PREPARING TO LAND! PREPARING TO LAND
I am posting this from project:camphor driver for Intel 2200BG! It works.
This was hard, hard work. I managed to figure out the source of the problem with Tx of packets: the Tx descriptor’s layout was not correct. Took many tries to finally find the correct layout, cross-referencing with the Linux driver, and now everything works.
The connection seems to be pretty stable: the downstream speed is maxing itself out (as fast as my DSL can work, right now 2 mbps). Need to test with local machine to see if it can hit 54 mbps well. I am also upstairs while my wifi router is tucked in a corner of the garage downstairs — it is normal for the signal to be very weak here, but the card is working as well as the FreeBSD driver (and not to gloat, but the connection is more responsive than iwidarwin - jalavoui if you’re reading this, there is a small bug in iwidarwin which I think is the reason it is quite slow in weak signal: NEED_ACK flag for tx descriptor should be set for unicast packets, not multicast packets).
Upload seems to be slow, though. This is probably because even though I’ve set the Tx power to MAX, the poor card can’t transmit a strong enough signal for the router to receive. There could be some things which the driver should be doing (e.g. if a packet takes too long to transmit and is not acknowledged, retransmit it). I don’t know if the TCP/IP layer should be doing it, or the 802.11 layer, but I’ll investigate this issue further. Right now I tell the OS that the transmission was “successful” after only sending it to the hardware - i.e. not when the hardware actually says that the transmission was done. So maybe I have to figure out a way to tell the OS asynchronously that the transmission succeeded or failed, so that the networking stack will itself retransmit the packet.
There is also the issue of when to drop connection, i.e. when x number of beacons have been missed, the connection should ideally be dropped and freshly associated. Also, scanning for networks while being connected seems to be a problem.. And many other such things.
In short, still a lot needs to be done before the driver is ready for prime time. But now it’s a matter of polish.
One thing that struck me though: Apple’s “802.11 stack” is pretty much non-existent. The driver has to do everything, because for transmission, it is sent 802.3 Ethernet frames instead of 802.11 frames! The outputRaw80211Packet() function never seems to be called, but I’ll see if I can figure out a better way. Right now the driver has its own nano-sized IEEE 802.11 “stack”.
Anyway, screenshots will be coming in the next post.
