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

04
2013-08
  • ventaur

    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
    • Answers
  • mas

    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.

  • David Schwartz

    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:

    1. Disable the DHCP server in your Netgear router.

    2. Disconnect the Netgear router's Internet/WAN port.

    3. 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.

  • ventaur

    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.


    • Related Question

    networking - How to block/avoid a particular IP when connecting to websites?
  • Mark

    I'm having trouble connecting to a particular website. I can view it through a proxy, but not from home. So I ran a traceroute:

    Tracing route to fvringette.com [76.74.225.90]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  <snip>
  2     *        *        *     Request timed out.
  3     9 ms     7 ms    27 ms  rd2bb-ge2-0-0-22.vc.shawcable.net [64.59.146.226]
  4     8 ms     7 ms     7 ms  rc2bb-tge0-9-2-0.vc.shawcable.net [66.163.69.41]
  5    10 ms     9 ms     9 ms  rc2wh-tge0-0-1-0.vc.shawcable.net [66.163.69.65]
  6    27 ms    23 ms    22 ms  ge-gi0-2.pix.van.peer1.net [206.223.127.1]
  7    18 ms    18 ms    20 ms  10ge.xe-0-2-0.van-spenc-dis-1.peer1.net [216.187.89.206]
  8     9 ms    11 ms    10 ms  64.69.91.245
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
...

    Looks like this "64.69.91.245" is somehow blocking me. Can I tell my computer to avoid/bypass that IP when trying to connect?


    • Related Answers
  • squircle

    For one, I can load the site fine. See the route:

    0 04:35:23pm ~ $ mtr -4 --report fvringette.com
HOST: Defcon.local                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. woodcrest.local               0.0%    10    0.6   0.5   0.4   0.8   0.1
  2. bas1-oakville30_lo0_SYMP.net  0.0%    10   14.0  16.1  13.1  31.2   5.4
  3. core1-hamilton14_10-0-3_150.  0.0%    10   13.3  12.8  11.6  15.7   1.1
  4. newcore1-chicago23_so2-0-0.n  0.0%    10   23.6  31.4  23.6  66.3  16.0
  5. bx5-chicagodt_xe-0-0-3_0.net  0.0%    10   24.7  24.6  23.2  28.5   1.6
  6. ge-3-2-4.chi10.ip4.tinet.net  0.0%    10   26.7  26.9  26.3  28.0   0.5
  7. xe-2-0-0.sea11.ip4.tinet.net  0.0%    10  107.0 106.8 106.0 107.5   0.4
  8. peer1-gw.ip4.tinet.net        0.0%    10   83.9  83.9  83.6  84.6   0.3
  9. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
 10. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
 11. 64.69.91.245                  0.0%    10   88.6  87.9  87.1  88.6   0.6
 12. van-hc21e-cs1.wappyzappy.net 10.0%    10   88.7  88.0  87.4  88.7   0.5

    It would appear that (somehow) the two nodes, 9 & 10 in my route, are either blocking ICMP packets or have some other form of network voodoo implemented. It could be that when you were accessing the site through the proxy, you were accessing some cached version when the website was really down, who knows. The fact that there is 100% packet loss in nodes 9 & 10 is odd, but since I can (obviously) reach the site, it doesn't appear that 64.69.91.245 (Peer1 Internet Bandwidth & Server Co-Location Facilities, 2155-500 West Hastings St., Vancouver) is doing anything to block any traffic (in all likelihood, they are just ignoring ICMP packets).

    To more directly answer your question, it's pretty much impossible to define your own route to a site. Since (I would assume) all packets would pass through that address at one point or another to get to the actual host (as it's the external IP of the datacentre the servers are hosted in), there would be no route around it. Once your packet gets outside of your router, it's up to Shaw what route your packet takes; you have no control whatsoever. Hope that helps a bit!

  • raw_noob

    I think you can do this by forcing a particular IP routing using the route add command at the command prompt, but it will take a better man than I am to explain exactly how. You might do a search on 'add a static IP route' or 'force IP routing' to get some idea. I don't know if you can block a specific node, but I wouldn't be surprised if you can. Forcing a specific route that avoids the node would be the alternative.

  • Blackbeagle

    Are you going to a site that is somehow geographically restricted? There are sites that will only accept traffic from certain regions and if your IP address is not within their allowed list, the packets may be eaten. The reason I'm asking is that you said you can access through a proxy.