On Wed, Jan 03, 2018 at 03:58:13PM +0000, Roderick wrote: > After losing Link > > # netstat netstat -n -I run0 >> tmp-netstat1 > netstat: interval is invalid
The above is bogus. Please read what you wrote before sending. > # tcpdump -n -i run0 > tcpdump: listening on run0, link-type EN10MB > ^C > 0 packets received by filter > 0 packets dropped by kernel > > # tcpdump -n -i run0 -y IEEE802_11_RADIO > tcpdump: listening on run0, link-type IEEE802_11_RADIO > 15:29:37.475139 802.11: data: 192.168.0.12.41070 > 64.233.190.16.587: FP > 3160548212:3160548235(23) ack 3357202105 win 256 <nop,nop,timestamp > 4270344605 658810306>, <radiotap v0, chan 1, 11g> > 15:29:45.974910 802.11: data: 192.168.0.12.47665 > 64.233.186.108.993: FP > 1359026660:1359026696(36) ack 2175423745 win 256 <nop,nop,timestamp 964805565 > 1626745330> (DF), <radiotap v0, chan 1, 11g> > 15:30:41.473291 802.11: data: 192.168.0.12.41070 > 64.233.190.16.587: R > 24:24(0) ack 1 win 0, <radiotap v0, chan 1, 11g> > 15:30:49.973049 802.11: data: 192.168.0.12.47665 > 64.233.186.108.993: R > 37:37(0) ack 1 win 0 (DF), <radiotap v0, chan 1, 11g> > 15:31:28.692024 802.11: data: 192.168.0.12.4130 > 200.1.19.17.123: v4 client > strat 0 poll 0 prec 0 [tos 0x10], <radiotap v0, chan 1, 11g> > 15:33:43.018220 8 This looks like the driver is still trying to send frames but the device has stopped receiving (and perhaps sending) for some reason. It's virtually impossible to debug this with back-and-forth over email. Ideally I would need to be in the same room as you or reproduce the problem independently. Can you trigger this problem elsewhere with a different AP or is it limited to the particular environmental conditions of this network?
