idVendor 0x0bb2 Ambit Microsystems Corp. idProduct 0x6098 USB Cable Modem bcdDevice 1.01 In the case below, the USB cable modem is eth1, the network card is eth0. If a simple network is setup: echo 1 > /proc/sys/net/ipv4/ip_forward iptables -F iptables -t nat -F iptables -A FORWARD -i eth0 -j ACCEPT iptables -A FORWARD -o eth0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE A ping from an internal machine works fine. $ ping google.com PING google.com (74.125.226.144) 56(84) bytes of data. 64 bytes from 74.125.226.144: icmp_req=1 ttl=52 time=17.6 ms 64 bytes from 74.125.226.144: icmp_req=2 ttl=52 time=18.8 ms Traceroute works as well. But, any attempt at anything else (wget, firefox) results in dropped traffic. tcpdump of eth1 reveals the traffic goes out and the webserver (google in this case) responding. However, the traffic goes no further than arriving at eth1. # netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 644035 0 0 0 528553 0 0 0 BMRU eth1 576 0 1773855 6509 0 0 552506 0 0 0 BMRU lo 16436 0 7307 0 0 0 7307 0 0 0 LRU Rx errors are very high on eth1 and climb steadily with each attempt by an internal machine to access something over the network. Otherwise, the device appears to perform normally, and fetching data on the gateway box from remote sites works fine.
Possibly related, and appeared at the same time as the switch to cdc_ether From an internal machine. $ ping -c 4 -i 0.5 google.com PING google.com (74.125.226.144) 56(84) bytes of data. 64 bytes from 74.125.226.144: icmp_req=1 ttl=52 time=18.8 ms 64 bytes from 74.125.226.144: icmp_req=2 ttl=52 time=17.1 ms 64 bytes from 74.125.226.144: icmp_req=3 ttl=52 time=19.6 ms 64 bytes from 74.125.226.144: icmp_req=4 ttl=52 time=19.4 ms --- google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 15177ms rtt min/avg/max/mdev = 17.121/18.774/19.667/0.999 ms From the gateway machine. $ ping -c 4 -i 0.5 google.com PING google.com (74.125.226.144) 56(84) bytes of data. 64 bytes from 74.125.226.144: icmp_req=1 ttl=53 time=18.0 ms 64 bytes from 74.125.226.144: icmp_req=2 ttl=53 time=17.6 ms 64 bytes from 74.125.226.144: icmp_req=3 ttl=53 time=18.6 ms 64 bytes from 74.125.226.144: icmp_req=4 ttl=53 time=17.6 ms --- google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 1512ms rtt min/avg/max/mdev = 17.614/17.996/18.642/0.443 ms 10x longer (!)
Eh. That last one appears to be a DNS problem. Presumably unrelated, although that hasn't changed recently either.
Hm. Another curiosity in the mystery of the broken masquerading. Things like wget still fail. wget http://google.com --2011-02-03 17:20:33-- http://google.com/ Resolving google.com... 74.125.226.146, 74.125.226.145, 74.125.226.148, ... Connecting to google.com|74.125.226.146|:80... connected. HTTP request sent, awaiting response... But, I notice it only fails after an initial connect! Additionally, here's my connection to netserver.hedgewars.org (for playing Hedgewars) :) $ __GL_SYNC_TO_VBLANK=1 ./hedgewars Server: ("CONNECTED", "Hedgewars server http://www.hedgewars.org/") Client: ("NICK", "nemo") Client: ("PROTO", "37") Server: ("NICK", "nemo") Server: ("PROTO", "37") Server: ("ASKPASSWORD") Client: ("PASSWORD", "<snip>") And then it hangs! Basically, it works for a little bit, then stops. If I check out on the gateway machine, I see: # tcpdump -an -i eth1 | grep 140.247.62.101 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4e01397 specified for 0x4e0184b (Mot de pas). 17:22:28.974389 IP 68.49.110.130.55653 > 140.247.62.101.46631: S 636452153:636452153(0) win 5840 <mss 1460,sackOK,timestamp 38442752 0,nop,wscale 6> 17:22:28.998058 IP 140.247.62.101.46631 > 68.49.110.130.55653: S 2877102509:2877102509(0) ack 636452154 win 5792 <mss 1460,sackOK,timestamp 221260545 38442752,nop,wscale 7> 17:22:28.998427 IP 68.49.110.130.55653 > 140.247.62.101.46631: . ack 1 win 92 <nop,nop,timestamp 38442758 221260545> 17:22:29.024053 IP 140.247.62.101.46631 > 68.49.110.130.55653: P 1:55(54) ack 1 win 46 <nop,nop,timestamp 221260552 38442758> 17:22:29.024427 IP 68.49.110.130.55653 > 140.247.62.101.46631: . ack 55 win 92 <nop,nop,timestamp 38442765 221260552> 17:22:29.024696 IP 68.49.110.130.55653 > 140.247.62.101.46631: P 1:22(21) ack 55 win 92 <nop,nop,timestamp 38442765 221260552> 17:22:29.048052 IP 140.247.62.101.46631 > 68.49.110.130.55653: . ack 22 win 46 <nop,nop,timestamp 221260558 38442765> 17:22:29.049051 IP 140.247.62.101.46631 > 68.49.110.130.55653: P 55:66(11) ack 22 win 46 <nop,nop,timestamp 221260558 38442765> 17:22:29.088092 IP 68.49.110.130.55653 > 140.247.62.101.46631: . ack 66 win 92 <nop,nop,timestamp 38442781 221260558> 17:22:29.110064 IP 140.247.62.101.46631 > 68.49.110.130.55653: P 66:89(23) ack 22 win 46 <nop,nop,timestamp 221260573 38442781> 17:22:29.110424 IP 68.49.110.130.55653 > 140.247.62.101.46631: . ack 89 win 92 <nop,nop,timestamp 38442786 221260573> 17:22:30.702858 IP 68.49.110.130.55653 > 140.247.62.101.46631: P 22:65(43) ack 89 win 92 <nop,nop,timestamp 38443184 221260573> 17:22:30.928087 IP 68.49.110.130.55653 > 140.247.62.101.46631: P 22:65(43) ack 89 win 92 <nop,nop,timestamp 38443241 221260573> 17:22:30.951115 IP 140.247.62.101.46631 > 68.49.110.130.55653: . ack 65 win 46 <nop,nop,timestamp 221261033 38443241,nop,nop,sack 1 {22:65}> And then it stops. That last response back from the server never makes it to me, and the client simply hangs after attempting to send the password message. The odd thing is how repeatable it is.
Oh, and wireshark reports the last 2 1633 6.225089 10.0.0.4 140.247.62.101 TCP [TCP Retransmission] 33185 > 46631 [PSH, ACK] Seq=22 Ack=89 Win=5888 Len=43 TSV=39058379 TSER=221875679 1638 6.248097 140.247.62.101 10.0.0.4 TCP [TCP Previous segment lost] 46631 > 33185 [ACK] Seq=971 Ack=65 Win=5888 Len=0 TSV=221875974 TSER=39058379 SLE=22 SRE=65 Those last 2. Retransmission/segment lost, are repeated every time. Aaaand, in case this helps at all, here's what I see on the client side (inside the local network, versus what the gateway interface reports. # tcpdump -an -i eth1 | grep 140.247.62.101 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 18:09:41.373857 IP 68.49.110.130.48684 > 140.247.62.101.46631: S 2094859431:2094859431(0) win 5840 <mss 1460,sackOK,timestamp 39150852 0,nop,wscale 6> 18:09:41.394917 IP 140.247.62.101.46631 > 68.49.110.130.48684: S 39670552:39670552(0) ack 2094859432 win 5792 <mss 1460,sackOK,timestamp 221968417 39150852,nop,wscale 7> 18:09:41.395302 IP 68.49.110.130.48684 > 140.247.62.101.46631: . ack 1 win 92 <nop,nop,timestamp 39150857 221968417> 18:09:41.417920 IP 140.247.62.101.46631 > 68.49.110.130.48684: P 1:55(54) ack 1 win 46 <nop,nop,timestamp 221968423 39150857> 18:09:41.418292 IP 68.49.110.130.48684 > 140.247.62.101.46631: . ack 55 win 92 <nop,nop,timestamp 39150863 221968423> 18:09:41.418537 IP 68.49.110.130.48684 > 140.247.62.101.46631: P 1:22(21) ack 55 win 92 <nop,nop,timestamp 39150863 221968423> 18:09:41.443919 IP 140.247.62.101.46631 > 68.49.110.130.48684: . ack 22 win 46 <nop,nop,timestamp 221968429 39150863> 18:09:41.444915 IP 140.247.62.101.46631 > 68.49.110.130.48684: P 55:66(11) ack 22 win 46 <nop,nop,timestamp 221968429 39150863> 18:09:41.484641 IP 68.49.110.130.48684 > 140.247.62.101.46631: . ack 66 win 92 <nop,nop,timestamp 39150880 221968429> 18:09:41.544919 IP 140.247.62.101.46631 > 68.49.110.130.48684: P 66:89(23) ack 22 win 46 <nop,nop,timestamp 221968454 39150880> 18:09:41.545289 IP 68.49.110.130.48684 > 140.247.62.101.46631: . ack 89 win 92 <nop,nop,timestamp 39150895 221968454> 18:09:43.165289 IP 68.49.110.130.48684 > 140.247.62.101.46631: P 22:65(43) ack 89 win 92 <nop,nop,timestamp 39151300 221968454> 18:09:43.392604 IP 68.49.110.130.48684 > 140.247.62.101.46631: P 22:65(43) ack 89 win 92 <nop,nop,timestamp 39151357 221968454> 18:09:43.416976 IP 140.247.62.101.46631 > 68.49.110.130.48684: . ack 65 win 46 <nop,nop,timestamp 221968922 39151357,nop,nop,sack 1 {22:65}> on gateway, versus an internal side of... #tcpdump -an | grep 46631 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 18:09:00.678385 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [S], seq 1443639824, win 5840, options [mss 1460,sackOK,TS val 39140678 ecr 0,nop,wscale 6], length 0 18:09:00.701277 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [S.], seq 3705373227, ack 1443639825, win 5792, options [mss 1460,sackOK,TS val 221958247 ecr 39140678,nop,wscale 7], length 0 18:09:00.701295 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [.], ack 1, win 92, options [nop,nop,TS val 39140684 ecr 221958247], length 0 18:09:00.726259 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [P.], seq 1:55, ack 1, win 46, options [nop,nop,TS val 221958253 ecr 39140684], length 54 18:09:00.726275 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [.], ack 55, win 92, options [nop,nop,TS val 39140690 ecr 221958253], length 0 18:09:00.726532 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [P.], seq 1:22, ack 55, win 92, options [nop,nop,TS val 39140690 ecr 221958253], length 21 18:09:00.749272 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [.], ack 22, win 46, options [nop,nop,TS val 221958259 ecr 39140690], length 0 18:09:00.750250 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [P.], seq 55:66, ack 22, win 46, options [nop,nop,TS val 221958259 ecr 39140690], length 11 18:09:00.788885 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [.], ack 66, win 92, options [nop,nop,TS val 39140706 ecr 221958259], length 0 18:09:00.814272 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [P.], seq 66:76, ack 22, win 46, options [nop,nop,TS val 221958275 ecr 39140706], length 10 18:09:00.814282 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [.], ack 76, win 92, options [nop,nop,TS val 39140712 ecr 221958275], length 0 18:09:04.035390 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [P.], seq 76:89, ack 22, win 46, options [nop,nop,TS val 221959080 ecr 39140712], length 13 18:09:04.035415 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [.], ack 89, win 92, options [nop,nop,TS val 39141517 ecr 221959080], length 0 18:09:05.258404 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [P.], seq 89:95, ack 22, win 46, options [nop,nop,TS val 221959385 ecr 39141517], length 6 18:09:05.258418 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [.], ack 95, win 92, options [nop,nop,TS val 39141823 ecr 221959385], length 0 18:09:06.045662 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [P.], seq 22:71, ack 95, win 92, options [nop,nop,TS val 39142020 ecr 221959385], length 49 18:09:06.268982 IP 10.0.0.4.46813 > 140.247.62.101.46631: Flags [P.], seq 22:71, ack 95, win 92, options [nop,nop,TS val 39142076 ecr 221959385], length 49 18:09:06.295448 IP 140.247.62.101.46631 > 10.0.0.4.46813: Flags [.], ack 71, win 46, options [nop,nop,TS val 221959645 ecr 39142076,nop,nop,sack 1 {22:71}], length 0
Tried 2.6.37 (not that I saw any activity with cdc_ether in there) No change
Created attachment 48152 [details] kernel config Attaching my kernel config, 2.6.37 version, in case it offers any clues.
FWIW, I gave up on this configuration, mostly due to the problems listed above, so I can't really test it anymore. Hopefully the information given is sufficient - not that anyone ever looked at it :)