wpa_supplicant stops carrying traffic after some hours

[James Feeney]

On 03/11/2018 04:57 AM, Jouni Malinen wrote:
> Restarting wpa_supplicant may clear whatever was broken here because
> that forces the station to reassociate with the AP and practically clear
> all state

Simply reassociating does not fix the problem.  A full restart is doing something different.

> If the traffic goes
> through fine to the AP and to the local network, but fails to go through
> to "outside network" (which I'm assuming is referring to going through
> an IP router), the Wi-Fi connection part is likely to be functional and
> issue is somewhere in the AP.

No - instead, the traffic seems to stop at the local machine interface.  Packets can be seen on the local network, but the machine stops responding.  Perhaps this is something with the kernel IP stack?  Perhaps the kernel stops talking to wpa_supplicant?  How could I test for that, or prove that?

But, I don't understand how the "local" network could act differently from the "outside" network.  In practice, I am connected to the machine "locally" through ssh.  If then, I try to, say, ping Google, there is no response.  Restart wpa_supplicant and ping works fine again.

And the failure is history dependent.  I only see this fail after a lot of "external" traffic.

And the fact that this network communication has to go through two different bus interfaces, from the PCcard to the PCI layer, and then from the PCI layer to the kernel, could that be causing some problem?  The PCcard driver probably doesn't get much testing these days.  Is there some way to "snoop" communication between these layers?

Thanks
James