Great discussion from the following thread:
http://forum.xda-developers.com/showthread.php?t=1191792
Thanks to know Static IP can temporary solve the connection problem.
BUT I found somethings:
1. A lot of 3.1 users upgraded to 3.2, BUT NOT ALL Users report such WiFi (grey icon / disconnect irregularly) problem.
2. A lot of people use DHCP, lot of lot users have no such problem. Some of us posted here are annoying with such WiFi problem, however, static IP can help.
3. Therefore the problem relates DHCP and Static IP.
My guess:
1. Maybe most of us (with WiFi problem) used DHCP BUT with IP reservation (I use reservation).
2. Most users (without WiFi problem (my friend's TF doesn't have grey problem)) use only the DHCP without IP reservation.
My testing and result:
1. Firstly, I disable the IP reservation (192.168.1.11) for the TF
2. Then set the DHCP range to 192.168.1.2 to 192.168.1.8 (1-7 for other devices)
3. Then I set the TF to DHCP
4. Finally, TF gets the 192.168.1.8
5. Then I use File Manager HD to get a 619MB file from my desktop to TF (Two times testing)
6. Wow, it's SMOOTH!!! Before DHCP with IP reservation...only can download around 100MB then disconnected. Now, no more disconnection
My conclusion (or you may try too):
With 3.2, don't set your router to have IP reservation with your TF, just set DHCP, MAC mapping (it's fine, no problem, WPA2-PSK (it's fine too).
Bros and Sis, if your TF faces WiFi problem after upgrading to 3.2, you may try my solution.
If your TF and router work well again with DHCP without IP reservation, my prediction is correct.
If my prediction is correct, please spread this message, to let TF fans, Xoom, Asus, Google to know it!
Please help to try and use back your DHCP.
Good Luck!
Just removed my IP reservation. Wifi icon now blue. Will let you know if this helps my disconnects
EEE Pad Transformer sent this
I have rooted 3.2 and no Wi-Fi problems. However, when I look at the syslog files from my router I see:
Code:
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
The Transformer is doing a DHCP request every 3 minutes or so. This is exceptionally frequent, and could cause the connection to drop if a) there are existing network problems that prevent the request from going through successfully or b) the DHCP server gets pissed off and stops responding.
PS: I obscured the MAC address in the log sample on purpose.
rtadams89 said:
I have rooted 3.2 and no Wi-Fi problems. However, when I look at the syslog files from my router I see:
Code:
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
The Transformer is doing a DHCP request every 3 minutes or so. This is exceptionally frequent, and could cause the connection to drop if a) there are existing network problems that prevent the request from going through successfully or b) the DHCP server gets pissed off and stops responding.
PS: I obscured the MAC address in the log sample on purpose.
Click to expand...
Click to collapse
The transformer isn't doing any DHCP requests based on it's own logic. It is all based on the length of the lease at the router handing out the DHCP requests (which runs dhcpd). If you have control of the router, you can set the lease length. All the transformer does is find out that it's lease has expired and fetch the same one again (usually, based on arp tables, etc).
My router has the DHCP lease time fro non-static (static DHCP configured from the router, not static IP configured on the client) addresses set to 24 hours. For static DHCP address the lease time is infinite. In both cases, the Transformer does a DHCP request every 3 minutes or so.
rtadams89 said:
My router has the DHCP lease time fro non-static (static DHCP configured from the router, not static IP configured on the client) addresses set to 24 hours. For static DHCP address the lease time is infinite. In both cases, the Transformer does a DHCP request every 3 minutes or so.
Click to expand...
Click to collapse
In that case, it's just weird. Based on reading that, I looked at the router log at home and mine isn't doing that but of course I could see the original DHCP request. I'm running 3.2 US rooted (whatever latest build is of that), no custom ROM, and as far as DHCP, it is behaving.
Yeah, I could see how an endless series of requests could cause trouble for our cheap home routers. Is there any chance that something else on your network is spitting out dhcpd services? If I were going to try to troubleshoot it, I'd setup another wifi router(some older cheap one would do) on it's own network, disconnect from your primary router, and point it at the new / old one, and see what it did over there. With only the two players, it might be easier to tell. For that matter if you've got a phone with wifi tether, I guess that would be a good test.
Does the logcat on the TF also note these DHCP requests?
hachamacha said:
Is there any chance that something else on your network is spitting out dhcpd services?
Click to expand...
Click to collapse
No other DHCP servers on the network.
hachamacha said:
If I were going to try to troubleshoot it, I'd setup another wifi router(some older cheap one would do) on it's own network, disconnect from your primary router, and point it at the new / old one, and see what it did over there. With only the two players, it might be easier to tell. For that matter if you've got a phone with wifi tether, I guess that would be a good test.
Click to expand...
Click to collapse
I tether to my phoen via bluetooth, so I can't really check that and I don't have any other routers that would show me enough log detail to see that info. What I did do is disable the router's DHCP/DNS services and instead used one of my Linux VMs to handle those services on the network. Same problem.
hachamacha said:
Does the logcat on the TF also note these DHCP requests?
Click to expand...
Click to collapse
Yes.
What I have done though is remove the static DHCP lease for the transformer, and it let it be assigned completely randomly. I'm reviewing the logs now, but it seems to not be requesting a lease as often. I'm not sure if that is an issue with how the router is handing out "infinite" leases (I'm not sure if it just sets a lease expiration as some large value, or if it sets it as zero, or if it doesn't even send that parameter at all).
If I do this command:
#getprop | grep lease
I get back something like this:
response: *wlan0*lease* : 84600
----
I was wondering what your's shows? I got interested in this when I noticed init.ventana.rc kicking off dhcpcd (client daemon) that uses for config /system/etc/dhcpcd/dhcpcd.conf so poked around some more.
Looking at this man page:
http://roy.marples.name/cgi-bin/man-cgi?dhcpcd.conf
(sorry, but no clue if all those work on android)
It does make me wonder if the leasetime parameter works? It says this:
leasetime seconds
Request a leasetime of seconds.
The problem is usually that the busybox/hacked down versions of these utilities like dhcpcd involves drastically reduced functionality.
Apparently on mine, it is working as intended since 84600 seconds is the lease length ala my router and is what it shows as the 'given lease time' on my TF, so I wonder if at that level it is showing up the same.
I use a linux box to do my DHCPD duties. So far I've tried both mac address based allocation of address and just allowing my TF to get one from the pool - there didn't appear to be any difference between the two.
With the default lease time set to 600 seconds and the max set to 7200 I was getting a request for dhcp renewal every couple of mins :
Code:
08-06 09:53:37.660 D/DhcpStateMachine( 130): DHCP request on wlan0
08-06 09:53:38.060 D/DhcpStateMachine( 130): DHCP succeeded on wlan0
08-06 09:53:38.070 D/WifiStateMachine( 130): netId=0 Link configured: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy:
08-06 09:53:38.090 D/ConnectivityService( 130): addDefaultRoute for WIFI (wlan0), GatewayAddr=192.168.1.254
08-06 09:56:02.450 D/DhcpStateMachine( 130): DHCP renewal on wlan0
08-06 09:56:02.850 D/DhcpStateMachine( 130): DHCP succeeded on wlan0
08-06 09:56:02.850 D/WifiStateMachine( 130): Link configuration changed for netId: 0 old: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy: new: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy:
08-06 09:56:02.880 D/ConnectivityService( 130): addDefaultRoute for WIFI (wlan0), GatewayAddr=192.168.1.254
08-06 09:58:27.130 D/DhcpStateMachine( 130): DHCP renewal on wlan0
08-06 09:58:27.330 D/DhcpStateMachine( 130): DHCP succeeded on wlan0
08-06 09:58:27.340 D/WifiStateMachine( 130): Link configuration changed for netId: 0 old: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy: new: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy:
08-06 09:58:27.370 D/ConnectivityService( 130): addDefaultRoute for WIFI (wlan0), GatewayAddr=192.168.1.254
I then changed the default lease time and the max lease time to 84600 (24 hours) and am getting practically none of these ... only when I turn on my TF since I have the wifi set to disable on screen off. - And obviously I don't see my wifi indicator go grey or loose network connectivity.
My first question is why when the lease time is set to 600 seconds is it making the request after 2 mins ?
It looks to me like it is dropping at least part of its layer 3 config when it goes through this process.
I have used IP reservations since the very first connection to my router, which included MAC filtering. I have never had my connection drop, at least none that I'm aware of.
Mind you, I buy a new router every year, to improve performance, for better implementations of standards, better compatibility, etc.
Those having issues may want to test another router.
Sent from my Transformer TF101 using XDA Premium App
As long as I set my lease time to 24 hours I have no problems ... trouble is I don't get a say in that on public wifi hotspots ... this should just work ... it's not exactly a complicated protocol.
A renew should just update the expiry time on the lease on the DHCP server it shouldn't trigger a complete layer 3 reconfigure which is what appears to be happening.
You should be able to find 'tcpdump' for arm. (might be called tcpdump-arm), which is a pretty nice packet sniffer for linux (or whatever it's built for). With that and a tcpdump examples page, (or the man page), you could look over the packets that are going back and forth, but this isn't simple stuff if you're not well versed in what they ought to look like, and even if you are, it's not that easy.
Wireshark, used to be called ethereal, would be much easier, but the only thing I can find out there in the market so far is "shark for root", and "shark reader". These are better than nothing, probably require tcpdump, and might help, but are also just trying to stick tcpdump output into a GUI, which isn't that good.
Maybe if you can find the right tools this becomes a lot easier to at least nail down to a 'bug' or even a 'fix', but without knowing the actual problem in terms of data being passed, these things are tough.
I'm just guessing that somewhere on XDA, there is a sniffer that is better than what I've mentioned and like the others is free. I've not searched around yet.
A different tactic that would also be useful would be to setup a 'hub' or a couple of 'mirrored ports' but then the question becomes " who the hell has this stuff anymore? " It requires , perhaps, Cisco level gear , IOS mirroring commands, or a hub (which are out of 'style'). But with that, you could slap in a laptop running wireshark and do this. Oh crap. I totally forgot that this is wifi, not wired, so the last option isn't good unless you've got a dd-wrt router that will somehow allow all this. DD-WRT is really cool, so it might let you run a good sniffer itself right from the router.
thephm said:
As long as I set my lease time to 24 hours I have no problems ... trouble is I don't get a say in that on public wifi hotspots ... this should just work ... it's not exactly a complicated protocol.
A renew should just update the expiry time on the lease on the DHCP server it shouldn't trigger a complete layer 3 reconfigure which is what appears to be happening.
Click to expand...
Click to collapse
I'm in your camp - my lease time is 1 week.
And the answer to this problem most assuredly is NOT 'replace your router' (which coincidentally is also what Asus tech support told me). Next will be 'go ahead and drive to a different public WiFi'.
hachamacha said:
You should be able to find 'tcpdump' for arm. (might be called tcpdump-arm), which is a pretty nice packet sniffer for linux (or whatever it's built for). With that and a tcpdump examples page, (or the man page), you could look over the packets that are going back and forth, but this isn't simple stuff if you're not well versed in what they ought to look like, and even if you are, it's not that easy.
Wireshark, used to be called ethereal, would be much easier, but the only thing I can find out there in the market so far is "shark for root", and "shark reader". These are better than nothing, probably require tcpdump, and might help, but are also just trying to stick tcpdump output into a GUI, which isn't that good.
Maybe if you can find the right tools this becomes a lot easier to at least nail down to a 'bug' or even a 'fix', but without knowing the actual problem in terms of data being passed, these things are tough.
I'm just guessing that somewhere on XDA, there is a sniffer that is better than what I've mentioned and like the others is free. I've not searched around yet.
A different tactic that would also be useful would be to setup a 'hub' or a couple of 'mirrored ports' but then the question becomes " who the hell has this stuff anymore? " It requires , perhaps, Cisco level gear , IOS mirroring commands, or a hub (which are out of 'style'). But with that, you could slap in a laptop running wireshark and do this. Oh crap. I totally forgot that this is wifi, not wired, so the last option isn't good unless you've got a dd-wrt router that will somehow allow all this. DD-WRT is really cool, so it might let you run a good sniffer itself right from the router.
Click to expand...
Click to collapse
I do this stuff for a living and am a fully card carrying geek .... my home router is a Cisco 1800, I run a linux server as a DHCP/Mail/Web/anything else I can think of box. tcpdump is pretty straightforward for someone with a modicum of networking knowledge and running with the -w option will save the captured packets in a binary format suitable for opening in Wireshark which makes things even easier. I've already done all this on from the dhcp servers perspective ... the problem doesn't appear to be in the dhcp request/response packets but what the TF actually does with the packets higher up int the TCP stack. In my opinion the way to identify the problem is not more packet tracing but to look at the dhclient code and/or the kernel code in android 3.2 preferably with the diff's against android 3.1.
Android defect : http://code.google.com/p/android/issues/detail?id=18648
which has been assigned an owner
thephm said:
In my opinion the way to identify the problem is not more packet tracing but to look at the dhclient code and/or the kernel code in android 3.2 preferably with the diff's against android 3.1.
Android defect : http://code.google.com/p/android/issues/detail?id=18648
which has been assigned an owner
Click to expand...
Click to collapse
I actually think it got broken in the 3.1 update, FWIW. I ran just fine with my current setup on 3.0.
I believe mine worked correctly on 3.1 - I have only had mine about 2 weeks so I went straight to 3.1 and then very soon after that to 3.2 but when I upgraded to 3.2 I was on a foreign network so it wasn't a direct comparison.
thephm said:
I do this stuff for a living and am a fully card carrying geek .... my home router is a Cisco 1800, I run a linux server as a DHCP/Mail/Web/anything else I can think of box. tcpdump is pretty straightforward for someone with a modicum of networking knowledge and running with the -w option will save the captured packets in a binary format suitable for opening in Wireshark which makes things even easier. I've already done all this on from the dhcp servers perspective ... the problem doesn't appear to be in the dhcp request/response packets but what the TF actually does with the packets higher up int the TCP stack. In my opinion the way to identify the problem is not more packet tracing but to look at the dhclient code and/or the kernel code in android 3.2 preferably with the diff's against android 3.1.
Android defect : http://code.google.com/p/android/issues/detail?id=18648
which has been assigned an owner
Click to expand...
Click to collapse
Wow, a real Cisco router. I'm impressed. If you can afford electricity to run that thing, all is well. I realized after I'd replied that the tcpdump I'd put on my tf was the full featured one, not some android knockoff. It is a good tool.
I read up on the bug report and it seems you're right. I always hope that trouble leaves a telltale. I guess I've escaped it for some reason because I'm on 3.2 and haven't the issue. Probably the problem takes a number of ingredients to occur.
I'm glad the bug is longer an orphan.
Sent from my Transformer TF101 using XDA App
chupig said:
Bros and Sis, if your TF faces WiFi problem after upgrading to 3.2, you may try my solution.
Click to expand...
Click to collapse
Just unistall it to good old 3.1
My device also had the same issue with being unable to connect to the wifi, as a different method than the ones suggested earlier,
Just change the password protection method of your router,
Changing mine from WPA / WPA2 to WPA2 solved the problem for me, weirdly enough...
AlienCraB said:
My device also had the same issue with being unable to connect to the wifi, as a different method than the ones suggested earlier,
Just change the password protection method of your router,
Changing mine from WPA / WPA2 to WPA2 solved the problem for me, weirdly enough...
Click to expand...
Click to collapse
Very strange coz that is a lower layer of the connection ... I've never lost the "physical" connection to the wifi just the layer 3 connectivity (the ip address/default route) when using DHCP.
My N5 cannot connect to my new wifi network. I can connect to my university wifi just fine, my wired PC has a connection through the router, my laptop is able to connect, everything else works just fine.
The network is WPA2-Personal encrypted, on channel 6, and is using the 2.4 GHz band. I've been able to connect to this exact router in the past (the exact same device, not just the same model), never had any issues. I just plugged it in again tonight and now it won't work. The phone tries to connect, is successful for a split second, then immediately drops back to just saying "Saved".
The log message below repeats a few times; I tried connecting quite a few times and these seem to be the related logs from /process/kmsg (I just removed the timestamps). I don't know how to interpret these error messages, so any ideas would be greatly appreciated!
Code:
cfg80211: Calling CRDA for country: US
wl_bss_connect_done succeeded with <router MAC address>
CFG80211 - ERROR) wl_is_linkdown : Link down Reason : WLC_E_DEAUTH_IND
link down if wlan0 may call cfg80211_disconnected . event : 6, reason=3 from <router MAC address>
CFG80211 - ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK
cfg80211: Calling CRDA to update world regulatory domain
wl_bss_connect_done succeeded with <router MAC address>
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wl_notify_connect_status nothing
wl_bss_connect_done succeeded with <router MAC address>
dhd_ndo_add_ip: ndo ipaddr added
CFG80211 - ERROR) wl_is_linkdown : Link down Reason : WLC_E_DEAUTH_IND
. . .
CFG80211 - ERROR) wl_cfg80211_get_station : NOT assoc
connect failed event=0 e->status 1 e->reason 0
CFG80211 - ERROR) wl_bss_connect_done : Report connect result - connection failed
Maybe your router somehow saved the configuration of your previous Nexus 5. I know that they collect/store information about the connected device - mine does at least
I've now tried two separate routers, a WD MyNet N900 and a Netgear WNR1500. I've tried all different channels, different speeds, g-only or n-only, 2.4GHz and 5GHz, 20MHz channels and 20-40MHz channels, every type of encryption from WPA2 to open, EVERYTHING. The Nexus WILL NOT connect to either router. It connects to my university wifi and all other networks just fine, my laptop can connect no problem, my wired desktop has no problems, but my damn N5 just won't connect no matter what settings I use.
This problem actually happened once before, with both routers, but that was several months ago and I wasn't too worried about it then. Now I want this to work; there's absolutely no reason it shouldn't be. I tried removing the networks in question from my wpa_supplicant.conf file and deleting ipconfig.txt outright, then rebooting, problem persisted. Between the time this last happened and now I have done a full, clean factory image reset.
I don't know what the hell the problem could possibly be.
Setup a static ip address on your nexus 5 and setup the same static ip address in your router
Sent from my rooted RCT6203W46 using xda-dev app
piperx said:
Setup a static ip address on your nexus 5 and setup the same static ip address in your router
Sent from my rooted RCT6203W46 using xda-dev app
Click to expand...
Click to collapse
Appreciate the suggestion, but I did try that step. No dice. Also tried WPS, both button and PIN methods, nothing.
Lolliopop has screwed up my wifi on 2 devices.
My N10 at home slows to a crawl if you're more than a room or so away from the router. Happened the instant I updated the firmware. Factory resets, OTAs and flashing factory images have not made a difference. I've finally now updated my N5 to CM12 and now can't connect to my work wifi at all. Luckily I have a good 4G signal there.
Google screwed up something bad with Lollipop and wifi. It doesn't affect everyone but there are plenty out there with the same issues - just check out the Nexus help forums on Googles own site. Not sure whether its specific to certain routers or what but something is certainly wrong.
It is some saved setting or something on the router. I found this: https://communities.intel.com/mobil...-content?content=/api/core/v3/contents/323227
Try wiping your router settings or see if it remembers MAC addresses or DHCP leases.
Sent from my Nexus 5 using XDA Free mobile app
MrObvious said:
It is some saved setting or something on the router. I found this: https://communities.intel.com/mobil...-content?content=/api/core/v3/contents/323227
Try wiping your router settings or see if it remembers MAC addresses or DHCP leases.
Sent from my Nexus 5 using XDA Free mobile app
Click to expand...
Click to collapse
I found that as well during my troubleshooting, but there's nothing on either router that does that. I wiped both (completely removed the firmware then reinstalled fresh from the manufacturer site) and retried, still nothing. I'm on CM12 now (was on stock/rooted), still can't connect. I do have telnet access to one of the routers (working on getting root SSH), so I can mess around, but I don't even know where I'd look.