D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: netdevil on October 29, 2008, 11:15:12 AM
-
HI everybody,
I am having major difficulties with my DIR-655 router. I am using a VoIP hardware device (Fritz!Box FON) which for some strange reason will only work with firmware 1.11 (I tried both 1.20 and 1.21, both failed to work). With the 1.11 firmware, however, wireless networking only works occasionally - either the WLAN card (with a Ralink chipset) cannot establish any network connection, or do so only after at least 5 attempts, sometimes even more than 10. I have tried multiple operating systems, all have the same problem. With the newer firmwares the WLAN works flawlessly - but I cannot get the VoIP to work. I have enabled port forwarding (3478,3479,5060-5070,10000-30000,21,53,69,123) and have set UDP endpoint filtering to "Endpoint Independent" - this setting works under fw 1.11 but not under anything newer.
I have googled for this to no avail. Do you have any suggestion what I can do? I already contacted my VoIP provider and it is certainly a local router problem.
???
Thanks!
Edit: Also tried DMZ, turned SIP ALG off ... nothing.
Edit 2: OK - this is too weird: went back to 1.11 and WLAN seems to work for now... any suggestions as to what could be the problem with 1.21 though?
-
I believe starting with version 1.20, Port Forwarding basically does not work. Actually, it's worse than that. It prevents the creation of port mappings that would normally be created on-demand, when LAN nodes initiate communication with the internet, if these mappings are listed under Port Forwarding.
Use 1.11 or use Virtual Server to pass through NAT.
-
I would have to agree that firmware past 1.11 has issues.
-
I tried it again, this time used the 1.21B08 firmware and following the suggestion for a workaround in another thread disabled DNS Relay. This made one of my two voip providers work - though my VoIP device reported a connection to both servers, the calls were not routed through both inbound and outbound... so back to 1.11 it is once more...
The WLAN issue is not completely resolved either - I occasionally get disconnects. I do not think it is a problem of the operating system (Ubuntu), but I think it's router related. I'll post a log next time it happens.
This is really a shame... I am getting closer to buying a new router... Is there any new firmware coming that might solve some of these issues? There seem to be sooooo many users with problems.
-
Status update:
I tried again after our line constantly appeared to be busy to callers... I tried the NEWEST 1.21 firmware (Nov. 13 from the DLINK ftp server), I changed port forwarding to Virtual Server... nothing. I tried with restoring the factory defaults and then setting up the rules again, then turning off the power to make sure it really rebooted, nothing. The calls are not going through. I also had to turn off the DNS relay as I was experiencing like 5-10sec wait until the connection was established... switched over to OpenDNS and to my providers DNS site and it worked.
PLEASE, does anybody have any idea what else I could do or try? I am about to try to return this damn router... :-\
My setup is very simple: I have one WLAN device, one networked computer, and one VoIP Device (FritzBox)... it should not be such a difficult thing to get the port forwarding to function?? The only firmware it seems to work with (not perfectly, but at least mostly functional) is 1.11
@Moderators: Can't you find out what has changed since regarding DNS relay, port forwarding and ask them to fix it?? ???
-
Netdevil, is anything NOT working if DNS Relay is turned off?
-
Hi funchords,
if DNS Relay is turned off the port forwarding is still not working... so I am not sure whether that is really the cause for all the trouble as you're suggesting... though I am pretty sure it has something to do with it.
One scenario of what happens is this: there seems to be a delay up to 30 sec until the packets actually get to the VoIP device, so the caller gets no answer or a busy signal, while my phone starts to ring 30sec later and nobody's on the line.
Another is that there is no reaction whatsoever...
I am basically still stuck with 1.11 but would call the performance sub-optimal at best. At least its useable.
I can try to post a log from 1.21, but that means having no telephone for at least 1 h - and from what I can tell it is not really all that informative...
-
I think I know why you're getting the 30 second delay. If 1.11 is working, then don't mess with it.
But if you're already messing with 1.21 someday, turn off DNS relay and ALSO restart your VOIP device and other computers (make sure clients get good DNS settings that point to actual DNS servers and not the router).
If this helps its because the DNS Relay in the DIR-655 is failing with certain lookups (NXDOMAIN at least). DNS lookups are a blocking action for some software and network devices, either programmatically (the program waits for a response before executing the next instruction) or naturally (you can't go to www.google.com until it is translated into an IP address by DNS) -- as a result, while an outstanding DNS query exists, these programs have to wait for the response. This might also be a blocking action in the DIR-655 itself, if it is programmed to complete all queries in serial order then it would have to wait for a delayed response before it could process the next one. As a result, many interactive uses (such as web surfing, game playing, file transferring) that is waiting on a DNS query to continue will tend to stall.
-
Hi funchords, hello everybody else,
I did try the DNS relay and restart thing, for some reason it did not work. I also checked the log again today (back at 1.11, HW A3) and found that the SIP ALG rejects a whole bunch of packages - could that be a reason why the phone line appears to be busy if somebody is trying to call us?
here is some part of the log (I took out the parts concerning the other network devices) - what I find strange is that sometimes these rejections appear to be repeated 10 times or more:
[INFO] Tue Dec 02 10:55:37 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:55:05 2008 Above message repeated 10 times
[INFO] Tue Dec 02 10:55:05 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:54:57 2008 Above message repeated 2 times
[INFO] Tue Dec 02 10:54:53 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:54:49 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:54:45 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:54:41 2008 Above message repeated 1 times
[INFO] Tue Dec 02 10:54:37 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:54:33 2008 Above message repeated 3 times
[INFO] Tue Dec 02 10:45:48 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:45:16 2008 Above message repeated 10 times
[INFO] Tue Dec 02 10:27:32 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:27:00 2008 Above message repeated 10 times
[INFO] Tue Dec 02 10:27:00 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:26:35 2008 Above message repeated 6 times
[INFO] Tue Dec 02 10:26:31 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:26:28 2008 Above message repeated 3 times
[INFO] Tue Dec 02 10:18:15 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:17:51 2008 Above message repeated 6 times
[INFO] Tue Dec 02 10:17:47 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:17:44 2008 Above message repeated 2 times
[INFO] Tue Dec 02 10:17:43 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 10:00:17 2008 Above message repeated 2 times
[INFO] Tue Dec 02 09:59:26 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:58:55 2008 Above message repeated 10 times
[INFO] Tue Dec 02 09:58:54 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:58:23 2008 Above message repeated 10 times
[INFO] Tue Dec 02 09:50:42 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:50:11 2008 Above message repeated 10 times
[INFO] Tue Dec 02 09:31:21 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:31:17 2008 Above message repeated 1 times
[INFO] Tue Dec 02 09:31:13 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:30:49 2008 Above message repeated 8 times
[INFO] Tue Dec 02 09:30:49 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:30:17 2008 Above message repeated 10 times
[INFO] Tue Dec 02 09:23:10 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:22:38 2008 Above message repeated 10 times
[INFO] Tue Dec 02 09:04:10 2008 Above message repeated 2 times
[INFO] Tue Dec 02 09:03:15 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:03:07 2008 Above message repeated 2 times
[INFO] Tue Dec 02 09:03:03 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:02:59 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:02:55 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:02:44 2008 Above message repeated 5 times
[INFO] Tue Dec 02 09:02:43 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 09:02:12 2008 Above message repeated 10 times
[INFO] Tue Dec 02 08:55:37 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:55:09 2008 Above message repeated 7 times
[INFO] Tue Dec 02 08:55:07 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:35:09 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:34:39 2008 Above message repeated 8 times
[INFO] Tue Dec 02 08:34:38 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:34:38 2008 Above message repeated 1 times
[INFO] Tue Dec 02 08:34:37 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:34:06 2008 Above message repeated 10 times
[INFO] Tue Dec 02 08:28:04 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:27:32 2008 Above message repeated 10 times
[INFO] Tue Dec 02 08:07:02 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:06:30 2008 Above message repeated 10 times
[INFO] Tue Dec 02 08:06:30 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 08:05:58 2008 Above message repeated 10 times
[INFO] Tue Dec 02 08:00:30 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:59:58 2008 Above message repeated 10 times
[INFO] Tue Dec 02 07:38:56 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:38:24 2008 Above message repeated 10 times
[INFO] Tue Dec 02 07:38:24 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:38:11 2008 Above message repeated 3 times
[INFO] Tue Dec 02 07:38:07 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:38:03 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:37:52 2008 Above message repeated 5 times
[INFO] Tue Dec 02 07:32:56 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:32:25 2008 Above message repeated 10 times
[INFO] Tue Dec 02 07:10:49 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:10:45 2008 Above message repeated 1 times
[INFO] Tue Dec 02 07:10:41 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:10:37 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:10:18 2008 Above message repeated 7 times
[INFO] Tue Dec 02 07:10:17 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:09:46 2008 Above message repeated 10 times
[INFO] Tue Dec 02 07:09:05 2008 Above message repeated 1 times
[INFO] Tue Dec 02 07:05:22 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 07:04:51 2008 Above message repeated 10 times
[INFO] Tue Dec 02 06:42:43 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:42:11 2008 Above message repeated 10 times
[INFO] Tue Dec 02 06:42:11 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:42:07 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:41:39 2008 Above message repeated 9 times
[INFO] Tue Dec 02 06:37:49 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:37:17 2008 Above message repeated 10 times
[INFO] Tue Dec 02 06:14:36 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:14:05 2008 Above message repeated 10 times
[INFO] Tue Dec 02 06:14:04 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:13:33 2008 Above message repeated 10 times
[INFO] Tue Dec 02 06:10:15 2008 SIP ALG rejected packet from 192.168.0.102:5060 to XXX.XXX.XXX.XXX:5060
[INFO] Tue Dec 02 06:09:43 2008 Above message repeated 10 times
The rejections concern both my VoIP providers. Any idea what causes them? It seems to be an awful lot...
I sure would appreciate any help!
-
Do you have some PC or device active in DMZ?
-
No...
-
I just posted a new message on this topic - I should have checked deeper into the messages before adding a new one...
For what it is worth netdevil, I see the exact same problem. I run an Asterisk server for my house and use a SIP trunk for connection to the PSTN. Using anything past 1.11 appears to be hopeless. I tried all the same configuration tricks, even putting the server into the DMZ (which I did only for testing purposes) to no avail. It appears as if the SIP INVITE hits my server quickly, but my server has problems getting the OK back.
I'm not real happy with 'finding a version of the firmware that works for you and stick with it', Versions 1.20 and 1.21 seem just plain broken. I'd like the Guest Account and the SharePort capabilities.....
-
I did try the DNS relay and restart thing, for some reason it did not work. I also checked the log again today (back at 1.11, HW A3) and found that the SIP ALG rejects a whole bunch of packages - could that be a reason why the phone line appears to be busy if somebody is trying to call us?
My memory is getting foggy on this issue, but memory is that something works inversely here --
It's either disabling the SIP ALG that solves it, or if that doesn't help, then re-enable the SIP ALG but disable the SPI function of the firewall.
-
@StephanFr - I am inclined to say "FINALLY SOMEBODY WHO TELLS ME I AM NOT CRAZY" - while at the same time it is pretty sad that these issues are out in the open and nobody seems to be doing anything about them.
@funchords - If I remember correctly I tried to turn of the SIP ALG, which did not do anything. I"ll give the other one a shot.
@ALL: I second StephanFr's "I'm not real happy with 'finding a version of the firmware that works for you and stick with it', Versions 1.20 and 1.21 seem just plain broken. I'd like the Guest Account and the SharePort capabilities....."!!!
-
@ALL: I second StephanFr's "I'm not real happy with 'finding a version of the firmware that works for you and stick with it', Versions 1.20 and 1.21 seem just plain broken. I'd like the Guest Account and the SharePort capabilities....."!!!
If they are broken, the issue should be a generic one. And VOIP (sip) and WLAN work fine on version 1.21 with my Acer laptop and desktop....how could that be?
-
@Eddie: Do you think then it's actually a hardware problem that would justify a RMA? I am not a network professional but have worked with computers for two decades or more... I have tried everything I could think of and hope I have documented my attempts sufficiently. I have owned several routers and have never had any problems like this. In short: if anybody will tell me what's wrong, I'll shut up ;)
PS: Does anybody have any suggestions for a CHEAP VoIP hardware box (available in Canada) that I could get to see whether the problem is my VoIP device? I don't want to spend even more money for nothing, that's why I am asking. Mind you, I've been using the VoIP box for close to 4 years now without any prior problems...
-
@funchords - If I remember correctly I tried to turn of the SIP ALG, which did not do anything. I"ll give the other one a shot.
Read http://www.dslreports.com/forum/r21532822-msg which suggests that both SIP and DNS Relay ought to be disabled -- at least for his VOIP.
Good luck!
-
Thanks funchord! I know this thread but I didn't check for two days... I'll give it a shot tonight and will post if that helps.
Maybe we should open a new thread with "Known Issues and Solutions"? People could respond there if something worked or didn't for them and DLINK could finally try to figure out the cause in order to fix it... Ideally this would be a sticky thread so that anybody would find it immediately...
-
@EddieZ - Are you running a SIP client (like the Vonage Softphone) or a SIP PBX? Netdevil and I are trying to run SIP PBXs behind the DIR 655. There is a big difference between running a client out through the router and running a server which has to be accessible to the world behind the router. I doubt there would be problems with a softphone.
@netdevil - If you have a spare computer handy you might want to try TrixBox. It is an Asterisk based appliance and I believe the download is free. Alternatively you could download and build Asterisk. You will need a Linux box ready. The build is easy enough, the configuration of the dialplan can be a hassle.
What irks me about this is that a fairly obvious bug in the DNS Relay issue not only made it out of Engineering and through QA without being caught in V1.20, but it remained in place in V1.21. It looks to me like sometime mid-year Product Management decided that SharePort and SecureSpot needed to be added to the product before Christmas buying begins, so they hurried out another firmware release, propagating a serious bug.
Fact is that these problems should be fixed. It shouldn't be necessary, nor incumbent on the customer, to have to experiment with varying multiple configuration parameters or scour forums to learn the secret settings necessary to get the product to work as advertised.
-
@StephanFr: I hear ya and agree 100%! OK, make it 200%!
About Asterisk: I am running only Linux systems anyway, so that sounds like an idea - especially with a nice little Atom board that is good on energy - hmm... could also run a VDR (or PVR) on it... the only problem then is that I have to buy a VoIP phone. Or are there adapters that I could use, i.e. USB? I guess I'll google for it a little.
Nonetheless, the optimal solution would be for DLink to get the bloody firmware working... there are enough indications out there where the source of the problem might be - so get at it boys (and girls, of course)!!!
-
netdevil - if you want to play with Asterisk, you can always use a softphone as well. I think CounterPath still makes a free softphone called X-Lite. There are a couple other freeware softphones as well, SJPhone comes to mind. I build Asterisk on Fedora.
For PVR I actually use a pair of Windows solutions: SnapStream's BeyondTV for recording and TVersity for UPNP streaming. BeyondTV is licensed, TVersity is free. On linux there is MythTV. I tinkered with it years ago and it looked interesting but was still a bit unbaked. I imagine it is far better now.
I may break down any try tinkering one last time with DNS Relay, SIP ALG, etc. We have visitors frequently enough that the guest zone is very handy. My wife started getting very irritated with the phone service instability, so if I do start fiddling with the DIR 655 settings again, I'll watch it like a hawk.
-
@EddieZ - Are you running a SIP client (like the Vonage Softphone) or a SIP PBX? Netdevil and I are trying to run SIP PBXs behind the DIR 655. There is a big difference between running a client out through the router and running a server which has to be accessible to the world behind the router. I doubt there would be problems with a softphone.
I'm running a SIP client, not a PBX. So I am not a good reference.
@ StephanFr:
Fact is that these problems should be fixed.
True. What's broken must eb fixed.
It shouldn't be necessary, nor incumbent on the customer, to have to experiment with varying multiple configuration parameters or scour forums to learn the secret settings necessary to get the product to work as advertised.
Unfortunately each LAN or even WAN modem connection has its own way of influencing the settings/functioning of a router. Running a SIP PBX, for example, is still not a standard home activity. The router works out-of-the-box 8 out of 10 times is my estimation (perhaps the Dlink guys have some estimates on that). I've seen (and fixed) many situations in which the user is a n00b and hasn't got a clue what's happening. They just marked some options because 'some folks or forums' told him this was a good setting.
-
Is it just me or are you guys also wondering if any of the Mods / DLink Tech people actually read this thread? It'd be nice to get some feedback that would indicate at least recognition of the problem and attempts to fix the problem...
I am pondering the purchase of a PAP2T right now to replace my SIP PBX and see if that makes any difference - the decision would be much easier, however, if I knew the router would work properly... right now I have a feeling that it would not make any difference at all...
-
Maybe some patience...it's not IM... ;D Maybe you're the only one having this specific issue...
Why interfere when co-users might be able provide a solution?
-
Well - generally you're right, but the fact that StephanFr is reporting the exact same issues, and that others are reporting issues that track to the same root gives me reason to think that I am not the only one with that problem - otherwise I'd send my router in and let them have a look at it...
I didn't mean to appear impatient - I'd just like to hear a quick acknowledgement that DLink is at least aware that SOME users are having that issue... Mind you, there is of course nothing wrong with co-users helping!
-
It's not unusual for techs to be bound to policy about promising fixes or setting expectations about updates -- but I'd also like to hear if this report has been escalated internally.
-
From a common sense point of view I think not everything is being escalated immediately when one or two people have an issue. If they would, they would get a s**tload of issue to work on (even the job of finding out if it is a router issue or a user/environment issue would take them days per issue to reproduce probably) What would you do if it was your company, you sold over 100.000 devices and when two people have an issue...?
Not speaking on behalf of Dlink but when you look at these client expectations closely, these are sometimes too high.
-
Not speaking on behalf of Dlink but when you look at these client expectations closely, these are sometimes too high.
I am not sure how exactly to respond to this - I do not think that asking them to look into an issue that appears quite central - DNS Relay and Port Forwarding - and is a basic feature of a network router amounts to "too high expectations". Mind you, if DLink considers this to be too much then I'll consider it too much to ever buy any of their products again.
I realize that there are some issues that people raise that fall under the category you refer to, and that there are some people that are not very understanding and cooperative about that. But I do not think that something that works under one version of a firmware and does not under another is part of that category. Additionally, it's not as if we're saying "My internet does not work, please fix it" but we've narrowed the issue down quite a bit. And though it may not be "a standard home activity" to run a PBX just yet - in Europe it's becoming more and more common and will happen over here too.
Anyway - I'm not asking for promises, I just wanted to know if they are aware of the fact that some users are experiencing this problem and have informed the technical developers of it.
Doing this is more than "a s**tload of work" - it's called customer service that produces a positive side-effect: think of the nice advertising possibility it would offer to put on a box: "Supports VoIP"
-
I'm in Europe, I'm in IT and trust me, running a PBX is not even close to being mainstream/"common".
Knowing this, your issue is still kind of rare (2 people thusfar with this issue). Just send on of the tech guys a PM or something. Much more effective I would say, and more productive than complaining about a lack of attention on a board. ;)
-
Eddie, I'm shocked.
Had I not seen your response with my own eyes, I would have said that someone who was both blind and deaf would by now simply have to be intentionally ignoring the enormous evidence submitted that DNS Relay is broken.
STEPS to reproduce:
1. Perform a query that would result in an NXDOMAIN response
2. Unit waits for several seconds before returning response
Repeat those steps using the same DNS on a client, and the response typically comes back immediately.
That's it. My own post to this effect is in one of the stickied threads at the top of this forum.
-
Eddie, I'm shocked.
Had I not seen your response with my own eyes, I would have said that someone who was both blind and deaf would by now simply have to be intentionally ignoring the enormous evidence submitted that DNS Relay is broken.
STEPS to reproduce:
1. Perform a query that would result in an NXDOMAIN response
2. Unit waits for several seconds before returning response
Repeat those steps using the same DNS on a client, and the response typically comes back immediately.
That's it. My own post to this effect is in one of the stickied threads at the top of this forum.
Surprisingly, I never mentioned that DNS Relayisn't broken. Or did I overlook some lines I wrote?
You were talking about VOIP/PBX, and the lack of attention for your PBX issue, remember?
So don't be shocked. And concerning DNS Relay, look around in the topics and you will find that you're one of many that mention this issue. Do you really expect Moderators to reply everytime a question is repeated again and again?
-
Eddie - PLEASE start to read the posts more carefully - this was --> funchords <-- replying in a perfectly appropriate manner to your suggestion that I was just complaining about a problem that 2 people were having. I had also said that MY problem traced back to the issue that funchords had been describing, namely DNS RELAY (for the fourth time) and PORT FORWARDING (there are at least 5 other threads where people reported that they are having the same problem).
And going back to the Europe thing: I am also from Europe, with the difference that I am originally from Germany and have just moved to Canada... in Germany there is hardly any internet provider that does NOT include a VoIP flatrate. In my immediate (all non-IT) family there are at least 10 people who are running a PBX (most of them unknowingly, they just like the fact that their phone plugs into the "router").
I noticed that you were recently ****e to deliver some harsh responses. If you do not like the question being asked then maybe you should not respond. The DLink team seems to keep it this way (which in some cases is unfortunate, in others probably better). I really appreciate all the help you are providing in this forum, but after all this is a DLink forum meant to provide technical assistance and link up the company with the users - so I think it's not too much to ask for a quick response.
-
Still not getting the point...I am not judging the severity of a possible malfunction in a feature. Never said I did. I merely questioned the short term expectations you had about a response. Dyslexia? ;)
It seems to me there has been some confusion about the use of term "running PBX". This is mostly used for a PBX program on the PC (Asterisk, FreePBX). A router with VOIP (SIP) and PTSN to VOIP capabilities is, inside the box, technically speaking perhaps a PBX but it is virtually never referred to as "running a PBX".
And making comparisons with other, out-of context responses do not really add to the content of the discussion. Sorry to notice that you feel the need to enforce your story that way. As if your arguments would not suffice... ???
-
OK OK we'll leave it at that - and I'll just hope that somebody that actually can get things done at DLink takes note of this problem.
-
Still not getting the point...I am not judging the severity of a possible malfunction in a feature. Never said I did. I merely questioned the short term expectations you had about a response.
Sorry Eddie, I interpreted it as missing or denying the problem itself, not about having unreasonable expectations for a fix.
My personal expectations would be mid-February. It's the EOY, the developers are off-shore, different holidays are everywhere, and both debugging and testing is required. End of January would be nice but my patience would begin to run out by mid February.
-
I have sent three emails to the Europe support desk but never got an answer. So I understand your frustration. Since I am not tempted to change their customer service performance (...for free; this is part of my profession 8)), I just let it be. There are more important things in life to worry about or get frustrated over. :)
-
@EddieZ - I am in complete agreement that running a SIP PBX in one's basement is an uncommon practice. I've been doing this for years, I understand the protocols very well and the type of topologies needed to get these systems to operate reliably. I am a power-user. I don't have any issue with having to spend time configuring my networking gear accordingly - I expect the extra effort.
However, the demands on the router for this kind of setup is minimal. I need to reliably route traffic from a fixed set of ports exposed on the WAN to a fixed set of ports on a single machine inside my WAN. I don't issue reinvites, don't allow them. My PBX stays in the middle of all signalling and media to help insure the signalling and media paths are not tripped up by NAT problems.
There really aren't nuances here. Take a packet appearing on a specific WAN port and deliver it to a specific server/port combination in the LAN. The product documentation claims it is able to do this. Versions of the Firmware up to and including 1.1 of the Firmware do this reliably (I started with V1.02 and had no problems with all the intermediate upgrades). Versions 1.2 forward do not. This is a regression and the product with Version 1.2 forward ceases to perform as documented, nor have I seen any errata from DLink acknowledging any problems and advising any workarounds.
I develop SW for a living. Perhaps I am overly sensitive on this topic, but I'm disinclined to cut DLink any slack on this problem as they produce a router and they appear to have a pretty serious regression in a fundamental routing feature. Also, the number of users who will actually take the time to research this and go to a forum is low. If I had just purchased the DIR 655, substituted it into my network and had the problems I had - it would have gone straight back to the store, period. I wouldn't have even bothered trying to research it. The fact that this problem effects a small minority of their existing customer base isn't particularly compelling as this is a regression. The DNS Relay problem is another regression that effects all their users.
This is a real hot-button topic for me. I spend a lot of time impressing on my staff that attention to quality and product fit-and-finish is critical in high-volume and consumer products. Anything else is a poor business strategy.
I also feel strongly that the best way for consumers to help drive product quality is to hold vendors accountable for their product quality.
-
Quick update:
I turned off both SIP ALG and SPI on 1.11. As expected there are fewer log entries now, but the router still blocks certain connections from my SIP Box:
[INFO] Tue Dec 16 12:20:15 2008 Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.102 to xxx.xxx.xxx.xxx
[INFO] Tue Dec 16 12:20:09 2008 Above message repeated 2 times
[INFO] Tue Dec 16 12:17:02 2008 Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.102 to xxx.xxx.xxx.xxx
[INFO] Tue Dec 16 12:16:35 2008 Above message repeated 5 times
Seems to me that the phenomenon is still the same and just the name has changed. Whereas it said SIP ALG before it now just reads ICMP packet. Can any of you make sense of that? Calling still seems to work as before with the occasional busy signal.
@StephanFr: Full ack!
-
Okay, ICMP 3 means that the DIR-655 allowed an incoming packet through to 192.168.0.102 and the port wasn't open at 192.168.0.102. That the outgoing ICMP "unavailable" response was blocked is because the DIR-655 lacks the code to translate the NAT for ICMP 3 outgoing.
Since I imagine that you have DNS Relay turned off, then this is probably not a late DNS query being returned. (ICMP 3 is a symptom of a DNS response being forwarded after the request has timed out.)
Is 192.168.0.102 a computer? If you put Wireshark on it, you should be able to figure out what's generating those messages. Either that or right after seeing one of those ICMP 3 messages appearing, take a look at Status - Internet Sessions and see if you can see an open session to the .102 device that has an expiration timer that coincides with the ICMP 3 (udp timers start at 300 seconds, I think TCP is 7700?).
I was actually getting a bunch of these ICMP3's blocked in response of a Skype node that just wouldn't give up on contacting my closed Skype app. I hadn't run Skype in over 24 hours but the node kept probing. The port wasn't open in a rule, but it was open in UPNP. Sounds frustrating but it's just a harmless log item.
-
With the ALG disabled the firewall sees that first and blocks it accordingly.
If you enable the alg and the blocks now shot ICMP type 3, my guess is either the UPnP is not opening the ports needed, or the port forwarding is not working.
-
@funchords:
Since I am back on FW 1.11 I have the DNS Relay activated. 192.168.0.102 is not a computer but a VoIP box (Fritz!Box) that I have told to act as a network device. So I cannot put Wireshark on it
@Lycan: I'll re-enable ALG and see if that changes anything. I think I had it enabled for a while but discovered the same blocks - but I'll check again.
EDIT: No change...
[INFO] Tue Dec 16 14:35:38 2008 Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.102 to XXX.XXX.XXX.XXX
[INFO] Tue Dec 16 14:35:32 2008 Above message repeated 2 times
BUT: I dug back into the settings and found the possibility that it marks SIP packets with ToS (Type of Service) - would that be a possibility? I haven't found any hint about what nummerical values I should use (it can mark SIP and RTP packets), any suggestions? (Default is 0)
How about the setting: "Keep Portforwarding active" with various intervalls - does that affect it somehow? I have changed it to 30 sec for now and will monitor if it changes anything. EDIT: Still getting the "[INFO] Tue Dec 16 14:49:37 2008 Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.102 to XX.XX.XX.XX"
Do you think that could be a problem of the VoIP device so that I maybe should buy a PAP2T or something like that?
-
NetDevil,
No data packet is being blocked. The -outgoing- ICMP 3 packet IS AN RESPONSE to an incoming packet that passed through the DIR-655 and was received on a closed port on your *.102 device. Unless something really weird is going on, you probably can safely ignore this. To be certain, put your VOIP device through its paces and see if you are getting any unexpected failures.
Do you have an XP or Vista machine on this network? If you can open up the Properties of the UPnP "Extreme N" device that appears either in the Network Manager (Vista) or in the Network Connections (XP) screen, the Advanced button should show what ports are open to the *.102 device. One of these ports is what's being passed inbound, and might give a clue. Or it could be Port 53 (which is DNS) -- hard to say without scoping the actual device somehow.
-
Hi funchords -
no Windows or Vista machine... running OpenSuse11 on one machine and Ubuntu 7.10 on the Laptop. On the VoIP deviceI cannot really do much about finding out which ports are open ...
Thanks for explaining that though! Your feedback here in the forum is outstanding and very helpful - I'm starting to get the point. As I described before, sometimes people calling here get busy signals even though the line is not busy on my side - its hard for me to tell since I normally do not hear about it, but I think it might coincide with these blocks - it also reports Timeout on the VoIP device but far less regular than those blocked packets. I guess - if I can ignore the blocked packets - the question is then what is giving the callers a busy signal? Cause that's happening ALL THE TIME with any firmware newer than 1.11...
-
Any chance your VOIP provider has a limit on incoming trunks? You can also test periodically your own number with your cellular phone -- sample throughout the day.
Also, don't forget that "Status/Internet_Sesssions" screen. If you notice that you've just had an ICMP 3, you can look at that Status/Internet_Sessions list and look for any entries that are as old as the ICMP. (You only have 5 minutes -- 300 seconds -- if its UDP, but if you catch it you can see what port it tried to contact. Also the DMZ will obviously provoke a few of these ICMP 3 responses).