Print

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

[EddieZ]

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? 

[netdevil]

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.

[EddieZ]

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

[netdevil]

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.

[funchords]

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.

[EddieZ]

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  ), I just let it be. There are more important things in life to worry about or get frustrated over. 

[StephanFr]

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

[netdevil]

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:

Code: [Select]

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

[funchords]

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.

[Lycan]

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.

[netdevil]

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

Code: [Select]

[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?

[funchords]

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.

[netdevil]

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

[funchords]

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