On Fri, 2012-10-26 at 10:08 -0400, Shawn J. Goff wrote: > 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. Without direct support from the vendor you pretty much have to flail around in the dark, trying a bunch of different things that might make the modem less angry, and hope one of them works... :( Dan -- 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
