Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[netdevil]

@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]

@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!

[netdevil]

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

[StephanFr]

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

[netdevil]

@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)!!!

[StephanFr]

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]

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

[netdevil]

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

[EddieZ]

Maybe some patience...it's not IM... Maybe you're the only one having this specific issue...
Why interfere when co-users might be able provide a solution?

[netdevil]

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!

[funchords]

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.

[EddieZ]

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.

[netdevil]

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"

[EddieZ]

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. 

[funchords]

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.