Hi,
Im on 4.2.2 ( newest PA build) and my problem is when i turn bluetooth on my wireless connection gets very slow.
When bluetooth dvices are connected it gets even slower, but it stays always connected to AP.
[email protected]:/ # iwconfig wlan0
wlan0 Qcom:802.11n ESSID:"xxxx"
Mode:Managed Frequency:2.437 GHz Access Point: xxxxx
Bit Rate=52 Mb/s Tx-Power=17 dBm
RTS thr=2347 B Fragment thr=8000 B
Encryption key:xxxxx Security mode:restricted
I cant change tx-power with "iwconfig wlan0 txpower xx" to check if a boost would help.
Can anyone confirm?
Related
I can't seem to keep either of our Heros connected to WiFi reliably. It works fine when first turned on, then after 10 or 15 minutes I can't connect to anything. The Hero still shows itself as connected, excellent signal strength, and a valid IP config for my network. All other devices on my network continue to work just fine. Rebooting the phone usually, but not always, gets me another 10 minutes of WiFi connectivity.
I'm running DamageControl with the 2.41.04.02.02 radio. My wife's Hero is, aside from installing Handcent, exactly as it came out of the box. Both display the same symptoms. The problem is also the same regardless of which of my 3 access points I use.
I've spent 2 solid days googling this problem and come up empty handed. Does anybody know of a good solution to this?
Have you tried setting up Static IPs for your phones? To do this, hold down on the WiFi connection and select Advanced Settings.
Yep. I've been building and maintaining corporate networks for over 20 years. The very first thing I did was make sure the phone had valid IP configuration.
I also have the WiFi set to never sleep, per a suggestion I stumbled across on another board. Seems to make no difference.
This is extremely frustrating since both my wife and I rely heavily on data connectivity for our jobs. Living in an area where we're roaming and have 1x data *at best*, WiFi is completely non-optional for us.
Can you recommend a good ssh server for the phone? I'd like to log in and see what it's doing. From the symptoms I've observed it seems like either the DNS config or the routing tables are flaking out.
subliminalurge said:
…Can you recommend a good ssh server for the phone? I'd like to log in and see what it's doing. From the symptoms I've observed it seems like either the DNS config or the routing tables are flaking out.
Click to expand...
Click to collapse
I don't mean to dis your experience. It's always been my practice to answer in forums assuming novice status unless otherwise apparent.
I normally set DNS1 to the router address and let the router handle the job. Can't you SSH locally to test the local WiFi network?
Edit: Sorry... I see you meant an SSH Server for the phone. It should be built into the ROM isn't it?
There is a setting that some how gets set to turn wifi off when it goes to sleep.
Go to Menu > Settings > Wireless and Networks > WiFi Settings > Menu > Advanced > WiFi Sleep Policy > Change from After 15 minutes to Never or Never when plugged in.
Edit:
Disregard just saw your other post saying you have done this.
No worries. I also find it's usually better to oversimplify than to be overly technical when you're unsure of the audience.
What do you mean by "ssh locally"? The local WiFi network is working just fine. I have 3 laptops, 2 iPhones, an iPod touch, and a PS3 connected to it right now, all accessing the Internet just fine. I also have 2 Heros that have no access through the same network.
What I want to do is log in to a command prompt on the phone itself (which is essentially just a small Linux computer) and troubleshoot the network configuration from there. I've pretty much exhausted what can be done through the gui utilities on the phone.
I'm not sure if the 2.1 builds have dropbear installed. If so, it shouldn't be too difficult to enable the built-in ssh server. MoDaCo ROMs not only had it built-in, but enabled out of the box.
Cool. I'll look into getting that up and going.
Logged in through adb, here's where it's at.
Code:
# busybox ifconfig
busybox ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1097 errors:0 dropped:0 overruns:0 frame:0
TX packets:1097 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:101782 (99.3 KiB) TX bytes:101782 (99.3 KiB)
tiwlan0 Link encap:Ethernet HWaddr 00:23:76:BF:F2:A0
inet addr:192.168.5.229 Bcast:192.168.5.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1090 (1.0 KiB) TX bytes:2000 (1.9 KiB)
This is valid for my lan.
Code:
# busybox route
busybox route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 * 255.255.255.0 U 0 0 0 tiwlan0
default 192.168.5.1 0.0.0.0 UG 0 0 0 tiwlan0
#
This is also valid.
Let's take DNS out of the equation and ping an IP address. (OpenDNS server. It is up and responding to pings from my laptop at the same time I execute this command.)
Code:
# ping -c 3 208.67.222.222
ping -c 3 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
From 192.168.5.229 icmp_seq=2 Destination Host Unreachable
From 192.168.5.229 icmp_seq=3 Destination Host Unreachable
--- 208.67.222.222 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2002ms
#
Not good. The packet isn't even leaving the phone.
Let's just try the router itself.
Code:
# ping -c 3 192.168.5.1
ping -c 3 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
From 192.168.5.229 icmp_seq=1 Destination Host Unreachable
From 192.168.5.229 icmp_seq=3 Destination Host Unreachable
--- 192.168.5.1 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2000ms
#
And finally....
Code:
# ping -c 3 192.168.5.229
ping -c 3 192.168.5.229
PING 192.168.5.229 (192.168.5.229) 56(84) bytes of data.
64 bytes from 192.168.5.229: icmp_seq=1 ttl=64 time=0.427 ms
64 bytes from 192.168.5.229: icmp_seq=2 ttl=64 time=0.428 ms
64 bytes from 192.168.5.229: icmp_seq=3 ttl=64 time=0.427 ms
--- 192.168.5.229 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.427/0.427/0.428/0.016 ms
#
Well, at least the phone can ping itself...
I'll dig in deeper later, but I can now say for certain that this is NOT an IP configuration issue. The phone and access point aren't communicating on the hardware level (although according to the settings screen, the phone thinks it is).
Off the top of my head my best guess right now is that it's going to take some kernel level tweaking to get this resolved.
The subject pretty much says it all... if I have EV-DO available, and also have 802.11g available, how does the phone's network stack decide which route is better? Does it try to always use Wi-fi when available, on the theory that it avoids blocking incoming voice calls? Does it go as far as analyzing ping times and doing background traceroutes to see which route is more direct, reliable, and fastest? Does relative signal strength enter into the equation (ie, if I'm in the back yard & have a really marginal Wi-Fi signal, will it insist on trying to use it anyway to the exclusion of a potentially stronger EV-DO signal)?
I've tried to figure it out from observation. Originally, it seemed like it always tried to use WiFi whenever possible, but then I wrote a client-server app that tries to send traffic to my desktop PC at 192.168.x.x (which obviously can only route over wi-fi). The app worked sometimes, completely failed at others, and there seemed to be almost no discernible correlation between when it worked and when it failed.
Good question. Here's the routing table of a CDMA and 802.11x connected device. I don't see any metrics indicating one would be preferred over the other. Both tiwlan0 and rmnet0 are gateways. I wonder if the CDMA and WLAN interfaces receive some sort of preference elsewhere in the stack??
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
108.100.55.xx * 255.255.255.252 U 0 0 0 rmnet0
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
default 108.100.55.xx 0.0.0.0 UG 0 0 0 rmnet0
#
EDIT: I just ran 3 traceroutes to external addresses, and tiwlan0's interface was used every time. It seems to me in a routing table, the first route that can satisfy a request is used. In this case, my 10.x default gateway satisfies a route to an external address, and in my traces, that's what got used. I didn't see variable behavior.
I've found that it will always try to use wifi when available, regardless of signal strength. However, my tests have been conducted in 2 placess. One with a strong 3G signal (-72 or better) but with an incredibly unreliable wifi signal, the other with a strong wifi signal (4 to 5 feet), but at -96 to -106 to roaming 3G signal. I've found that it will try to use Wifi in both cases.
Yeah, it's something I've googled a few times, but it seems to be one of the great unexplored issues. Occasional anecdotal observations, but nobody who really knows what's officially intended to happen has ever really blogged about it online At first, it seemed pretty obvious that it would probably try to always use WiFi when possible, but when my own app started dying randomly with no route to host errors (even when I was standing with the phone literally 5 feet from the access point's antenna), I started to wonder what was really going on behind the scenes.
bitbang3r said:
Does it go as far as analyzing ping times and doing background traceroutes to see which route is more direct, reliable, and fastest? Does relative signal strength enter into the equation (ie, if I'm in the back yard & have a really marginal Wi-Fi signal, will it insist on trying to use it anyway to the exclusion of a potentially stronger EV-DO signal)?
Click to expand...
Click to collapse
IP routes are decided on subnets, masks, metrics. In most routing devices, there isn't additional intelligence unless a routing protocol is invoked, and even then, the protocol algorithm determines the best route and that route is placed in the routing table (successors are saved and inserted in the event an active route goes down).
These are all static default and subnet specific routes. Can you open adb shell, show your route table, and run a few traces to various external and internal addresses?
bitbang3r said:
Yeah, it's something I've googled a few times, but it seems to be one of the great unexplored issues. Occasional anecdotal observations, but nobody who really knows what's officially intended to happen has ever really blogged about it online At first, it seemed pretty obvious that it would probably try to always use WiFi when possible, but when my own app started dying randomly with no route to host errors (even when I was standing with the phone literally 5 feet from the access point's antenna), I started to wonder what was really going on behind the scenes.
Click to expand...
Click to collapse
I honestly don't think signal strength has anything to do with it. It should be a routing table decision.
I'm going to try a little experiment...hang on.
Ok, I disable CDMA and checked the route table:
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
# ping google.com
PING google.com (74.125.95.106) 56(84) bytes of data.
64 bytes from iw-in-f106.1e100.net (74.125.95.106): icmp_seq=1 ttl=50 time=223 ms
^C
Note, ping still works and the Sprint 108.x network and associated default gw are gone.
Interestingly, when I re-enabled CDMA, the 108.x default route wasn't added back into the table and the mobile network wouldn't connect until I disabled wi-fi.
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
Ping still works though:
Code:
# ping google.com
PING google.com (74.125.95.99) 56(84) bytes of data.
64 bytes from iw-in-f99.1e100.net (74.125.95.99): icmp_seq=1 ttl=50 time=1453 ms
64 bytes from iw-in-f99.1e100.net (74.125.95.99): icmp_seq=2 ttl=50 time=449 ms
Once I disabled wi-fi:
Code:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
108.101.213.xx * 255.255.255.252 U 0 0 0 rmnet0
default 108.101.213.xx 0.0.0.0 UG 0 0 0 rmnet0
Turning wi-fi back on places the tiwlan0 default back in the table above rmnet0 and traceroute went back to my 10.x gateway. This is very deterministic and exactly what I'd expect except for rmnet0 not coming back up with wi-fi enabled. It should...
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
108.101.213.xxx * 255.255.255.252 U 0 0 0 rmnet0
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
default 108.101.213.xxx 0.0.0.0 UG 0 0 0 rmnet0
The metric field in route on linux decides the weight on multiple routes, but android doesn't set it properly. Hope that makes sense.
It Is how a ' normal' linux kernel decides.
kkruse said:
The metric field in route on linux decides the weight on multiple routes, but android doesn't set it properly. Hope that makes sense.
It Is how a ' normal' linux kernel decides.
Click to expand...
Click to collapse
That's great, but the tests I ran showed deterministic behavior.
What's your source for this statement? Whether or not metrics are being used, the behavior I saw showed corresponding routing behavior.
Care to elaborate?
This is with JB 4.2.2 (Euroskank) on both:
turn on Bluetooth on Nexus 7 (N7)
turn on Bluetooth Portable Hotspot on Galaxy Nexus (GN)
pair
share internet on GN
choose to use GN for internet on N7
test it, doesn't work...
drop to root terminal on both to see what is wrong...
[email protected]:~$ netcfg
See it has IP of 192.168.44.1
[email protected]:~$ netcfg
it has a dummy IP, 169.x.x.x
[email protected]:~$ netcfg dhcp bt-pan
[email protected]:~$ netcfg
Shows that it gets 192.168.42.91 (wrong IP)
[email protected]:~$ ifconfig bt-pan 192.168.44.91
OK, IP is now good, time to check the routing..
[email protected]:~$ ip route
192.168.44.0/24 dev bt-pan proto kernel scope link src 192.168.44.91
BROKEN! Okay, let's add the default route:
[email protected]:~$ ip route add default via 192.168.44.1
check the route:
[email protected]:~$ ip route
default via 192.168.44.1 dev bt-pan
192.168.44.0/24 dev bt-pan proto kernel scope link src 192.168.44.91
Looks good, let's test it:
[email protected]:~$ ping google.com
PING google.com (74.125.226.69) 56(84) bytes of data.
64 bytes from yyz06s07-in-f5.1e100.net (74.125.226.69): icmp_seq=1 ttl=57 time=1 288 ms
Works!
But, when the GN goes to sleep, everything slows to a crawl... has to have a wake lock to keep data at a reasonable speed... why is Bluetooth tethering SO BROKEN?
Good thing my carrier blocks tethering, so all this really doesn't affect me, but for those that it does, I bet you guys are disappointed.
Hi,
I want to connect few phones to ethernet network via USB ASIX AX88772B adapter. Some devices can connect without any problems, some need to install xposed and Fake WiFi module. And some... can't! They all have OTG support and drivers for this network card. All phones get IP from DHCP, on all DNSs are set to 8.8.8.8 and 8.8.4.4, all have the same gateway. On all devices traceroute and nslookup works properly, but on some doesn't work ping and internet generally. It looks like Android can't see internet connection. Even with Fake WiFi. I also tried to set IP of rmnet0 to 0.0.0.0, but it didn't help. This is steps which I'm doing:
Install xposed, fake wifi and turn it on
Plug ethernet card
Dhcpcd eth0
setprop net.dns1 8.8.8.8 and for second dns 8.8.4.4
route add default gw xxx.xxx.xxx.xxx dev eth0
Testing with nslookup, traceroute, ping
Did you have the same problem? I noticed that all LG Phones have this problem, and HTC ONE Max (I didn't test on other HTCs). Could you help me?
The scenario: I have a rooted lollipop-TV-Box (S905) with Wifi, Ethernet (RJ45) and USB. The box is connected to internet via a wifi-router. Nearby I have a orange pi running with armbian (a debian-derivate for arm) with ethernet and USB but not wifi. I want to connect the orangepi via TVBOX-ethernet to the router to internet. This is my prefered solution. Alternativly I could also use a USB-connection between box and orangepi, but thats not prefered due to speed-reasons and the need for an additional client on the orangepi that are required for most usb-tethering solutions, and the box has no usb-tehering capabilities
I tried it the Linux-way on a linux-Machine with a shell-script. The wlan-net is 192.168.0.x the lan is 192.168.1.x. The wlan-ip in the Android/Linux router is 192.168.0.13 the lan in the same device is 192.168.1.2, the connected lan-client-ip is 192.168.2.4
the routing is Internet-(Wifi)-Gateway 192.168.0.1->Android/Linux-Box 192.168.0.13/192.168.1.2->192.168.2.4 and vice-versa
on lan-client:
ip route:
default via 192.168.1.2 dev eth0 proto static metric 1024
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4
on Android/Linux-Router
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.13 metric 600
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric 100
I also enabled forwarding and set the forward-tables with iptables
With the Linux-Box as a router everything works like a charm, with Android not, when I ping the lan-ip of the client from the Android box (ping 192.168.1.4) the reply is network unreachable from the external internet-server
PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.
From 84.116.198.82: icmp_seq=7 Destination Net Unreachable
From 84.116.198.82: icmp_seq=8 Destination Net Unreachable
From 84.116.198.82: icmp_seq=17 Destination Net Unreachable
I have to specify the interface with ping -I eth0 192.168.1.4, then it works, although this should already be specified by the local routes, like if the local request is routed over the public gateway. Looks like in Android the local routing is overriden by a hidden route to the default gateway