Notice: register_sidebar was called incorrectly. No id was set in the arguments array for the "Sidebar 1" sidebar. Defaulting to "sidebar-1". Manually set the id to "sidebar-1" to silence this notice and keep existing sidebar content. Please see Debugging in WordPress for more information. (This message was added in version 4.2.0.) in /usr/share/wordpress/wp-includes/functions.php on line 4139 Tech Notes » 2013 » June

APC 9617 DHCP on MacOSX

Uncategorized No Comments »

The APC UPS controller AP9617 requires an additional DHCP Option 43 set to “APC” to indicate that the DHCP specifically knows it’s talking to an infrastructure device; it’ll refuse all DHCP not bearing this string. This avoids misconfigurations but can be a pain to realize and configure. MacOSX uses opensource code for its daemons but really prefers this XML-ish “plist” config (I’m not a fan of this nearly-XML because although it leverages the concise “yes, this is markup” and escaped content, it is positional (change the order of the sibling “key” and “value” and it’s all screwed up), and it cannot be addressed/read in XPath notation. Even locating the proper plist config file can be non-trivial.

The shortcut:

  1. insert “<key>dhcp_option_43</key><data>AQQxQVBD</data>” into /private/etc/bootpd.plist and
  2. sudo /bin/launchctl load -w /System/Library/LaunchDaemons/bootps.plist to activate

The detail:

In Standard ISC Bind config, (Keith Perry @sciatl.com)
# The following class identifier is used by the APC UPS: "APC"

class "APCUPS" {
match if substring (option vendor-class-identifier, 0, 3) = "APC";
}

# The following line populates the lease file with
# the Vendor Class Identifier that the client sends.

set vendor-string = option vendor-class-identifier;
# APC Network
subnet 10.1.0.0 netmask 255.255.192.0 {
pool {
deny dynamic bootp clients;
option routers 10.1.63.254;
option broadcast-address 10.1.63.255;
option subnet-mask 255.255.192.0;
range 10.1.0.201 10.1.63.250;
authoritative;
filename "APC.bin";
next-server 10.1.0.1;
option vendor-encapsulated-options "APC";
allow members of "APCUPS";
ping-check TRUE;
}
}

On MacOSX, /etc/bootpd.plist is the key component, read by a daemon started using sudo /bin/launchctl load -w /System/Library/LaunchDaemons/bootps.plist (http://www.jacquesf.com/2011/04/mac-os-x-dhcp-server/). Tests can be made by making changes and “kill -HUP” (sighupping) the daemon, but it seems the underlying stack has already reserved a redirection for UDP/67 so running a bootpd or dhcpd outside of the launchctl won’t bind to the port (already in use).

The problem as well is that the <key>dhcp_option_43</key> we need to add to the config (to tell the APC that it’s OK, we know it’s an APC, you can accept this DHCP) isn’t one that MacOSX bootpd knows the format of, so it’ll complain (in the console log). Instead of a simple <key>…</key><value>…</value>, we need to use <key>…</key><data>…</data>, and the data needs to be Base64-encoded. I used http://hogehoge.tk/tool-i/, then checked it as follows:

$ echo -n 'AQQxQVBD'|base64 -D|od -tx1
0000000 01 04 31 41 50 43

This value is “code #1, length 4, #31, A, P, C”; AP9617 Documentation refers to this ‘1 A P C’ as “The APC cookie”. #31 might be the ASCII ‘1’ or an APC-specific “set option #31 to this value” marker.

The AP9617 then asks for an IP in a quicker mode when it’s just booting (cold-boot to Request is approx 18 seconds):

0.0.0.0.bootpc > broadcasthost.bootps: [no cksum] BOOTP/DHCP, Request from 00:c0:b7:12:34:56 (oui Unknown), length 300, xid 0x317e, secs 32, Flags [none] (0x0000)
Client-Ethernet-Address 00:c0:b7:12:34:56 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Vendor-Class Option 60, length 3: "APC"
Client-ID Option 61, length 7: ether 00:c0:b7:12:34:56
CLASS Option 77, length 3: "MSP"

When it has no valid lease, it’ll eventually drop to a fuller Request or a Discover; as you can see, it has absorbed the IP that I had sent it without the proper Option-43 set, so it seems to be re-asking with the offered IP address of 192.168.1.2 in a sort of “are you sure? (and please answer with option 43 set)”. Notice “Vendor-Option” is set in the Parameter Request line — I assume that’s specifically asking for Option-43.

14:54:25.674991 IP (tos 0x0, ttl 64, id 38, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.bootpc > broadcasthost.bootps: [no cksum] BOOTP/DHCP, Request from 00:c0:b7:12:34:56 (oui Unknown), length 548, xid 0x317e, secs 64, Flags [none] (0x0000)
Client-Ethernet-Address 00:c0:b7:12:34:56 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: 192.168.1.2
Parameter-Request Option 55, length 13:
Domain-Name-Server, Default-Gateway, Subnet-Mask, Domain-Name
TFTP, BF, BS, Vendor-Option
RN, RB, NTP, Time-Zone
Hostname
Server-ID Option 54, length 4: 192.168.1.1
Vendor-Class Option 60, length 3: "APC"
Client-ID Option 61, length 7: ether 00:c0:b7:12:34:56
CLASS Option 77, length 3: "MSP"

With our DHCP server set up in /etc/bootpd.plist, we’re happy to oblige:

192.168.2.1.bootps > 192.168.1.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x317e, Flags [none] (0x0000)
Your-IP 192.168.1.2
Server-IP 192.168.1.1
Client-Ethernet-Address 00:c0:b7:12:34:56 (oui Unknown)
sname "ACLARK-LT.local"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.1.1
Lease-Time Option 51, length 4: 85536
Domain-Name-Server Option 6, length 4: 192.168.1.1
Default-Gateway Option 3, length 4: 192.168.1.1
Subnet-Mask Option 1, length 4: 255.255.255.0
Vendor-Option Option 43, length 6: 1.4.49.65.80.67

Once it’s online, you can choose to accept DHCP offers lacking the APC Cookie for robustness; I did, but it opens me to rogue IPs. I think in my environment, there’s a higher risk of forgetting the random little bits that this device needs to appease its ego. Just take the IP and have a nice day 🙂

Automount on MacOSX

howto No Comments »

As a quick reminder, when trying to use automount -hosts on a Mac (ie auto-mounts NFS shares found by name on the local subnet), ensure that you:

  1. edit client:/etc/autofs.conf: ensure “resvport” is in AUTOMOUNTD_MNTOPTS (mine says: AUTOMOUNTD_MNTOPTS=nosuid,nodev,resvport)
  2. defaults write com.apple.desktopservices DSDontWriteNetworkStores true to avoid writing .DS_Store in network shares, which MacOSX keeps open (hence “hot”, hence avoiding automount timeout)

Works quite well now with my Synology, for which I have enabled “192.168.0.0/24 root_quash” for the shares in question:

$ showmount -e ds211.local
Exports list on ds211.local:
/volume1/Archive *
/volume1/music *
/volume1/Scan 192.168.0.0/24

$ mount
ds211.local:/volume1/Scan on /net/ds211.local/volume1/Scan (nfs, nodev, nosuid, automounted, nobrowse)

.. the next step is to set all Scanned content to write to this new pathname to avoid mount issues down-the-road

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in