Closed GoogleCodeExporter closed 9 years ago
exactly same behaviour. I tried to connect an iPad.
No way... It was not possible to get dhcp response.
No IP assigned. No router specified, no subnet mask.
please, please, help!!!!
Original comment by viscardi...@gmail.com
on 29 Apr 2010 at 9:09
[deleted comment]
[deleted comment]
same here, same "rooting" : seeing the adhoc network but no dhcp response...
trying bluetooth : no pan/dun bluetooth service detected from my macbook pro.
thanks.
Original comment by steevebr...@gmail.com
on 29 Apr 2010 at 11:13
To debug please do the following:
1) Try to start from user-interface. This generates a configuration-file for
your device.
2) After this attempt failed connect to the device via adb, become root and try
to
start manually - commands:
adb shell
su
cd /data/data/android.tether/bin
./tether start 1
This should generate a more detailed output which you could post here (that
would help).
Thanks
Original comment by harald....@gmail.com
on 30 Apr 2010 at 2:29
These are my results:
# ./tether start 1
about to run: [/data/data/android.tether/bin/ifconfig eth0 192.168.2.254
netmask
255.255.255.0]
about to run: [/data/data/android.tether/bin/ifconfig eth0 up]
about to run: [/data/data/android.tether/bin/iwconfig eth0 mode ad-hoc]
about to run: [/data/data/android.tether/bin/iwconfig eth0 essid Aether]
about to run: [/data/data/android.tether/bin/iwconfig eth0 channel 6]
about to run: [/data/data/android.tether/bin/iwconfig eth0 txpower 10mW]
about to run: [/data/data/android.tether/bin/iwconfig eth0 commit]
about to run: [/data/data/android.tether/bin/iptables -N wireless-tether]
about to run: [/data/data/android.tether/bin/iptables -F wireless-tether]
about to run: [/data/data/android.tether/bin/iptables -t nat -F PREROUTING]
about to run: [/data/data/android.tether/bin/iptables -t nat -F POSTROUTING]
about to run: [/data/data/android.tether/bin/iptables -t nat -F]
about to run: [/data/data/android.tether/bin/iptables -A wireless-tether -m
state --
state ESTABLISHED,RELATED -j ACCEPT]
about to run: [/data/data/android.tether/bin/iptables -A wireless-tether -s
192.168.2.0/24 -j ACCEPT]
about to run: [/data/data/android.tether/bin/iptables -A wireless-tether -j
DROP]
about to run: [/data/data/android.tether/bin/iptables -A FORWARD -j
wireless-tether]
about to run: [/data/data/android.tether/bin/iptables -t nat -I POSTROUTING -s
192.168.2.0/24 -j MASQUERADE]
about to run: [/data/data/android.tether/bin/dnsmasq -i eth0 --resolv-
file=/data/data/android.tether/conf/resolv.conf --conf-
file=/data/data/android.tether/conf/dnsmasq.conf]
script result was []
#
The strange thing is that, at least when doing this through ADB, I had to
disable
wifi previously; otherwise iwconfig would report my home router essid
(reddwarf)
instead of the configured one (Aether).
Starting with wifi disabled seemed to render better results:
# ./ifconfig eth0
eth0: ip 192.168.2.254 mask 255.255.255.0 flags [up broadcast running multicast]
# ./iwconfig eth0
eth0 IEEE 802.11-DS ESSID:"Aether" Nickname:""
Mode:Ad-Hoc Frequency:2.437 GHz Cell: 2A:17:81:7E:F4:0D
Bit Rate=11 Mb/s Tx-Power:10 dBm
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Managementmode:All packets received
Link Quality=5/5 Signal level=-57 dBm Noise level=-57 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:4 Invalid misc:0 Missed beacon:0
#
Nonetheless, my laptop won't get an IP address.
I saw several iwconfig-related BUG reports in the dmesg output, but I don't
know
whether these may have anything to do with the problem. I'll attach the dmesg
output.
Original comment by skanda...@gmail.com
on 30 Apr 2010 at 6:01
Attachments:
Ok, what I see look good.
Could you check the following please ...
adb shell
ip route
Original comment by harald....@gmail.com
on 30 Apr 2010 at 6:51
With the phone connected to my home wifi:
# ip route
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.65
default via 192.168.0.1 dev eth0
After disabling wifi and running tether start 1:
# ip route
10.125.33.32/28 dev rmnet0 proto kernel scope link src 10.125.33.39
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.254
default via 10.125.33.33 dev rmnet0
Original comment by skanda...@gmail.com
on 30 Apr 2010 at 7:13
ok, let's sum it up.
1) what i see from the generated output looks good. the wifi-interface can be
started. ad-hoc mode seems to be configured. all ok.
2) you don't get an ip-address from the dhcp-server which is running on the
phone.
right? (do you have an intel card in your pc - do you use windows 7?)
weird.
let's generate network-trace ...
1) download "tcpdump" from here
2) copy it to your device and set file-permissions:
adb push tcpdump /data/data/android.tether/bin/.
adb shell chmod 0755 /data/data/android.tether/bin/tcpdump
3) start the tethering app from gui
4) start packet-capturing on eth0
adb shell
cd /data/data/android.tether/bin
./tcpdump -i eth0 -w /sdcard/dump.pcap
5) try to join from your pc
6) stop tcpdump (press ^C)
7) attach generated file here
Original comment by harald....@gmail.com
on 30 Apr 2010 at 9:19
Attachments:
My card is ath9k based. I've tried with Ubuntu 9.10, Ubuntu (10.04, just
upgraded :-)
) and Windows 7.
I attach the capture file (but I opened it with Wireshark and it didn't show
anything
sensible ?!?!
This is what I ran on my laptop:
root@rimmer:~/downloads/htc-desire# ifconfig wlan0 down
root@rimmer:~/downloads/htc-desire# iwconfig wlan0 mode Ad-Hoc
root@rimmer:~/downloads/htc-desire# ifconfig wlan0 up
root@rimmer:~/downloads/htc-desire# iwconfig wlan0 essid Aether
root@rimmer:~/downloads/htc-desire# iwconfig wlan0 channel 6
root@rimmer:~/downloads/htc-desire# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"Aether"
Mode:Ad-Hoc Frequency:2.437 GHz Cell: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
root@rimmer:~/downloads/htc-desire# dhclient -d wlan0
Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/00:23:4d:0b:3b:a0
Sending on LPF/wlan0/00:23:4d:0b:3b:a0
Sending on Socket/fallback
DHCPREQUEST of 192.168.0.66 on wlan0 to 255.255.255.255 port 67
DHCPREQUEST of 192.168.0.66 on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
Trying recorded lease 192.168.0.66
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
No working leases in persistent database - sleeping.
^C
root@rimmer:~/downloads/htc-desire#
Original comment by skanda...@gmail.com
on 30 Apr 2010 at 11:23
Attachments:
Just to confirm what skandalfo said:
I have a Desire and tried the same but from a Nokia N95, from a G1, an IPhone
and
from my desktop with a CSR bluetooth chip. I couldn't get an IP from the G1 and
the
IPhone and the Nokia.
From my desktop, I could add the device via bluetooth but it was being shown on
the
PAN devices list.
Original comment by emon...@gmail.com
on 1 May 2010 at 1:41
For me it is just the same as for skandalfo (running version 2.0.1 actually).
I hope this can be fixed soon.
This is what I captured on eth0 .. only ipv6?
# ./tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:17:53.217903 IP6 fe80::223:76ff:fedd:4889 > ff02::2: ICMP6, router
solicitation, length 16
00:17:57.254890 IP6 fe80::223:76ff:fedd:4889 > ff02::2: ICMP6, router
solicitation, length 16
./iwconfig eth000:17:58.307746 IP6 fe80::223:76ff:fedd:4889 > ff02::16: HBH
ICMP6, multicast listener
report v2, 1 group record(s), length 28
00:18:01.262275 IP6 fe80::223:76ff:fedd:4889 > ff02::2: ICMP6, router
solicitation, length 16
Cheers
Original comment by gae...@gmail.com
on 1 May 2010 at 10:26
Also, don't know if it helps but the attached file is the dmesg output when I
run the
tether from the gui.
Original comment by emon...@gmail.com
on 2 May 2010 at 11:44
Attachments:
Hi, I have the same issue on HTC Desire. I did some tests and here are my
findings, maybe helps debugging:
- started Tether, made the setup to use Wifi (as it is by default) and pressed
start.
- tried to connect from my laptop, but no IP was given by phone's DHCP server
- I've put on my laptop the IP 192.168.0.13/255.255.255.0, router 192.168.2.254
dns 192.168.2.254 (this
would be the phone Wifi ip address as discovered by issuing "ifconfig eth0" on
the phone)
- tried from laptop
\>ping 192.168.2.254
but no response.
- tried from phone
\>ping 192.168.2.13
and SURPRISE!! ping reports replies.
- then from laptop tried ping to phone, get a webpage...IT WORKS!!
Hope it helps.
Best regards,
Catalin P
Original comment by catalinp...@gmail.com
on 3 May 2010 at 7:14
[deleted comment]
@catalinpetrisor
I have tested your method by defining the static ip on my IPad and it os
WORKING!!! Yeah
Nothing happend untill i tried pinging the iPad ip, and then the message
"connecting" was showing on my
iPad, and a few sec later, it worked
Thank you very much m8 :-)
Original comment by smull...@gmail.com
on 3 May 2010 at 8:49
I can confirm the above behaviour.
I've experimented a little bit with arp tables. What I saw would suggest that
the
phone's wifi interface is not responding to ANY broadcast ethernet frame, be it
a
DHCP request or a even an ARP request.
The later is the reason the ping from the PC won't work until one is done from
the
phone fist. When the phone-to-PC ping is done, the ARP table in the PC is
primed with
the ping packet source addresses, so no ARP discovery is needed until the ARP
cache
entry expires and routing works.
Now we need to know what's happening, and whether it's a problem with Ad-Hoc
mode
only, and if it's a configuration problem that we can fix (but I can't really
imagine
how this behaviour could be configurable).
The other possibility is that this is a wifi driver shortcoming (read bug), and
then
we won't be able to do anything about it without using a custom patched kernel
:-(
Original comment by skanda...@gmail.com
on 3 May 2010 at 8:53
Hi Skandalfo,
I'm aware that maybe you don't have that phone to test (I don't believe this is
happening with the N1).
Just let me know if you need to modify any configuration or test a new app, I
can do
it here.
Cheers.
Original comment by emon...@gmail.com
on 3 May 2010 at 9:11
Hi, Emontes.
I don't understand what you mean...
I actually have an HTC Desire (and a Samsung Galaxy I7500, but that's another
story).
I don't have access to any Nexus One.
... and I'm not a developer of android-wifi-tether either (or at least not yet
;-) ).
About it not happening with the Nexus One, it probably doesn't happen, since it
seems
this application works for people.
I don't know. Perhaps a crude thing to test would be to grab the bcm4329.ko
(that's
the module with the wifi driver) from a Nexus One and hope the kernels of both
phones
are similar enough for it to load, in order to see whether it works. I won't
bet
about it, though.
Original comment by skanda...@gmail.com
on 3 May 2010 at 9:19
Ops, just confused you with harald.mue, he's the project owner, he was asking
you do
to some troubleshooting and you answered,
sorry mate :)
Reading a thread on Modaco, it seems that they don't have a Desire to test,
that's
why I asked if you need to test. (the question is directed to harald though).
About the N1, I tested with a friend and on his device wifi-tether works fine.
So, to clarify, if the owner needs to test anything on a Desire, I believe we
have a
lot of people that are keen to do it, just shout :)
Original comment by emon...@gmail.com
on 3 May 2010 at 9:32
Tried to load a bcm4329.ko from some Nexus One ROM after hacking the vermagic
to match
with an hex editor, but only got the phone to hang miserably. Had to remove the
battery.
Original comment by skanda...@gmail.com
on 3 May 2010 at 9:52
Wow ... if you ping a client from the phone first results to working tethering?
That's really weird.
And yes, this app is working absolutely fine on a NexusOne (I have one and it's
tested). I've even done some measurements regarding "reduce
transmitpower"-feature:
http://picasaweb.google.com/harald.mue/NexusOne
Anyway. The Desire has the same wifi-chip like the NexusOne (that's the reason
why
the wifi comes-up in adhoc-mode on the desire - that was implemented for the
NexusOne). It looks like "something" is blocking traffic and I have no idea
what that
is (has HTC already published kernel-sources for the desire?).
What you could try is the CyanogenMod-port (for desire) which was quickly thrown
together by modaco.
http://android.modaco.com/content/htc-desire-desire-modaco-com/307607/01-may-5-0
-6-test-r1-cyanogenmod-5-for-desire-online-kitchen/
This version is a very early test-release (it has some issues) ... so I would
backup
your current install before flashing.
Original comment by harald....@gmail.com
on 3 May 2010 at 10:15
I can confirm the above that WiFi tethering works using the ping method.
Installed wireless_thether_2_0-pre10.apk vi SD card.
1. Set WiFi Card static IP on the PC (Windows 7) to 192.168.2.100/24 with a
gateway of 192.168.2.254
2. Started WiFi Thether App with defaults only.
3. PC associates with the WiFi Tether access point.
4. Using a terminal emulator on the desire issued command 'ping -c 3
192.168.2.100'
5. No response to the ping command (100% packet loss)
6. A few seconds later the PC says its online.
7. Web page loaded (google.co.uk)
Original comment by bigreefb...@googlemail.com
on 3 May 2010 at 10:55
Hello Harald,
Just tested with cyanogenmod and the problem is the same, it doesn't work.
tcpdump can't see anything as well but if I set the IP manually and ping that
IP from
the phone then it works fine.
Weird isnt it? :)
Original comment by emon...@gmail.com
on 3 May 2010 at 11:24
Is there any other thing we can do to troubleshoot this?
Original comment by emon...@gmail.com
on 5 May 2010 at 7:36
Mmmmh ... I don't know. Maybe something with the kernel. Does the
modaco-cyanogen-port
contain a custom-kernel or the original one?
Original comment by harald....@gmail.com
on 5 May 2010 at 10:57
I believe it is the original one. The problem is exactly the same.
Original comment by emon...@gmail.com
on 6 May 2010 at 3:53
isnt the cyanogen mod a port of nexus one?
Original comment by larsmari...@gmail.com
on 6 May 2010 at 12:18
no, it's a bigger change than just that, but one way or another, that's not the
point. even if it were the same, the two phones have different kernels at a
lower
level so problems can still occur. by the looks of things, this is exactly
what the
problem is. it's not so much the overlaying OS, it's the differences in the
underlaying kernel (and obviously the fact that the developer doesn't have a
rooted
Desire to test and develop on)
Original comment by sead...@gmail.com
on 6 May 2010 at 12:23
No, I don't have a desire.
I've found this one:
http://forum.xda-developers.com/showthread.php?t=674218
This seems to be a CyanogenMod-port. And the cook of this rom says:
"Wifi Tether Works (only when u hav network Key on WEP)"
Can someone confirm this?
Original comment by harald....@gmail.com
on 6 May 2010 at 8:34
Have put wireless on WEP, set the passkey to a 13 letters combination and it
does NOT work. Ping method still
works, with or without WiFi encryption.
What can we do to help fixing this faster?
Original comment by catalinp...@gmail.com
on 6 May 2010 at 8:43
@catalinpetrisor: do you have a cyanogenmod-rom/port installed?
Original comment by harald....@gmail.com
on 6 May 2010 at 8:45
@harald.mue: nope, tried it on rooted stock rom
Original comment by catalinp...@gmail.com
on 6 May 2010 at 8:48
Once connected using the ping method from the device, you can make avoid this
step
in future by doing the following from a command prompt:
arp -a
copy the mac address for the 192.168.1.254 entry, then:
arp -s 192.168.2.254 MACADDRESS
or
netsh interface ip add neighbors "Wireless Network
Connection" "192.168.2.254" "MACADDRESS"
where MACADDRESS is the MAC Address copied earlier (in the form of
xx-xx-xx-xx-xx-
xx) and "Wireless Network Connection" is the name of the required network card
(found from ipconfig)
Original comment by adrian.w...@gmail.com
on 6 May 2010 at 11:06
@adrian: yeah, that makes sense. The problem is that I don't know the
mac-address of
the client (your pc, ipad or whatever) on startup. So, I don't see a way to add
this
static arp-entry out of the app as workaround.
Could someone provide the kernel-config?
Pulling the config from your device:
adb pull /proc/config.gz .
Upload it here please.
Original comment by harald....@gmail.com
on 7 May 2010 at 10:04
@harald
Please check attachment.
Original comment by catalinp...@gmail.com
on 7 May 2010 at 10:10
Attachments:
Harald,
I'm testing the cyanogenmod on my Desire with the WEP key. When I tested
without (as
per my previous post some days ago) it didn't work.
I will report in some minutes.
Original comment by emon...@gmail.com
on 7 May 2010 at 11:17
Problem is the same with Cyanogenmod-rom/port. Tried with and without a WEP key
and
unless I issue a ping on the IP address I set on the device trying to connect,
it
doesn't work.
Original comment by emon...@gmail.com
on 7 May 2010 at 11:40
@adrian
I don't what I am doing, but I get this response tryng arp -s etc etc
arp: SIOCSARP INVALID ARGUMENT
when you say 192.168.2.254 mac address do you mean the mac address for the
phone or for the ipad?!?
thank you!
Original comment by viscardi...@gmail.com
on 7 May 2010 at 2:31
[deleted comment]
What is the output of:
adh shell /data/data/android.tether/bin/iptables -L
before starting the app? Are there any iptables-rules? I just wonder why the
desire
comes with kernel which actually supports all netfilter features!?
Original comment by harald....@gmail.com
on 8 May 2010 at 4:52
[deleted comment]
Hello again.
even iptables is provided with the default system:
skandalfo@rimmer:~$ adb shell /data/data/android.tether/bin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
skandalfo@rimmer:~$ adb shell iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
skandalfo@rimmer:~$
As you can see it's in the path.
I suppose it's because the phone comes already with USB tethering, based in
rndis_host (emulates an ethernet card when
you plug the phone in "internet sharing" mode) and probably NAT + DHCP.
Original comment by skanda...@gmail.com
on 8 May 2010 at 7:10
I've looked at the output of iptables -L with the "internet sharing" activated.
I had to use ConnectBot, since adb gets disbled when enabling the
sharing option:
# ./iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
FIX ME! implement getprotobynumber() bionic/libc/bionic/stubs.c:378
TCPMSS tcp -- anywhere anywhere tcp
flags:SYN,RST/SYN TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
#
Original comment by skanda...@gmail.com
on 8 May 2010 at 7:31
And I found how to print the "nat" table while sharing:
# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
FIX ME! implement getprotobynumber() bionic/libc/bionic/stubs.c:378
FIX ME! implement getnetbyaddr() bionic/libc/bionic/stubs.c:366
DNAT udp -- anywhere 192.168.100.254 udp dpt:domain
to:87.216.1.65
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE 0 -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
#
Original comment by skanda...@gmail.com
on 8 May 2010 at 7:42
Good find. Mmmh ... this entry "TCPMSS tcp -- anywhere
anywhere
tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU" can be generated with a command
like:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
After reading
http://www.iptables.org/documentation/HOWTO/netfilter-extensions-HOWTO-
4.html (point 4.7) I don't think that this would make it work anyway.
Original comment by harald....@gmail.com
on 8 May 2010 at 9:38
Kernel is out:
http://member.america.htc.com/download/RomCode/Source_and_Binaries/bravo_54b7033
a.tar.gz
Any help?
Original comment by dkendall...@googlemail.com
on 14 May 2010 at 4:46
A rather quick cursory look seems to suggest that HTC did
several changes to the bcm4329 wifi driver. For instance they
#if-0'ed sections relative to ARP offload to the embedded wifi
firmware... This may well have something to do with the ARP
problems preventing wifi tether to work without a phone-to-
PC ping beforehand.
I'll try to actually diff the two kernels (desire and nexus one)
when I have time in order to see if I spot more differences
that may matter...
Original comment by skanda...@gmail.com
on 15 May 2010 at 9:15
I've done a diff now and I've found the if-0'ed sections in dhd_cdc.c as well.
BUT ... what the hell is "CONFIG_BCM4329_SOFTAP" (check wl_iw.c)! Master-mode?
That
would be great - replacement for infrastructure instead of ad-hoc!?!?
Original comment by harald....@gmail.com
on 17 May 2010 at 9:08
CONFIG_BCM4329_SOFTAP doesn't seem to be enabled in the stock-kernel. But
woohoooo ...
it's really interesting.
Original comment by harald....@gmail.com
on 17 May 2010 at 9:27
Original issue reported on code.google.com by
skanda...@gmail.com
on 29 Apr 2010 at 6:47