Dual Booting and DHCP - is that my problem?

[Randybob01]

So, long story short, I dual-boot Windows 7 and Linux Mint 13 (LTS) w/ KDE, and I was able to connect just fine using the same wireless adapter I run currently to my old roommate's router in both operating systems. I think it was an old G router, he didn't give me details on it other than how to connect on wifi. We went our separate ways, and now I'm using a U-verse wireless gateway. I can connect just fine in Windows, and on my Android phone. I have not changed my adapter. I'm still running Linux Mint 13, I didn't change the wireless adapter's driver. But when I boot into Mint, the network connection only lasts a few minutes, then it goes dead. I need to service network-manager restart every few minutes in order to maintain a connection, and that connection is noticeably slower in Mint than it is in Windows (and slower than the connection I had at the old place). I'm using DHCP, and in Linux, it's the connection to the gateway itself that goes dead. Under both operating systems, the computer has the same hostname. Being as the router is all that changed, is it possible that the router/gateway is getting confused by the dual-boot setup somehow?

Here are some of my ping times for comparison. In Linux, they're horrible:

--- 192.168.1.254 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.694/21.921/120.601/37.192 ms
zathras ~ # ping -c 10 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_req=1 ttl=64 time=102 ms
64 bytes from 192.168.1.254: icmp_req=2 ttl=64 time=105 ms
64 bytes from 192.168.1.254: icmp_req=3 ttl=64 time=249 ms
64 bytes from 192.168.1.254: icmp_req=4 ttl=64 time=2.73 ms
64 bytes from 192.168.1.254: icmp_req=5 ttl=64 time=34.2 ms
64 bytes from 192.168.1.254: icmp_req=6 ttl=64 time=74.4 ms
64 bytes from 192.168.1.254: icmp_req=7 ttl=64 time=2.63 ms
64 bytes from 192.168.1.254: icmp_req=8 ttl=64 time=1.90 ms
64 bytes from 192.168.1.254: icmp_req=9 ttl=64 time=2.71 ms
64 bytes from 192.168.1.254: icmp_req=10 ttl=64 time=5.15 ms

--- 192.168.1.254 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.900/58.190/249.068/75.351 ms

Here's a ping as the connection dies, then after a restart:

zathras ~ # ping -c 10 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_req=3 ttl=64 time=270 ms
64 bytes from 192.168.1.254: icmp_req=4 ttl=64 time=266 ms
64 bytes from 192.168.1.254: icmp_req=6 ttl=64 time=272 ms
64 bytes from 192.168.1.254: icmp_req=7 ttl=64 time=268 ms
64 bytes from 192.168.1.254: icmp_req=10 ttl=64 time=267 ms

--- 192.168.1.254 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 8999ms
rtt min/avg/max/mdev = 266.803/268.988/272.246/2.019 ms
zathras ~ # service network-manager restart
network-manager stop/waiting
network-manager start/running, process 24931
zathras ~ # ping -c 10 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_req=1 ttl=64 time=236 ms
64 bytes from 192.168.1.254: icmp_req=2 ttl=64 time=2.74 ms
64 bytes from 192.168.1.254: icmp_req=3 ttl=64 time=5.61 ms
64 bytes from 192.168.1.254: icmp_req=4 ttl=64 time=5.19 ms
64 bytes from 192.168.1.254: icmp_req=5 ttl=64 time=2.34 ms
64 bytes from 192.168.1.254: icmp_req=6 ttl=64 time=1.91 ms
64 bytes from 192.168.1.254: icmp_req=7 ttl=64 time=2.34 ms
64 bytes from 192.168.1.254: icmp_req=8 ttl=64 time=1.73 ms
64 bytes from 192.168.1.254: icmp_req=9 ttl=64 time=2.29 ms
64 bytes from 192.168.1.254: icmp_req=10 ttl=64 time=2.02 ms

--- 192.168.1.254 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.733/26.248/236.277/70.021 ms

In Windows though, it's as fast as one would expect:

Pinging 192.168.1.254 with 32 bytes of data:
Reply from 192.168.1.254: bytes=32 time=3ms TTL=64
Reply from 192.168.1.254: bytes=32 time=3ms TTL=64
Reply from 192.168.1.254: bytes=32 time=2ms TTL=64
Reply from 192.168.1.254: bytes=32 time=5ms TTL=64
Reply from 192.168.1.254: bytes=32 time=10ms TTL=64
Reply from 192.168.1.254: bytes=32 time=11ms TTL=64
Reply from 192.168.1.254: bytes=32 time=4ms TTL=64
Reply from 192.168.1.254: bytes=32 time=7ms TTL=64
Reply from 192.168.1.254: bytes=32 time=8ms TTL=64
Reply from 192.168.1.254: bytes=32 time=4ms TTL=64

Ping statistics for 192.168.1.254:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 11ms, Average = 5ms

Wifi performance on my Android was fast as usual when I was having the problems in Linux. With Windows and Linux, it's the same IP, and restarting Network Manager has not changed that as yet. What can/should I check for the connection before blaming the driver or kernel (this issue predates every kernel update I have attempted since the move, but didn't happen before the move)?

 

[Mushkins]

The DHCP server binds an IP with the MAC address of the network adapter, regardless of what OS you're booted into if they're both using DHCP it'll just give out the same address and everything's gravy.

Sounds like a Linux problem, not a network problem to me.

 

[XavierMace]

DHCP has nothing to do with the performance. If it wasn't working, you wouldn't have any connectivity at all.

Sounds like a Linux problem.

 

[VirtualLarry]

I agree with the other two people. Linux's wifi drivers suck, in most cases.