Airport Stuff

Graphite (original) base station firmware

Note: Apple's 2.0.4 update, including PPTP and IPSec support, is only available for the Snow basestation. See Apple's AppleCare document on 2.0.4, which says "...update does not provide any new Graphite Base Station functionality."

Airport 2.0.2 firmware -- KarlBridge verison 3.84 'kbairp' (aka Graphite BaseStation 3.84 update) -- 234,704 bytes
Airport 2.0 firmware -- KarlBridge version 3.82 'kbairp' -- 234,752 bytes
Airport 1.3.1 firmware -- KarlBridge version 3.81 'kbairp' -- 234,648 bytes
Airport 1.3 firmware -- KarlBridge version 3.79 'kbairp' -- 234,624 bytes

Upgrading Orinoco "Silver" cards to 128-bit WEP ("Enhanced WEP Encryption"). Apparently the airport firmware doesn't allow 128-bit WEP with an upgraded silver card inside the airport, but clients can use this technique.

I'm not really working on this any more, for the following reasons:

There's a Java Configurator, which works well.
KarlNet is working on a CLI, and theirs will obviously be better than mine. Lucent/Agere/ORiNOCO's version of it is available from www.orinocowireless.com's download section. Look for the "AP CLI Proxy Software", the web page says it manages AP-500 and AP-1000 but don't be fooled, it works on some features of the airport too. Lucent/Agere/ORiNOCO has binary-only releases for Windows and Linux. The Linux binary works great on my FreeBSD 4.3 box with Linux emulation.
Shortcuts to orinocowireless.com's download search: Linux | All operating systems .

My limited perl script is available as aircli-prerelease1.tar.gz. It requires the SNMP perl module from CPAN, which in turn requires UCD-SNMP. It can load and save configurations, and can do a few configuration changes but is somewhat buggy and I lost interest.

The remainder of this page is kind of a diary of my reverse-engineering in early 2000. There's probably no unique or new information here (although I like to think there was at the time).

On boot, the airport first ARP's for its own address (possibly the last address that it used); on the one I just got it's 192.42.249.13. I think it just always uses this address on boot, since I assigned it an address via DHCP and then it went back to 192.42.249.13 on boot.

It then does 3 cycles through 10.0.1.(2..50), ARP'ing for each one. If it gets an ARP reply, it ping's the address on (that? and) future passes by that address (e.g. ARP for 39, ping 40, ARP for 41). It does this on both the wired and wireless sides. Presumably this is to figure out what DHCP addresses it has assigned.

