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: 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:


TODO List:


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


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 =)