Why does tracert not work when connected via wireless, but works when wired?

If my laptop is connected to my new Netgear router via wireless, all tracert commands display my router's IP address for hop #1, then timeouts for all remaining hops. If I connect to my router via wire, the tracert commands act as expected (displaying each hop's resolution with latency).

Any idea why this is?

Wireless Traceroute:

Tracing route to www.l.google.com [74.125.113.99]
over a maximum of 30 hops:

  1     1 ms    <1 ms    11 ms  192.168.x.x 
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14    32 ms    32 ms    33 ms  vw-in-f99.1e100.net [74.125.113.99] 

Trace complete.

Wired Traceroute:

Tracing route to www.l.google.com [74.125.91.103]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.x.x 
  2     1 ms     1 ms     1 ms  10.1.10.1 
  3    15 ms    32 ms    70 ms  98.211.90.1 
  4    26 ms     8 ms    11 ms  te-8-3-ur01.mycity.md.bad.comcast.net [68.85.134.125] 
  5    17 ms    13 ms    18 ms  69.139.174.210 
  6    15 ms    13 ms    30 ms  69.139.174.190 
  7    22 ms    29 ms    13 ms  pos-5-1-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.90.241] 
  8    35 ms    15 ms    15 ms  pos-0-1-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.30] 
  9    64 ms    78 ms    73 ms  75.149.231.62 
 10    20 ms    57 ms    34 ms  209.85.252.80 
 11    49 ms    45 ms    30 ms  209.85.248.75 
 12    27 ms    44 ms    32 ms  209.85.254.237 
 13    48 ms     *       34 ms  209.85.240.57 
 14   100 ms    29 ms    43 ms  qy-in-f103.1e100.net [74.125.91.103] 

Trace complete.

Detailed IPConfig (of the 2 adapters):