It also sends DHCP requests, and can be assigned an address by a DHCP server. At this point, you can use SNMP to talk to it. A simple walk will just get mib-2, but a walk of enterprises finds a few OID's under enterprises.762 . This seems to imply that it's a KarlBridge. (KarlBridge's web site seems to agree; http://www.karlnet.com/news/199912/199912-Airport.html.) In fact, KarlNet's configurator for Windows (see the File Downloads section) can manage some aspects of the Airport operation (not NAT or DHCP, as far as I can find =( ) Unfortunately, it sometimes can't write the configuration to the device (the SetRequest for the 2nd row just times out, no errors or anything), so this may only be good for checking the configuration and monitoring (like wavelan monitoring).

KarlBridge's web site implies that the KarlBridge software supports the WavePoint, WaveLAN, and RS232 MIBs, although I haven't been able to find any of these to prove it yet. They don't show in a walk but that could just be an incomplete walk implementation. The KarlNet Configuration software for Windows allows you to configure tests and discover other WaveLAN network users from the bridge's point of view, so there's definitely something going on there. Need to sniff this too.

No WEP or access control is configured in this default configuration. Great for plug-n-chug (although I would love to know how to turn off NAT and DHCP...)

I sniffed the Apple software configuring the Airport. It uses long opaque strings to do the actual configuration; it looks like enterprises.762.2.2.1.1.1 thru .68 are each 256-element OCTET-STRINGS which are access to the device configuration memory. So, although decoding what's going on is still doable, it's much more painful than if they actually used SNMP data types, etc.

Locations:

Trap community string: 56, max 31 chars.
Read community string: 76, max 31 chars.
Write community string (write-only): 96. Writing a 0-length string retains the current setting.
Microwave Oven Robustness Support: 0x158 : 0x00->0x20
Turn on syslogging: 117: 0x20 -> 0x00, 478 -> syslogger host; 440 = numeric syslog facility
Network name: 1c8, 1c9, 1d8, 1d9, 1e8, 1e9, ..., max 32 chars.
Modem info:
- Length of init string at 19a and init string at 19b, 1aa, 1ab, ...
- Following init string, 2 BCD-encoded phone numbers:
- Dialout number (length of this in digits at 18a)
- 2nd number (length of this in digits at 18b)
Serial Number: 3fe
Be a DHCP client on eth0: 44a=40; don't: 44a=0.
- Change DHCP interface to wi0: 117: 20 -> 00; 119: 51 -> 71
Do DHCP & NAT: 0x449 = 0x82; don't: 449 = 0.
Do only DHCP: 0x449 = 0x80
Also be a DHCP server on the ethernet: 117 = 0x40
Low address in DHCP'able range: cf2 Hi: cf6
?wavelan's static IP? 0xd2a
DNS server: cfa, cfb, d00, d01, cfc, cfd, d02, d03
My current address: 46a. d4a? (on airport)
Current netmask: 474, d4e, d66
Default router: 470
Trap destination: 47a
SysContact: 48c, max 63 chars
SysName: 4cc, max 63 chars
SysLocation: 50c, max 127 chars
SNMP access ACL's:
- number of entries in list at 636
- 1st 2 bytes of the IP address follow starting at 638
- 2nd 2 bytes of IP address follow starting at 642
- 1st 2 bytes of each netmask follow starting at 64a
- 2nd 2 bytes of each netmask follow starting at 656
- Interface specification is unclear. Padding is unclear. Need to check again with more table entries.
Domain Name: d0a
Dialout expect/send sequences start at f08
- 0x80 + length of expect string
- expect string
- 1 byte (192 + timeout?) - but if no timeout spec'd then no byte
- 0x40 + length of send string
- send string, including 0x0d
MAC filter table: 448 == 0x81: on, == 0x01: off, f88 & f89 (little-endian short) has # of entries in this table. table can handle at least 258 entries (possibly all the space f8a-1cc8 is reserved for this table, meaning 565 entries). The Lucent software help says 497 entries.
- MAC addresses: f8a, f90
- Station names: 1cc8, 1cdc
Dialout info at 3eaa: 1 byte username length, N bytes username, 1 byte password length, N bytes password.
Dialin info at 3ece: 1 byte username length, N bytes username, 1 byte password length, N bytes password, constant 0x02. 2nd info is at 3eec, dunno if it's constant 3 bytes after 1st username/pw or if it's constant location, forgot to try variable length
Checksum #1 at 43b6-43b7: sum of bytes in config area, in little-endian order.
Checksum #2 at 43b8-43b9: sum of bytes 0-43b7 (i.e. including checksum #1), in little-endian order. (This one was HARD to figure out!)

TODO List:

Figure out how 16-bit overflow is handled in the checksum calculation
Figure out where the rest of the configuration items are
- NAT
- DHCP server
- Dialup configuration
Figure out the WEP key algorithm
Figure out the string length limitations
Implement all this stuff

Auto-Discovery

When trying to discover base stations, the mac (and the KarlNet Configurator) sends the following UDP packet:

17:14:49.344819 10.42.42.47.32769 > 255.255.255.255.192: udp 116
E...Py..<....**/         4500 0090 5079 0000 3c11 f98b 0a2a 2a2f
.........|H.....         ffff ffff 8001 00c0 007c 48dc 0100 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000

That causes the base station to reply as follows:

17:14:49.345327 10.42.42.46.192 > 10.42.42.47.32769: udp 116 (DF)
E.....@......**.         4500 0090 0000 4000 ff11 12ac 0a2a 2a2e
.**/.....|kA....         0a2a 2a2f 00c0 8001 007c 6b41 0101 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
................         0000 0000 0000 0000 0000 0000 0000 0000
.0e."d...**.AirP         0030 652e 2264 0000 0a2a 2a2e 4169 7250
ort Base Station         6f72 7420 4261 7365 2053 7461 7469 6f6e
 f74037.......Z.         2066 3734 3033 3700 0000 0000 0000 5ae4
AirPort Base Sta         4169 7250 6f72 7420 4261 7365 2053 7461
tion V3.60 SN-P.         7469 6f6e 2056 332e 3630 2053 4e2d 5000

Not surprisingly, this is a port registered by Doug Karl:

osu-nms         192/tcp    OSU Network Monitoring System       
osu-nms         192/udp    OSU Network Monitoring System       
#               Doug Karl <KARL-D@OSU-20.IRCC.OHIO-STATE.EDU>

Interestingly, the Lucent WavePoints respond to this request also. I don't know the community names for our WavePoints or I'd investigate further.

Firmware Upload

It seems like when the Airport software does a firmware upload, it writes the configuration in the same way as normal, and then keeps going:

SetRequest(291) E:762.2.3.1.1.1
SetRequest(291) E:762.2.3.1.1.2
...
SetRequest(293) E:762.2.3.1.1.876
SetRequest(293) E:762.2.3.1.1.877

and then reboots (this is a different reboot than I've seen):

SetRequest(32) E:762.2.1.2.0=224448 (DF)
SetRequest(32) E:762.2.1.3.0=224448 (DF)

Odd thing: the Mac config program started being unable to save to the airport in the same way as the KarlNet config program (timeout on row 2 of the Set). I power-cycled the airport and then it started behaving OK again. Now the KarlNet config program is able to save certain configuration changes too! Weird.

Some comments after using the modem and NAT/DHCP

traceroute doesn't work through the NAT; I guess it doesn't translate the ICMP replies.
I thought I configured A and B as DNS servers, but the airport gives itself,A, itself, itself,itself and itself as DNS servers. When you send the airport a DNS request, it forwards it to the DNS server, but then the reply comes directly from the server so if you expect the reply from who you sent it to you'll be disappointed.
- (I hear this is so that requests don't time out when you're dialing -- it lets you keep falling back to the next server while it dials and hopefully it'll bring the line up before you time out N times.)
I can't find any modem activity information; getting ifOperStatus.3 is the best I can do (which doesn't help if it's dialing or chatting). It'd also be nice if there was chat script debugging somewhere...
I got an unsubstantiated report that the whole box can crash if you do an active FTP connection through it.

CAUTION

When I was revisiong the configuration a lot, the Apple software became unable to handle the configuration that was present on the Airport (I think it was the pulse dialing mode that made this happen). It would donwload the whole config and then pop up an error box (sometimes an empty error, sometimes saying I probably had the wrong password, and sometimes binary gibberish). Luckily, uploading a previously working config that I had sniffed off the wire a while ago put everything back into a good state. I will endeavor not to have bugs like this in my configurator =)