D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: fgl30 on March 06, 2008, 12:19:17 PM
-
Why router connect (without my request) to mcleodusa.net domain? What this means? How is the functio connection to ip 63.253.14.xx???? Iīm very concerned about this kind of attitud/connection...... ???.....I need some light here....
-
Thats a UPnP request. It's normal.
-
Could you, please explain me a little better? Why UPnP need such request over net? If I turn off UPnP so, DIR-655 will not make this connection? Thx for attention
-
Thats not your router, it's your PC I believe.
-
FYI there is a but of a stir about what some of these firewall reports are, though this guy doesn't cite very good examples in the thread I am about to link. This needs to be cleared up:
http://www.dslreports.com/forum/r20071221-Flaw-Security-Dlink-DIR655-Router-with-implant-backdoor
-
Iīm pretty sure isnīt my PC.... I donīt use UPnP in any of my computers.... plus, why my PC could connect a D-Link domain? Isnīt D-Link owner of McLeodUSA company?
-
Upon further inspection, we have determined that it is the router. However it's intended. I forwarded the link to the forum post to the PM gourp responsible for that product and it's currently being reviewed.
Thank you for your attention.
-
I read the thread. ::)
I promise to stop eating chocolate for a month. If there is a "true" security problem (ie: realistically exploitable).
-
I don't get it. Why report anything to the product team if it is "as intended?"
Regardless -- I'm glad that you did forward the report. This has to be a bug -- it may simply be that something is being incorrectly displayed (which is how I'm leaning, as packets captured in the log are generally the packets that are NOT going through).
The original DSLReport's post (which is very confusing) suggests that something is egressing out the WAN side. But other than that first reporter, nobody else is seeing anything of major concern.
Anyway, thanks for forwarding it along.
-
I read the thread. ::)
I promise to stop eating chocolate for a month. If there is a "true" security problem (ie: realistically exploitable).
well, I donīt think your answer is serious... I really donīt care about your chocolates, I care about security router problem, that you doesnīt explain nothing..... Lycan, at least acept that there is some problem.... is a start... deny an obvious thing is not good... it seems "Received Deauthentication" problem is not alone....
-
This is one topic I am very interested in, and quite frankly, has me concerned. The DSL Reports thread was an interesting read. Thanks for he link.
-
I read the thread. ::)
I promise to stop eating chocolate for a month. If there is a "true" security problem (ie: realistically exploitable).
Hi do you have a update on this issue?
can you give us a better description of the mechanism involved here ?
I understand you don't think it's a security issue, and I concur, but it would be best to descrive how the process is working , and how several options within the router can cause these reports to appear, last I wonder WHY Dlink management has not bothered to rename the mcleod site to something like mcleod.dlink.com so users of their equipment won't panic so much.
thanks
-
Hi do you have a update on this issue?
can you give us a better description of the mechanism involved here ?
I understand you don't think it's a security issue, and I concur, but it would be best to descrive how the process is working , and how several options within the router can cause these reports to appear, last I wonder WHY Dlink management has not bothered to rename the mcleod site to something like mcleod.dlink.com so users of their equipment won't panic so much.
thanks
After reading the thread on dslreports, I get the impression that there is not a definitive answer as to whether this is a security concern.
An update would be welcome...
-
Not to jump Lycan thunder.
To the ones that hated my Chocolate for Security issue comment:
I guess you have to do some deep thinking to find what I meant. To clarify: I read the DSL reports thread. I don't think it is a security issue. If you talk to SAM have him send his report to D-Link US corporate email address attn: Director of Technical Services.
We will do a scan of the WAN side of the router to find out what really is "reporting home" with default settings. They we will also perform a capture with settings our fine level headed forums users report drive the problem. Then we will figure out why the results are what they are and change code as necessary to reach our expected function if it isn't doing it already.
To the ones that want D-Link to change the name of the IP resolution to a D-Link name:
That won't happen in the near future. It belongs to the co-location that hosts our NTP servers. We lease the space and bandwidth.
If you aren't talking about the sites, we use then look for a virus on your LAN.
-
"We will do a scan of the WAN side of the router to find out what really is "reporting home" with default settings."
@AWDL: could you, please, clarify to me how you plan to perform that scan?
-
For the WAN problem report:
t1->Switch A port 1
WAN port -> Switch A port 2
Wireshark Comp -> Switch A port 3
Configure Switch A port 2 (or ALL ports) to be mirrored to port 3
If that doesn't work, we'll substitute a hub for the switch.
You you have a Favorite config that causes strange Logs or WAN side traffic let Lycan know.
The router log complaints weren't as clear, but at some point a new thread will have to start separating the two problem reports so that we can get the results. I have a DIR-655 frimware 1.10 HW rev A1 and I don't have funny log entries (all check marks except informational), so I can't be the point of clarity.
-
... We will do a scan of the WAN side of the router to find out what really is "reporting home" with default settings. They we will also perform a capture with settings our fine level headed forums users report drive the problem. Then we will figure out why the results are what they are and change code as necessary to reach are expected function if it isn't doing it already. ...
Hi,
So it would be correct to say that we can expect a more detailed answer, regarding this issue, here in the forum?
Thanks.
-
Hi,
So it would be correct to say that we can expect a more detailed answer, regarding this issue, here in the forum?
Thanks.
He will try to sniff communication between router-hub/switch and see if anything is wrong....
-
We will do a scan of the WAN side of the router to find out what really is "reporting home" with default settings. They we will also perform a capture with settings our fine level headed forums users report drive the problem. Then we will figure out why the results are what they are and change code as necessary to reach our expected function if it isn't doing it already.
Was there ever any progress on this?
-
Not yet. I am looking for a report on Monday. I would also encourage anyone who has a confiruation that can make the device report strange traffic to a scan to let us know the config and may be even give us the capture. I have only seen expected functionality or Vague details when it comes to the traffic initiated by the router out the WAN port.
Even this thread is weak an any points to a thrid party thread that doesn't have any meat to it.
We are just looking at the traffic as we don't have a clear, detailed scenerio to replicate. I hope the techno-geeks out there understand.
-
@AWDL: please, donīt losse you focus... it must be mcleodusa.net .....
-
Not yet. I am looking for a report on Monday. I would also encourage anyone who has a confiruation that can make the device report strange traffic to a scan to let us know the config and may be even give us the capture. I have only seen expected functionality or Vague details when it comes to the traffic initiated by the router out the WAN port.
Even this thread is weak an any points to a thrid party thread that doesn't have any meat to it.
We are just looking at the traffic as we don't have a clear, detailed scenerio to replicate. I hope the techno-geeks out there understand.
AWDL,
I have Rev A3 with the 1.11 US Bios, and I see the Inbound connection from 63.253.14.236 to 63.253.14.240 as reported by the router. However, using an ethernet tap catching traffic in both directions for a 7 hour period on the WAN side, I saw no traffic to or from either of these IPs. I scoured the entire Wireshark log files for the 7 hour period and postively accounted for every single outbound packet. During this same time, the router logged dozens of these packets on the LAN side and passed them to a PC running Wallwatcher.
It really seems like a firmware glitch, and I am reasonably convinced there is no backdoor, and no actual connection from the router to any of these addresses (at least in my case). However, I readily admit that I am far from being an expert on this. I'll happily submit submit log files (WAN Side or LAN side) and details of my router config to DLINK tech support for further analysis. If you have any particular instructions before I do another capture please let me know.
Incidentally, I posted under the alias Zoinks in the thread on DSLReports.com.
-
@AWDL: please, donīt losse you focus... it must be mcleodusa.net .....
Sorry, I lost focus. We use partner services that include mcleodusa.net. We co-loc our NTP server. I am still trying to figure out if there is a connection. What a thought was a no brainer is not? Mcleodusa.net has IP all over the range and I can't confirm the end-user of the range 63.253.14.236 to 63.253.14.240.
I have Rev A3 with the 1.11 US Bios, and I see the Inbound connection from 63.253.14.236 to 63.253.14.240 as reported by the router. However, using an ethernet tap catching traffic in both directions for a 7 hour period on the WAN side, I saw no traffic to or from either of these IPs. I scoured the entire Wireshark log files for the 7 hour period and postively accounted for every single outbound packet. During this same time, the router logged dozens of these packets on the LAN side and passed them to a PC running Wallwatcher.
I thought this was an outbound question. Device calling home and all that? And you see the IP on the router logs, not on a WAN side capture? Did you have this on the 1.10 firmare as well? I am running HW REv A1, Firmware 1.10 and don't see this in my logs (all checked except informational). I guess I should start with and upgrade to 1.11 (I hate fixing things that are broken).
-
63.253.14.236 to 63.253.14.240 for Cable connections and 155.x.x.x and other from DSL connections are showing up in logs if "informational" is checked. We are looking into gettting a complete list of the IP addresses used for QOS baseline.
We will also look to see if these also show up on firmware 1.10, since 1.10 and 1.11 is the same reference code.
I will check the the "informational" box on my logs to look for 1.10fw consitancy as well. then I will have PM remove the informational option if possible.
-
AWDL,
I haven't tried the 1.10 Firmware since I bought my DIR-655 after the 1.11 version came out.
I think there are a few people who think their router is "phoning home" but I haven't seen any evidence of this other than the anomolous log entries, but as I mentioned, I don't see these connections on the WAN side. The person who claimed the router phoned home posted a log file (on the DSLREPORTS thread) that was obviously from Wallwatcher. I think they may have the WallWathcer software set to "Convert IP addresses to URLs" which I suspect would then generate the "suspicious" outbound traffic.
I only became concerned after I read the thread on DSLReports that posted very similar log entries to mine, and claimed their router had a back door. I was concerned enough that I built my own ethernet tap to monitor that WAN connection. Since my paranoia has dipped back down to normal levels, I only posted to help try to resolve this issue.
[edit: just saw your followup reply, but decided to post anyway]
-
Polydactyl,
The product supervisor may still contact you off thread to get your logs and what not. If we find what we expect in the code, we will either explain or change it, or explain it and change it.
Thank you for the clarification on the outbound/inbound situation. I thought the DSL reports (SAM??) person was a little hard to translate and he started with a rant which by forum law isn't helpful. He sounded educated but then made sweeping claims like my wife, so he got discounted pretty quickly. The only he said that we are still looking at is the IP addresses (plus a few maore).
What I have seen is not an exploitable security hole. If those are the addresses we use for QOS timing then you all may be stuck with them. We probably check timing even if QOS is disabled (not used), so that won't stop your router from knowing it connection speed. We should let you know if that is the case, when we get the development report.
-
If I may, I believe that even with the QoS disabled the router still sends a request for uplink measurement. However like the NTP it is simply ignored by the router upon return.
The only way to know for sure is to look at the unit at the SDK or code level and see if those ips correlate to SDK programming. I'm betting we'll see that they are indeed intended and needed for some low level QoS functionality. Its easier to create code where the routers operation is the same even if the function ( in this QoS) is disabled. That way the boot sequence and the basic funcitons of the unit remain integral. It also allows for engineers to create base codes that are easy to work with and powerful for the end user.
AWDL has requested that the code be examined for the IP to learn their true nature, please be patient and try not to stress on it to much until we get those answers.
Also thank you for all the feed back and support of the product that the forum users have provided, it's been a great help.
-Peas
-
I just finished reading this thread & the dslreports thread. Sounds like this is likely a non-issue, however, from the last 2 entries it's not entirely clear that a final resolution was ever posted. It looks like you guys think it's related to the QoS bandwidth check, or possibly some leftover dev code maybe, but it seems to trail off back in March, with no clear explanation. Is there any update to this?
In particular, I'd like to see something along the lines of:
1. Does this occur in 1.11 firmware (if so, which countries).
2. General explanation of whether or not you guys reproduced this & what it is & if it's fixed (if needed), or will it be fixed.
3. Was a connection ever really established or attempted, or is this just an errant set of messages.
4. If this is related to the QoS startup, why does it sound like, from prior people's postings, that it is occuring throughout the day rather than just at modem reboot?
5. Exactly which models of dlink does this occur in .. I have an A2, an A3, a DI-LB604, and several others than I can't remember and now I'm a little concerned ... to be honest, I'm more concerned about the response to the problem than the issue itself since I think it's likely not a big deal ..... but, with no clear resolution, who knows....
Would appreciate any type of final clear Dlink statement on this.... thanks a bunch (from a big Dlink fan, fyi).
ps - If I can violate forum policy here & tack on a couple of quick suggestions:
1) it would be nice to be able to turn on logging of good packets, if desired, rather than just dropped packets.
2) Can you add a Search-capability to the Knowledge Base (http://support.dlink.com/supportfaq/) .. it'd be a heckuva lot more useful (or point it out if there is one).
Thanks!
Dylan Tynan
dtynan@gmail.com
now w/Cadence
prev w/Motive
-
The end result was that when packet captures were done it was determined that the router will use a HEX based algorithm to generate a random public IP, then ping that IP to determine up-link speed. This feature is inherent to the SDK and can not be disabled.
It in no way poses any type of security threat or hole.