Mystery: DIR-655 sending out blocked pings with nothing attached

Discussion in 'hardware' started by mossyrock, Sep 17, 2012.

Thread Status:
Not open for further replies.
  1. mossyrock

    mossyrock Registered Member

    Joined:
    Sep 17, 2012
    Posts:
    2
    Location:
    US
    Hi,

    I looked through all of the forum categories and this looked to be the best place to post this question.

    I have two D-Link DIR-655 routers, identical versions, and both have been flashed with the latest firmware. Both have identical configurations.

    One router has been in production for quite a while, the other I was preparing as a spare.

    I was testing each one separately, of course (both of them were not online at the same time).

    I decided to take a look at the logs of both and saw something that needed investigating - I noticed that both routers are pinging and receiving connection attempts from unexplained addresses. Thinking that something bad was on my network somewhere, but confused as to why the source addresses of the outbound pings didn't show a LAN address, I started eliminating each LAN client, one by one, until the outbound pings stopped so I could find out what computer or device is generating the pings.

    Well, I got to the point where there was nothing connected to the router at all, and the wireless was off, but the outbound pings continued and so did the inbound connection attempts. I performed the same experiment/process on the other router and the results are identical except the IP address involved is different. It's like those external IP addresses are hard-coded into the routers firmware!

    I can understand the inbound connection attempts continuing, but where could outbound pings originate from when there is nothing connected to the routers (except the modem, of course). During the testing, I rebooted the routers several times and the behavior continued with no LAN clients and wireless off. When LAN clients are connected, the behavior continues as well, identically.

    Both the pings and the connection attempts are being dropped, and they don't appear to be synchronized in any way. The outbound pings occur every two minutes like clockwork. The inbound connection attempts are more random.

    Here are excerpts from my routers' logs. I've obscured my IP address below with x's. Note the pings don't show a LAN address - they show my IP address as assigned by my ISP (DHCP).

    Router A:
    info [ 810.090000] '[DROPPED-PACKET]:'IN= OUT=eth0.1 SRC=24.113.xx.xx DST=71.60.105.215 PROTO=ICMP TYPE=3 CODE=3
    Sep 17 06:22:13
    info [ 925.980000] '[DROPPED-PACKET]:'IN=eth0.1 OUT= SRC=71.60.105.215 DST=24.113.xx.xx PROTO=TCP SPT=1756 DPT=6346
    Sep 17 06:22:56

    Router B:
    info [ 6328.720000] '[DROPPED-PACKET]:'IN= OUT=eth0.1 SRC=24.113.xx.xx DST=198.254.177.79 PROTO=ICMP TYPE=3 CODE=3
    Sep 17 12:09:38
    info [ 5904.310000] '[DROPPED-PACKET]:'IN=eth0.1 OUT= SRC=198.254.177.79 DST=24.113.xx.xx PROTO=TCP SPT=2926 DPT=35491
    Sep 17 12:16:32

    In both routers, the "Enable WAN Ping Respond" setting is unchecked (OFF).

    Again, the outbound pings are being sent out every two minutes, apparently not in response to the inbound connection attempts.

    I called D-Link tech support and got escalated to level 2 but they had no idea of what is causing this. I called my ISP just to check if those two IP addresses are somehow related to their network, and of course, they aren't.

    I see that port 6346 is involved with file sharing, but no, I'm not involved with anything like this. The other port 35491, is unlisted as to its purpose.

    GRC Shields Up! shows those destination ports as stealthed on my router/LAN.

    Those destination ports also do not show up an any netstat results (-b, -an, -ao) on any machine.

    Any ideas of what is happening here? There is probably a simple explanation but it is escaping me.

    Many thanks!
     
  2. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Check whether you have time server unchecked
     

    Attached Files:

  3. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    It is the firmware. Cannot remember the reason now or where it went. It was not something that I wanted, so I flashed back. That was a year or two ago. I am using v.1.21, and I have hardware vA4. To flash back I had to get a specific firmware version, which would allow the lower versions to be installed. I did this on both DIR-655's that I use.

    I cannot recall exactly, but I think I got a lot of this info from the Dlink forum.

    Sul.
     
  4. mossyrock

    mossyrock Registered Member

    Joined:
    Sep 17, 2012
    Posts:
    2
    Location:
    US
    Thanks, folks.

    I have NTP server ntp.dlink.com.tw selected and neither of those addresses correspond with that timeserver. The ntp1.dlink.com NTP server doesn't work.

    Those two addresses were malicious machines on the net.

    However, I believe I've found the problem. It looks to be a logging issue. I reset the router to default configuration and let it run for a while without any clients, then connected and examined the logs.

    I found in the log perfectly matched pairs of dropped incoming connection requests and dropped outgoing ICMP type=3 code=3 replies, until the log filled up and older entries started being dropped off. (With only 25 pages available, it didn't take long).

    After that, I was seeing what appeared to be a slightly scrambled log: there were no longer perfectly matched pairs but seemingly random entries which had led me to believe that the router was spontaneously generating these pingbacks ahead of the connection attempts. I was seeing blocked connection attempts without blocked pingbacks, and blocked pingbacks without any trigger. In reality, some log entries apparently are being dropped.

    Another screwy thing is how the router reports pingbacks in the log when you have "Enable WAN Ping Respond" unchecked, meaning that the router should remain silent as to replies. What happens is that the router generates a reply (in this case an ICMP type=3 code=3 (destination unreachable, port unreachable)) but then blocks its own reply, and reports it as blocked. It would make much more sense to just not generate the reply at all instead of generating all those unnecessary log entries.

    I've wasted about 10 hours on this wild goose chase, but feel good to put this behind me.
     
    Last edited: Sep 19, 2012
Loading...
Thread Status:
Not open for further replies.