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.
Related
I originally posted this in the Nexus One Forum... But recently bought my wife the Hero, and discovered the problem is also with that... So thinking now the problem is more general and Android related......
I have a weird problem.... My home network uses dnsmasq to provide DNS/dhcp. When i try to connect my phone via wifi, i get associated ok... also get IP+GW... BUT no DNS servers(!?). My previous phones (HTC Touch HD and Kaiser) never had this problem.
If i setup static IP, then all works ok.... So far i only have seen this problem at home, hence i believe it is dnsmasq related.
So... just wondering if anyone has come across a similar issue... or any ideas on how i can diagnose this. Haven't really done much diagnosing on Android yet, was hoping for a a few pointers.... Like how does Android handle DHCP... i am guessing it doesn't use the typical dhcpcd client
Thanks
Update:
Well after looking at this closely, discovered the problem is not with DNS entries, but setting the default GW. The thing is that dhcpcd sees the default gw and via hooks script in /system/etc/dhcpcd/dhcpcd-hooks runs setprop.
Also looking at logcat i can see that it picks up the right default gw but still isn't setting it:
V/WifiStateTracker( 106): IP configuration: ipaddr 192.168.1.74 gateway 192.168.1.254 netmask 255.255.255.0 dns1 192.168.1.3 dns2 192.168.1.254 DHCP server 192.168.1.3 lease 86400 seconds
but no default gw is listed when i run 'ip route show'... The other crazy thing is, that my dhcp server sends extra static routes, and these show fine... even work as expected.
If i manually add the route it works fine.... Well... i am a Linux admin but my first real attempt at working on Android, so still learning my way around... I am guessing setprop is used my Android to set the route (and other settings) but haven't figured out why it has failed. Will look some more, any help would be appreciated.
Well i finally got it working.... Posting here so that it might help others.
Basically the additional static routes were causing the problem. As i mentioned before, they were being added but no default GW. I removed the static routes from my dnsmasq config and hey presto the default gw was added.
Since i need these static routes for other boxes on my network, leaving left out was not really an option. So as a "band aid fix it" i added the default gw to the static routes list... So the line in dnsmasq looks like:
dhcp-option=121,<network>,<route>,0/0,192.168.1.254
This works.. but i don't really like it.
It seems that the static routes take precedence over the default gateway. I am not sure if this is a general problem or dnsmasq specific... Would be very suprised if it was dnsmasq only. Will open a bugreport and see what devs have to say
Hi,
we had the same problem with windows server 2008 and all android phones.
Make sure you have the static routes you want but also add a static route for 0.0.0.0/0 in your dhcp server. This way your android will work again.
good luck
yasn77 said:
Well i finally got it working.... Posting here so that it might help others.
Basically the additional static routes were causing the problem. As i mentioned before, they were being added but no default GW. I removed the static routes from my dnsmasq config and hey presto the default gw was added.
Since i need these static routes for other boxes on my network, leaving left out was not really an option. So as a "band aid fix it" i added the default gw to the static routes list... So the line in dnsmasq looks like:
dhcp-option=121,<network>,<route>,0/0,192.168.1.254
This works.. but i don't really like it.
It seems that the static routes take precedence over the default gateway. I am not sure if this is a general problem or dnsmasq specific... Would be very suprised if it was dnsmasq only. Will open a bugreport and see what devs have to say
Click to expand...
Click to collapse
This problem was driving me nuts also. Turns out that dhcpcd is just following the spec (RFC3442)!
The problem is masked on some Androids because something else (probably a hook script) is reading option 3 ("router") and setting the default route. In fact, in this situation, option 3 will override the 0.0.0.0/0 route in option 121, which is a direct violation of RFC3442 (which states that the Router option MUST be ignored in the presence of the Classless Static Routes option).
Has anyone had a problem with the Captivate when in both WIFI and 3G coverage the phone will not download or open a webpage? If I shut off one or the other it works but if both are active it hangs up and doesnt download.
Is this by chance on an enterprise wifi access point? Such as one of those expensive cisco APs you find in schools and enterprise class networks? If so, there is currently a driver problem with the captivate connecting to it, but not trasnfering data. Whether the netwrok is encrypted or open doesnt seems to matter. Personally, I find this a bigger problem than the GPS issue. I had to use wifi static to manually set IP, subnet, etc. This is a workaround, not a fix.
jhannaman82 said:
Is this by chance on an enterprise wifi access point? Such as one of those expensive cisco APs you find in schools and enterprise class networks? If so, there is currently a driver problem with the captivate connecting to it, but not trasnfering data. Whether the netwrok is encrypted or open doesnt seems to matter. Personally, I find this a bigger problem than the GPS issue. I had to use wifi static to manually set IP, subnet, etc. This is a workaround, not a fix.
Click to expand...
Click to collapse
Hey, I think I'm running into this issue at my workplace (we definitely use those Cisco APs, I see them all around). I'm connected, I have an IP, but I can't browse anywhere.
Here's the weird thing though: I can connect to the company's wifi in any other building (I guess different APs?) than the one I'm in and wifi works fine. It's just the building my cubicle's in that doesn't work and it's infuriating!
well thats dumb.
I had that happen once since I bought the phone on launch. I restarted my phone and it went away.
I've had this problem as well, usually my phone switches to only wifi pretty quickly though, so I don't notice much. The phone acts like it is using the 3G connection because the arrows are both indicating data coming and going, but nothing actually happens unless only one or the other is on.
i need to check this at more places but at home i have a standard dlink dl-624 router with no security over comcast. i think my issue initially was because of the wifi sleep policy (see below) but now i am just getting really really slow speeds. pages seem to load slower than 3G....(i mean really cinemaxHD is showing last of the mohicans in pan and scan)....also the pages time out very very frequently.....
Anyone having problems check out the advanced setting for wifi. The phone has a WIFI sleep policy. my default setting was to disconnect from wifi after the screen locks. my screen locks after 30 seconds. so basically it always looking for my network. you can change it to never.
I want to reiterate our findings again. There are multiple threads on other forums concerning this as well. When it comes to wifi, the captivate has a major problem. DHCP does not work on enterprise networks. Period. It is a driver issue. The network can be open or using any form of encryption, the results are thr same. I had numerous software, hardware and network analyst tackling this issue all week in my department. It is related in part to most enterprise networks not using a default subnet mask of 255.255.255.0. There is a workaround, but it is not a fix. You can either set a static from your static pool of ip's in wifi settings, or, if u connect to multiple networks, use wifi static from the market to remember and apply seperate static configs accross multiple networks which is what were having to do currently. This affects all captivates, one which we consider a major problem with deploying this phone to our other users.
Sent from my SAMSUNG-SGH-I897 using XDA App
I had the same problem and this is how a turn around the problem when I'm connected but cannot browse.
-Use Wifi Static
- DNS from google 8.8.8.8,8.8.4.4
- switch to airplane mode
- activate wifi
- test my conection (open the browser and surf)
- switch to phone mode
Hope it help
floppy__ said:
I had the same problem and this is how a turn around the problem when I'm connected but cannot browse.
-Use Wifi Static
- DNS from google 8.8.8.8,8.8.4.4
- switch to airplane mode
- activate wifi
- test my conection (open the browser and surf)
- switch to phone mode
Hope it help
Click to expand...
Click to collapse
Did this, Wifi Static was being used previously to bypass dhcp, and it correctly assigned the IP settings, used the static I assigned from our static pool of addresses. Still no data transfer over Cisco APs at work.
jhannaman82 said:
Did this, Wifi Static was being used previously to bypass dhcp, and it correctly assigned the IP settings, used the static I assigned from our static pool of addresses. Still no data transfer over Cisco APs at work.
Click to expand...
Click to collapse
are you able to access a website thru his IP address? in this case it's a DNS problem, try the Google DNS 8.8.8.8 - 8.8.4.4
floppy__ said:
are you able to access a website thru his IP address? in this case it's a DNS problem, try the Google DNS 8.8.8.8 - 8.8.4.4
Click to expand...
Click to collapse
Its hit or miss really, seems the wifi radio stack locks up and stops responding according to our trace logs. yes i have tried both our internal DNS server's as well as googles. Everywhere else works perfectly. But at work with our Cisco open (no security) APs, it doesnt work most of the time. Through whos ip address??? I have a static set from our static pool to make sure dhcp was not the culprit. Its def the device, and not my netwrok. I have over 100 of these APs deployed here.
Wifi works great everywhere else (at home with WPA2, etc). There is def a problem with enterprise cisco APs.
Netmask issue and cisco AP's
Posted this over in development thread.
http://forum.xda-developers.com/showpost.php?p=7698066&postcount=410
Make sure your netmask is correct.
Thanks jhannaman82
I just wanted to give a big thanks to jhannaman82 for posting his company's findings with these wifi issues. My wifi works 100% at home on my linksys tomato router (of course, with a netmask 255.255.255.0). But on my college campus they use an enterprise router setup with 255.255.0.0 and I have been going NUTS trying to figure out if it is my captivate or the network.
I can sometimes get a few minutes of working connection, but it always seems to crap out within 1 or 2 minutes.
I will attempt to fiddle around with switching the dhcp to static IP, and will post my results. Thanks!
edit: no luck with static IP fiddling so far. from my laptop (connected wirelessly), I gathered that the netmask is actually 255.255.248.0... when I set my captivate's netmask to anything other than 255.255.0.0, it does not connect. It says "connected" when I set the netmask to 255.255.0.0, but as usual no data will transfer (it seems). I'm at a loss. *shrug* Hopefully there's a driver update or something.
Thanks jhannaman82!
I just wrote a script with the GScript app: "ifconfig eth0 netmask 255.255.255.0", and have a shortcut on homescreen. The problem was that the netmask was wrongly set to 255.255.0.0 on my office wifi. Now all I need to do is tap on this shortcut at office, and the connection works!
Has anyone contacted Samsung about this ?
I'm hoping this gets fixed soon... This refuses to stay connected at my school. Huge pain.
I entered in an IP address and 255.255.252.0 for my netmask after seeing what it was on my computer and turn on flight mode and tested the wifi and now it's working. I'm not sure if it's just one of those fluke connections that I get... but we'll see.
Hello everybody! and sorry that i post this question here!
I have noticed some 2 months ago that i can not connect to wireless on my Huawei Ascend G300 U8815 , but i didnt care.
It was originally on GB 2.3.6 B885 then i upgraded to B895 then ICS B927 but wireless didnt work even before upgrading.
Yesterday i bought a TP link Router WR740N and setup my internet on it making it as an A.P, so i was sure that setting were correct since i connected with my laptop and another phone which is Nokia Xress Music 5530, but not on my G300.
So, my problem is that the phone recognize Wireless connections and when i try to access with or without password, it just says that my network is registered and keeps on trying to connect but unsuccessfully.
I tried all securities on my router from non to wep to wpa to wpa2 psk and still the same...
i even checked in some forums that some people experienced this problem, so they proposed :
-to reset phones setting to factory which didnt work
-use wifi fixer which didnt work
-upgrade to ICS which made me happy but still no wifi.
-use static ip address but also refsued to connect.
my self i downloaded WIFI MANAger Premium which is a very good soft but still knowing all networks but keeps turning and then stops.
Please find below my router settings:
LAN MAC Address:
64-70-02-55-4F-F8 IP Address:
192.168.1.1 Subnet Mask:
255.255.255.0 Wireless Wireless Radio: Enable Name (SSID): Meganet Channel: Auto (Current channel 6) Mode: 11bgn mixed Channel Width: Automatic MAC Address: 64-70-02-55-4F-F8 WDS Status: Disable WAN MAC Address: 64-70-02-55-4F-F9 IP Address: 88.222.160.212 Dynamic IP Subnet Mask: 255.255.248.0 Default Gateway: 88.222.167.254 DNS Server: 88.222.0.1 , 88.223.0.1
So, on the phone when i used static IP i did like this:
IP: 192.168.1.101
Mask: 255.255.255.0
GW: 192.168.1.1
DNS1: 192.168.1.1
DNS2: 192.165.1.1
Can any body help me please because i have tried all solutions and i think that the wireless driver is corrupted or something like that, so can it be replaced or flashed somehow because im using G internet now and it's exensive.....
Please i need your expertise!
Very strange
I am g300 owner too,and i never had any kind of problem with WiFi,it connects to everything (access point,printers,public places network,etc). It could be a factory problem,and I think you should take it into assistance. If you can't or you don't want to,you can try to root it and install an other kernel,but remember that this will compromise your warranty. There are all the guides and things you need at M*d*co.com huawei g300 forum. The best thing you can do is the first one,the second is a strictly recommended alternative.
Bye
Thanks...
Thanks for the answer.
So, by changing Kernel it means what? because i dont have big idea in Android and i just know the FW change so is it the same?
I also know that roting means giving full access to the phone so i have to root the phone and then?
I try to explain you that in a few lines
Android is a UNIX based OS,and it has a structure with UI,libraries,and lots of other stuff. The Kernel is the "root" of the structure "tree". It has every hardware driver and it controls those. It controls also WiFi lateen yard drivers, and this is why I advised you to try to change kernel and use a custom one,but this probably will not help you,cause in the update between ICS and gingerbread there's already been a kernel change(from 2.6.35 Linux kernel in GB to 3.0.1 Linux kernel in ICS), so the more probable reason of your problem is that your WiFi lateen yard is broken from factory. Take it to assistance, it's better than lose warranty and risk to break your phone
I'm having issues with my internet and am unable to do certain things that are sensitive to the NAT type. I have an LG Stylo 2 (Sprint), Windows 7 PC, Linksys router, Xbox One. Here's the order things are connected in
LGLS775>USB Tethered via PDANet>Windows 7 PC>Ethernet wire>Linksys router>Ethernet wire>Xbox One
I'm not sure how to set things up to fix the NAT type. Connection details: 60ms ping. 28 download. 7 upload. 100% packet loss.
I can still play certain games and access certain websites. But not everything. PLEASE DO NO TELL ME TO GO TO A DIFFERENT FORUM! ONLY POST HELPFUL ANSWERS
3 years later.
This is almost the same setup I'm working with but im using the wifi instead of usb on those parts.
For anyone having these issues I've got a couple things to try.
You can connect directly to pdanet via WiFi with pretty much any device (that I've seen so far) if you're able to set the proxy setting to manual using the ip given in pdanet with the port 8000. For me it would be 192.168.49.1:8000.
Or if you have to or just prefer to use a PDANet -> PC -> Router -> Device setup.
I used to have a much worse time with disconnects and error codes playing Destiny 2 on Steam, I still have problems here and there, sometimes often still. Ive got a good feeling though that what i did, actually improved my situation at least a bit.
In pdanet top right little menu with "Help" and "Dev Code", select IPv6 Support, then Prioritize IPv4.
Then in Windows, head to Network and Sharing, Change adapter settings, right click > properties on the adapter doing ICS then (what i did) uncheck "Internet Protocol Version 6 (TCP/IPv6)", "QoS Packet Scheduler", and anything else that isn't default, in my case, Npcap Packet Drivers.
I actually can't be sure that any of these really did anything but im much less frustrated than i used to be.
Also in my case im using a Netgear in AP mode, which ends up with a different local ip than ones that pdanet give. For me, after pdanet is adequately connected to the router, it seems that most of my Android devices work without further setup but some devices require setting a static ip, which should be easy to find using "arp -a" or "ipconfig" in cmd.
-In My Case-
The gateway was 192.168.137.1 so i choose any 2 digit number after 137. for the main (connecting device's) ip. Example. 192.168.137.23
So when connecting device to router via WiFi you will choose to set Manual/Static IP then after that the settings should look something like...
IP: 192.168.137.23
Gateway: 192.168.137.1
DNS: 192.168.137.1
Secondary DNS: 8.8.8.8
If v these v are set automatically or not required then you should be able to ignore them
Network prefix length: 24
Subnet mask: 255.255.255.0
I'm still trying to find other ways to set things that may be better but so far these are working okay for me. Don't hesitate to ask any question if clarification is needed, i understand a lot of things i post can be confusing. I hope at least some of this was helpful in any way!
CornholeOS_x86 said:
3 years later.
This is almost the same setup I'm working with but im using the wifi instead of usb on those parts.
For anyone having these issues I've got a couple things to try.
You can connect directly to pdanet via WiFi with pretty much any device (that I've seen so far) if you're able to set the proxy setting to manual using the ip given in pdanet with the port 8000. For me it would be 192.168.49.1:8000.
Or if you have to or just prefer to use a PDANet -> PC -> Router -> Device setup.
I used to have a much worse time with disconnects and error codes playing Destiny 2 on Steam, I still have problems here and there, sometimes often still. Ive got a good feeling though that what i did, actually improved my situation at least a bit.
In pdanet top right little menu with "Help" and "Dev Code", select IPv6 Support, then Prioritize IPv4.
Then in Windows, head to Network and Sharing, Change adapter settings, right click > properties on the adapter doing ICS then (what i did) uncheck "Internet Protocol Version 6 (TCP/IPv6)", "QoS Packet Scheduler", and anything else that isn't default, in my case, Npcap Packet Drivers.
I actually can't be sure that any of these really did anything but im much less frustrated than i used to be.
Also in my case im using a Netgear in AP mode, which ends up with a different local ip than ones that pdanet give. For me, after pdanet is adequately connected to the router, it seems that most of my Android devices work without further setup but some devices require setting a static ip, which should be easy to find using "arp -a" or "ipconfig" in cmd.
-In My Case-
The gateway was 192.168.137.1 so i choose any 2 digit number after 137. for the main (connecting device's) ip. Example. 192.168.137.23
So when connecting device to router via WiFi you will choose to set Manual/Static IP then after that the settings should look something like...
IP: 192.168.137.23
Gateway: 192.168.137.1
DNS: 192.168.137.1
Secondary DNS: 8.8.8.8
If v these v are set automatically or not required then you should be able to ignore them
Network prefix length: 24
Subnet mask: 255.255.255.0
I'm still trying to find other ways to set things that may be better but so far these are working okay for me. Don't hesitate to ask any question if clarification is needed, i understand a lot of things i post can be confusing. I hope at least some of this was helpful in any way!
Click to expand...
Click to collapse
So I actually figured it out a while back but now I'm in the same boat since I've moved to a place with no highspeed again. Same basis except I'm now T-Mobile, using a VPN and the Hotspot VPN APK. Same connection route. If I remember correctly there was an IP address error with the 137.anything. I'll post an update soon.
Anything better then pdanet ? That bypass data speed throttle after using so much???
This started a couple of days ago, and I have now mitigated it with a couple of firewall rules on the VPN gateway, as well as shutting down the dhcpcd server on that server (which I don't need anyway, and which probably should have been stopped long ago).
My LAN has a raspberry pi 4 running their debian firmware that is configured as a VPN gateway. It connects my LAN via ProtonVPN to the internet. This gateway is set up with a static IP address (192.168.2.49) on the LAN, and is configured to use another RPI on my LAN to get its DNS (192.168.2.50).
My one month old running OOS 11 OnePlus8 is rooted with magisk, and I have blocked most of the google stuff from the internet using afwall, and suspended non-essential system services using greenify. When connected to my LAN, the phone has a static IP address (192.168.2.71), has its gateway set to the VPN gateway (192.168.2.49), and its DNS to my local rpi DNS (192.168.2.50).
DHCP on my LAN is provided by my router (192.168.2.1).
WIFI on my LAN is provided by an enterprise-grade tp-link hotspot.
Starting a few days ago, for reasons mysterious, when the phone connects to the LAN, the VPN gateway would promptly go offline. Because I run it headless, I would be forced to reboot it - which made diagnosis a bit of a pain. Finally, I found a log entry on the VPN gateway that informed me that my OnePlus was trying to claim the ip address of the VPN gateway as its own (192.168.2.49) in spite of being set to use 192.168.2.71. This duplicate IP was causing dhcpcd on the VPN gateway to immediately take down its eth0 interface. This would break ALL connectivity because I have wifi on that RPI disabled.
Prior to this problem involving the OnePlus, that RPI had been up continuously for over 400 days, so it should certainly be considered to be reliable at the job it does and almost certainly the problem is with the OnePlus.
So, for some reason the OnePlus is trying to assert its assigned gateway address as its IP rather than the 192.168.2.71 that is set, at least in some packet that it uses to announce itself; once it is connected it works properly (which means the right IP address is being used).
I have deleted, then re-created the wifi connection profile and doing that did not cause the problem to go away.
I have another RPI VPN gateway on my IOT VLAN (192.168.24.0/24). No DHCP is available on the VLAN (a security measure), and I do have a profile for the phone that allows it to connect to the VLAN. It works without issue there, but then dhcpcd has been and remains shut down on that RPI. I suppose I could start dhcpcd on that server and see if the phone then breaks it too. I won't do this unless there is some merit to doing so...if it would help find the basic problem.
As I say, shutting down dhcpcd and blocking all dhcp traffic to/from the LAN VPN gateway mitigated the problem. But that the problem could occur at all says something is wrong, and I'm pretty sure it isn't a problem on my network.
This seems most likely to be a bug in OnePlus firmware, though why it would manifest after a month is a mystery to me. Does anyone have any insight? Or does anyone have any suggestions for another place on XDA where this post might more appropriately be placed?
I was pretty sure no one would have any idea about this. I have mitigated it by turning off dhcpcd on the VPN gateway and I am not inclined to do a deeper dive; I have too much else to do.