On Wed, 15 Jun 2016, Chris Murphy wrote:
On Wed, Jun 15, 2016 at 4:34 AM, vendor@billoblog.com wrote:
... and I bet there's a huge rise in dropped packets before it happens, right?
How can I tell? I tried this but it suggests no dropped packets.
# ip -s -d a
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 34:02:86:cc:d8:69 brd ff:ff:ff:ff:ff:ff promiscuity 0 inet 172.19.11.32/24 brd 172.19.11.255 scope global dynamic wlp2s0 valid_lft 15235sec preferred_lft 15235sec inet6 fe80::3602:86ff:fecc:d869/64 scope link valid_lft forever preferred_lft forever RX: bytes packets errors dropped overrun mcast 198972107 245657 0 0 0 0 TX: bytes packets errors dropped carrier collsns 8006062 90794 0 0 0 0
I'm tellin' ya, it's gotta be the driver/firmware and there's nothing you can do except get a different box or wait until the next revision of the driver/firmware and hope it works. If you've tweaked the MTU, moved things to avoid interference, changed channels, and hopped around between g and n, that's all you can do as a sysadmin/user.
I think it's a local configuration problem. I was in this same environment a year ago and this worked with the same hardware (well, it was a different building so different physical APs but the people managing it are the same).
Yow. I wasn't expecting that.
Well, this weekend, I'll plug in a little Chinese usb wifi adapter that exhibited the same kind of behavior you described, at least when I played with it with Fedora 22. I have four cheap usb adapters, all of which are *supposed* to have the same chips. Yayy ebay. Two of them do the same sort of thing you write about -- run fine for 20-30 mins and then crump. One of them only does it when it's talking to a Cisco router. Two of them work great.
I'll see what wireshark has to say. Maybe what I find on my toys might help.
billo