Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

all! I've been banging my head against a wall with this issue for a few days now and am hoping someone can help out.

I recently signed up for T-Mobile's webConnect 3G/4G service to replace the faltering (and slow) DSL connection in my apartment. The goal was to put the SIM in one of my old phones and use its built-in WLAN tethering feature to share Internet out to rest of my computers. I quickly found out that webConnect-provisioned SIMs do not work with regular smartphones, so I was forced to either buy a 4G-compatible router or tether one of my old laptops to my wireless router and share out that way. I chose the latter, and it's sharpening my inner masochistic self by the day.

Here's the setup:

  • GSM USB modem (via hub), ICS host ->
  • 10/100 Mbps Ethernet NIC, ICS "guest" ->
  • WAN port of my SMC WGBR14N wireless router in bridged mode (i.e. wireless access point).
Ideally, this would make my laptop the DHCP server and internet gateway with the WAP giving everyone wireless coverage. I can browse internet on the host laptop fine.

However, when clients try to connect, they get a DHCP-assigned IP from the laptop and are able to use the Internet for a few minutes before completely dying. After that happens, they are able to re-associate with the WAP and get IP addresses, but are unable to use Internet or resolve IP addresses until the laptop and router are restarted. If they do get access, it's very, very slow. After running Wireshark on the host machine, it turns out that this is because every TCP connection keeps getting RST. DNS seems to work.

I would normally think the firewall is the culprit here, but when it drops packets, it drops them completely. The fact that TCP connections are being ACK'ed by the destination rules that out. Of course, none of the event Log isn't saying anything about what's going on. I also tried disabling power management on the NIC, since that's caused problems in the past; that didn't help either. I finally disabled receive-side scaling as per a Microsoft KB (that applied to Windows Server 2003, SP2) to no avail. I'm thinking of trying it with a different NIC (will be tough; don't have a spare Ethernet NIC around for the laptop), but I'm getting the impression that this simply doesn't work.

Can anyone please advise? I apologise for the length of this post; all contributions are much appreciated!


share|improve this question

It sucks that this didn't get a lot of attention, but then again, normal folks have some sort of dedicated connection instead of this setup.

After playing around with it for a good while, I'm finally convinced that ICS is fundamentally broken. It seems that its biggest problem is with the stability of the built-in ICS DHCP server. Sometimes, DHCP will try to work but will route DHCP requests to the hosting NIC instead of serving DHCP requests on its own. I would get link-local addresses when this happens. Other times, the DHCP server will quit working entirely by letting DHCP requests go completely unanswered. I think these two problems happen in succession, but not too sure.

I have no idea why the TCP connections start RSTing after a while. I noticed some errors from Tcpip in event viewer, so I think it has something to do with winsock getting corrupted. Now that I think about it, perhaps the DHCP issues are related to that as well.

The only way I was able to get this to work with some stability is by doing the following:

  • Stopping ICS by unsharing my connection from the modem,
  • Disabling both NICS,
  • Resetting winsock by using netsh (netsh winsock reset). I don't reboot.
  • Re-enabling both NICs, and finally
  • Re-enabling ICS by sharing the modem connection again.

With this in mind, is there any way to enable winsock logging to see whether the underlying issue presents itself there?

Combined with everything else I did, I have no idea how long this will work for. Hopefully, it'll work long enough to set me over until I get the Cradlepoint modem I bought.

Hope this helps someone!

share|improve this answer
Update: It only worked for a few hours. Not only did the clients drop off after I woke up this morning, the computer was rendered pretty much unusable. I couldn't start Task Manager, nor could I shut it down cleanly. As I expected, it worked fine after a restart. – Carlos Nunez Apr 1 '11 at 14:04

ICS uses a fixed IP range, if I'm not mistaken (I could be). Make sure this does not conflict with the IP/subnet on your SMC WGBR14N.

It is also possible your 4G modem may be detecting the TTL of outgoing traffic and eventually terminating connections or dropping its PPP session if the TTL isn't what it suspects, this is a way to discover if traffic is originating from the connected system or one "behind" it.

share|improve this answer
I think the subnet of the router is irrelevant here as the router runs in AP mode, but the TTL detection is certainly a possibility. @Carlos Nunez You could try running a HTTP proxy on your "host" computer instead and if that works, you have to change the default TTL on the "guest" computers. Note that the NAT can still be detected due to the way TCP sequence numbers on some systems, but that technique is less used. – Apr 15 '12 at 1:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .