[CUWiN-Dev] Re: IBSS Split aka BSSID wars?

[David Young]

On Sat, Feb 03, 2007 at 03:41:09PM +0100, Sven-Ola T??cke wrote:
> Hi,
> 
> as David wrote in that days. Some of us use a fixed bssid (we use 
> 02:ca:ff:ee:ba:be). This works fine with current madwifi-ng using "iwconfig 
> ap xxx". I think that every ad-hoc net bigger than two dozen nodes need a 
> fixed bssid with one exception: you have the same hardware everywhere. 
> Anyhow, the ibss merge code in madwifi-ng does not look too clean for me. 
> Does not take into account the timedrift needed to execute driver code...

The way I did it in NetBSD was to look at the difference between the
TSF in the beacon/proberesp and the TSF timestamp that the MAC puts on
received packets.  If the MAC's TSF was less than the beacon/proberesp's
TSF, I initiate a merge.  In this way, there is no timedrift in the
driver.  I thought that at one time, madwifi-ng worked the same.

> One PS. We had problems with madwifi-ng at least on MIPS. Occasionally frozen 
> tx interrupt. Simply stops sending. You send a packet through the HAL, but 
> the TX int expected a few msecs later does not show up. According to a bloke 
> who knows the HAL sources, this may be a hardware bug. Fixed with a hack. In 
> case you need the same:

I have found out a few things about how to protect network devices
from stalling, or else appearing to stall.  Maybe one of these issues
affects MIPS:

        * Make certain that tx/rx descriptors are stored in uncached
          memory (sloooow), or else synchronize the CPU's view and the
          device's view of RAM by flushing/invalidating cache lines
          before the device starts DMA.  NetBSD provides an API for this
          so-called "DMA synchronization," and I am 99% sure that Linux
          does, too.

        * Beware that a PCI bus bridge in your system may have "write
          posting" enabled, so that when the CPU writes to a register
          (for example, the "doorbell" register that makes the transmitter
          check its descriptor ring), the write may not reach the device
          until after an arbitrary delay.  Ordinarily, you can flush the
          write-posting buffer by reading any register on the same device.

        * Use a 'volatile' modifier on all data that is shared between
          the CPU and a NIC, especially the tx/rx descriptors.  Otherwise,
          the compiler may optimize inappropriately.

          (This will probably not affect madwifi, because HAL subroutine
           calls handle descriptors.)

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933