Windows IP Configuration

   Host Name . . . . . . . . . . . . : MyPCName
   Primary Dns Suffix  . . . . . . . : 
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
   Physical Address. . . . . . . . . : xx-xx-xx-xx-xx-xx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : xxxx::xxxx:xxxx:xxxx:xxxx%12(Preferred) 
   IPv4 Address. . . . . . . . . . . : 192.168.x.yyy(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, September 07, 2011 5:13:55 PM
   Lease Expires . . . . . . . . . . : Thursday, September 08, 2011 8:04:49 PM
   Default Gateway . . . . . . . . . : 192.168.x.x
   DHCP Server . . . . . . . . . . . : 192.168.x.x
   DHCPv6 IAID . . . . . . . . . . . : 289954617
   DHCPv6 Client DUID. . . . . . . . : xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
   DNS Servers . . . . . . . . . . . : 192.168.x.x
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Wireless Network Connection:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Atheros AR9285 Wireless Network Adapter
   Physical Address. . . . . . . . . : xx-xx-xx-xx-xx-xx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : xxxx::xxxx:xxxx:xxxx:xxxx%11(Preferred) 
   IPv4 Address. . . . . . . . . . . : 192.168.x.zzz(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, August 30, 2011 9:39:45 AM
   Lease Expires . . . . . . . . . . : Thursday, September 08, 2011 7:35:50 PM
   Default Gateway . . . . . . . . . : 192.168.x.x
   DHCP Server . . . . . . . . . . . : 192.168.x.x
   DHCPv6 IAID . . . . . . . . . . . : 192213101
   DHCPv6 Client DUID. . . . . . . . : xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
   DNS Servers . . . . . . . . . . . : 192.168.x.x
   NetBIOS over Tcpip. . . . . . . . : Enabled

ventaur

Posted 2011-09-07T01:09:56.500

Reputation: 166

It's taking a different route and the 2nd and subsequent hops are blocking ping or there's an issue with how they respond to ping requests. See here for sum suggestions ... http://superuser.com/q/278952/16600

– Rhys Gibson – 2011-09-07T01:19:47.340

1Can you post the two traceroutes? – MaQleod – 2011-09-07T03:51:40.667

Since the traceroute works when wired, I'm suspect of Rhys' theory. Posting the traceroutes for all to see. – ventaur – 2011-09-07T20:55:05.563

Well, the destination is different, so it is definitely a different route. Timeouts on ICMP are not uncommon (many routers either just drop them by default or only echo back if they have nothing better to do). As far as why there is a different route, we'd have to look at your computer/router config to see. Are these results always the same (ie the same destination IP for wired and wireless respectively)? What does your ipconfig look like on your computer? What DNS servers are you using? Is there a modem on the other side of your router that is in routed mode? – MaQleod – 2011-09-07T23:54:52.503

The same type of results occur even when the destination IP is the same (for a site not as spread out as Google's). For example, ie6update.com always routes to the same IP (at least, it does right now), yet I get timeouts for all hops until the destination when wireless and I get replies for all hops when wired. – ventaur – 2011-09-08T00:10:25.337

I am using Google's DNS via my router (8.8.8.8 and 8.8.4.4). There is a modem on the other side of the router. It is a Comcast business-class modem I had recently installed for working from home. I noticed after the tech left that the modem was also a router, but the tech put it on a different subnet (as expected). – ventaur – 2011-09-08T00:12:38.970

My IPConfig is posted in the question now. – ventaur – 2011-09-08T00:12:54.943

Answers

Oddly enough, disabling DCHP off then back on again (on the modem/router) corrected the issue and everything started working properly. It was likely the need to reboot all network devices that fixed this.

Thanks for all your help and consideration of this problem.

ventaur

Posted 2011-09-07T01:09:56.500

Reputation: 166

You have double-NAT. This is a disfavored configuration that can cause all kinds of problems. In this specific case, it seems that your second NAT device can't figure out how to get the ICMP replies back to your machine.

There is actually a known issue in many Netgear routers involving improper bridging of wireless nodes. Wired nodes are bridged in hardware, wireless nodes in software. Their software bridging tries to understand some protocols (notably DHCP and ICMP) and sometimes decides to process, rather than bridging, some packets.

The simplest fix for you is probably:

Disable the DHCP server in your Netgear router.
Disconnect the Netgear router's Internet/WAN port.
Connect one of the Netgear router's LAN ports to one of the modem/router's LAN ports.

This uses the Netgear router strictly as a switch and access point. If you'd prefer to use the Netgear router to route, you need to find out how to change your modem/router to a bridge.

David Schwartz

Posted 2011-09-07T01:09:56.500

Reputation: 58 310

This makes sense. The most recent change was a switch from residential cable to business-class cable. That change came with a new modem and I'd bet the tech. set it up on a different sub-net without disabling the router functionality of the modem. – ventaur – 2011-09-15T23:40:00.713

Check if your new modem has something called "gateway smart packet detection". If so, turn it off. – David Schwartz – 2011-09-15T23:46:36.667

It is a very dumbed-down interface with no such options. Here is the modem: http://www.smc.com/index.cfm?event=viewProduct&localeCode=EN_USA&cid=2&scid=20&pid=1678. It appears that Comcast has completely replaced the management GUI as well. I think I'm stuck changing my router to act as a switch to get around the issue; not really pleased with that.

– ventaur – 2011-09-16T12:58:49.953

I actually did find this option and it was already disabled; "Disable Gateway Smart Packet Detection" has been checked the entire time. – ventaur – 2011-09-16T13:02:34.113

This behaviour is seen when the first gateway (in this case the wireless network side of the router is set to not issue/retransmit/forward ICMP TIME_EXCEEDED messages. (traceroute depends on these for the increasing IP protocol time to live (TTL) fields set in its outgoing requests to know the IP address and round-trip-time for each gateway on the path to the host). This is done for a mix of performance and security reasons. It may be possible to adjust the handling of these (and other) ICMP packets in the router set-up.

The times and IP addresses for the first and last entries are known from the IP address of the host and the IP address of the furst gateway.

mas

Posted 2011-09-07T01:09:56.500

Reputation: 2 431

I'll look around the wireless settings some more to see if there is anything I can override here and come back with results. – ventaur – 2011-09-15T23:37:55.757

I cannot find anything specific for ICMP with the wireless settings on my router. I've never really learned about fragmentation length, CTS/RTS threshold, and preamble mode. Other than security settings, those are the only other wireless-specific settings I can find. – ventaur – 2011-09-16T13:15:05.763