On 10/26/2012 02:16 AM, Bjørn Mork wrote:
"Shawn J. Goff" <shawn.goff@xxxxxxxxxxxxx> writes:
After the failure happens, I can see from USB traces (and this is with
an external USB sniffer) ARP requests going out and nothing coming in
-
so it seems like it's not a case of dropping URBs.
Does the modem respond to other packets than ARP? It is a point to point
link, and the ethernet header is just a dummy anyway, so you can turn
off ARP on the interface and test.
Here is a ping just after failure, then after disabling ARP, then some
dhcp discovers (ping + tcpdump + usbmon):
# ping 4.2.2.4
PING 4.2.2.4 (4.2.2.4): 56 data bytes
00:44:56.237688 ARP, Request who-has 21.44.110.21 tell 21.44.110.22,
length 28
c293e560 2696237824 S Bo:1:004:6 -115 42 = ffffffff ffffc2b4 b64e6f90
08060001 08000604 0001c2b4 b64e6f90 152c6e16
c293e560 2696238062 C Bo:1:004:6 0 42 >
00:44:57.240239 ARP, Request who-has 21.44.110.21 tell 21.44.110.22,
length 28
c293e560 2697240365 S Bo:1:004:6 -115 42 = ffffffff ffffc2b4 b64e6f90
08060001 08000604 0001c2b4 b64e6f90 152c6e16
c293e560 2697240561 C Bo:1:004:6 0 42 >
00:44:58.242664 ARP, Request who-has 21.44.110.21 tell 21.44.110.22,
length 28
c293e560 2698242776 S Bo:1:004:6 -115 42 = ffffffff ffffc2b4 b64e6f90
08060001 08000604 0001c2b4 b64e6f90 152c6e16
c293e560 2698242931 C Bo:1:004:6 0 42 >
--- 4.2.2.4 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
#
# ip link set dev wwan0 arp off
#
# ping 4.2.2.4
PING 4.2.2.4 (4.2.2.4): 56 data bytes
--- 4.2.2.4 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
# ip route add 4.2.2.4 dev wwan0
#
# ping 4.2.2.4
PING 4.2.2.4 (4.2.2.4): 56 data bytes
00:45:23.338147 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768,
seq 0, length 64
c293e560 2723338296 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90
08004500 00540000 40004001 b161152c 6e160402
c293e560 2723338573 C Bo:1:004:6 0 98 >
00:45:24.341673 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768,
seq 1, length 64
c293e560 2724341810 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90
08004500 00540000 40004001 b161152c 6e160402
c293e560 2724342064 C Bo:1:004:6 0 98 >
c293e560 2725342353 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90
08004500 00540000 40004001 b161152c 6e160402
c293e560 2725342625 C Bo:1:004:6 0 98 >
00:45:25.342202 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768,
seq 2, length 64
c293e560 2726342907 S Bo:1:004:6 -115 98 = c2b4b64e 6f90c2b4 b64e6f90
08004500 00540000 40004001 b161152c 6e160402
c293e560 2726343058 C Bo:1:004:6 0 98 >
00:45:26.342757 IP 21.44.110.22 > 4.2.2.4: ICMP echo request, id 53768,
seq 3, length 64
--- 4.2.2.4 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
#
# udhcpc -i wwan0
udhcpc (v1.19.4) started
Sending discover...
c293e360 2776988614 S Bo:1:004:6 -115 322 = ffffffff ffffc2b4 b64e6f90
08004500 01340000 00004011 79ba0000 0000ffff
c293e360 2776988803 C Bo:1:004:6 0 322 >
00:46:16.988471 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from c2:b4:b6:4e:6f:90, length 280
Sending discover...
c293e360 2779998437 S Bo:1:004:6 -115 322 = ffffffff ffffc2b4 b64e6f90
08004500 01340000 00004011 79ba0000 0000ffff
c293e360 2779998561 C Bo:1:004:6 0 322 >
00:46:19.998288 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from c2:b4:b6:4e:6f:90, length 280
At the point when
things stall out, I don't see anything special happening - there's a
large file that is downloading (lots of IN packets) that suddenly
stops while the tty port keeps chatting normally. I can also provide a
trace from the external sniffer if it's interesting, but here is a
usbmon trace of the failure: http://sprunge.us/ORQE . The last
incoming message from the wwan endpoint (2:8) is at 1555583640.
I may very well be wrong, but to me this looks like the modem just stops
responding for some reason. I have no idea why.
That's what I gathered as well; it's perplexing and I'm not really sure
where to go from there.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
