Bug#478858: madwifi-source: sometimes doesn't see arp packets

[Kel Modderman]

On Thursday 01 May 2008 23:41:04 Celejar wrote:
> Package: madwifi-source
> Version: 1:0.9.4~rc2-1
> Severity: important
> 
> Hardware is a pci Atheros AR5215/5213 (rev 01).
> 
> My LAN has a consumer wireless AP / switch / gateway router ('gwen'),
> and various hosts, including the box with the Atheros card ('edith') and
> another linux box ('lizzie').   Outgoing connections from edith are
> fine.  Incoming connections (e.g. ssh from lizzie) are sometimes fine,
> but sometimes fail with "no route to host".  In the normal case, the arp
> table on lizzie is correct; in the problem case, the entry for edith is
> 'incomplete'.  Pinging lizzie from edith will correctly set up lizzie's
> arp table, as will manually entering edith's MAC addres into lizzie's
> arp table.  Running tcpdump on edith (in the problem case) does not show
> any arp communications initiating from any other clients on the network,
> although it does show its own arp requests and replies to them.
> 
> I have no idea what triggers the problem; inbound connections will be
> fine for a while, and then they will start failing.  Removing and
> reinserting ath_pci seems to usually fix the problem.
> 
> The network is running WPA-PSK.  Googling turned up various (old)
> problems similar to mine, with some speculation that WPA was implicated,
> but in at least some of those cases, the arp packets showed up, albeit
> in garbled form, while in my case I see no trace of the arp requests at
> all [0].  I'm not sure if the problem occurs without WPA; turning off WPA
> seems to often require reloading ath_pci before the system will
> reconnect, and that itself seems to often solve the problem.  If
> necessary, I suppose I could run the network for a while without WPA.

This sounds fishy, there should be no need to reload the driver just to connect
to a bssid of different security properties.

Do you know if you are using the "wext" or "madwifi" driver backend of
wpa_supplicant to sustain these WPA connections? The madwifi backend is
deprecated but provided for backwards compatibility reasons.

> 
> I'm no network expert, and I may be misdiagnosing the problem.  I will
> be glad to provide additional diagnostic information at request.

I am no expert either, sadly I have no idea at all about this problem.

Thanks, Kel.