Comment 5 for bug 856333
Revision history for this message
| Mathieu Trudel-Lapierre (cyphermox) wrote | #5 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I think I know what this is, but it's a little tricky to test/prove. With both wired and wireless connected, could you do the following:
1) Capture the output of two separate commands (in separate terminals) running roughly at the same time:
sudo tcpdump -i eth0 icmp or arp
sudo tcpdump -i wlan0 icmp or arp
2) As these are running, start in a third terminal: "ping 8.8.8.8"
They don't need to be started exactly at the same time; and we only need the terminal output because they can include sensitive data if run while other things are going on using the network. This should only need to run for a short while: in ping, you'll likely see no responses for a while and short bursts of actually getting responses, or the other way around. If you always get responses or never get any, then it's something different (but the output of tcpdump will still help).
And the highly technical explanation for all this:
I think traffic is being routed incorrectly; as if for a while eth0 sends the traffic, and it comes back through wlan0 (which would cause it to be "lost"). At some point once other network devices have their arp cache expire; depending on how fast arp replies will get to the server; eth0 will start to both send and receive traffic and connections will complete. Then another arp request will come by and break it again.
However, I don't see how this would be tied to an update unless there was a kernel change very recently. Wired is not affected by many things except NM to establish connections and the driver/kernel to push data. The latest upload of NM doesn't appear to be installed on your system yet (I uploaded it just a few hours ago). The last kernel upload was 9 days ago. I'm not sure what else may have affected the device.