Print

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

[Tsumeone]

Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.198 to 64.151.85.68
Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.198 to 209.244.42.246
Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.198 to 216.93.181.86

It's all over my log and it's very annoying as there is no way to disable this ICMP blockage.  My DIR-655 is making outbound calls on my VOIP service ViaTalk thru my PAP2T device not connect about 50% of the time, or take REALLY long to connect.  The device is connected, but the call itself is just silence or takes over 20 seconds to start dialing.  I'm not sure if the blocked packet in the log is the problem, or something else with the DIR-655, but when I hook directly to the cable modem there are no issues.

THIS IS A FIRMWARE BUG THAT NEEDS CORRECTING, NO AMOUNT OF NAYSAY WILL CHANGE THIS
(this is directed to people who are going to come in and tell me that "oh I have xyz and it works okay so its your fault" or "you're doing it wrong because bla bla bla and it bla bla bla for me" - I've been in the business longer than you, I know what I'm doing, please shh.  I don't want to be hostile, but some of the members in this forum have forced me to insert this text.)

Here's what I've all tried.  Feel free to make suggestions for anything else to try, but I am confident the problem is not my equipment or configuration at this point, just the D-Link firmware.  ViaTalk support has documented numerous other users with this exact router with a multitude of firmware and hardware revisions all experiencing the same issue.

-Updated PAP2T firmware to newest 5.1.6
-Put PAP2T in DMZ (PAP2T has a Static DHCP address so it is always .198 in my system)
-Disabled SIP ALG
-Disabled all other ALG
-Tried opendns and advanced DNS
-Disabled DNS Relay
-Disabled tcp and udp endpoint filtering.
-Disabled SPI firewall
-Instead of DMZ, manually forwarded ports.
-Set QOS priority 1 to traffic on ports 1-65535 being sent from 192.168.0.198-192.168.0.198 to 0.0.0.0-255.255.255.255 ports 1-65535.
-Yelled at the router
-SCREAMED at the router
-Cried in front of the router
-Etc.

This problem seems to be worse when the router has been on for a long time.  There was one time where I could not even get the PAP2T to connect even after power cycling the PAP2T twice.  I had to reboot the router, and upon reboot the PAP2T connected instantly...

Anyone else who read these forums have this issue?  Again, the primary issue is a call takes forever to connect or never connects, or sometimes it connects and i can't hear the other party but they can hear me.  Also, again, to reiterate, it is perfectly fine when hooked directly to the cable modem.  No other PC is connected to the router when performing my tests as to eliminate any potential bandwidth usage from said PCs as the cause.

Edit:  I rarely use my VOIP, and I'm totally open to letting D-Link borrow my PAP2T for their own testing if they need it.  I'd like to see this fixed

[lizzi555]

Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.198 to 64.151.85.68
Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.198 to 209.244.42.246
Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.198 to 216.93.181.86

The question is, why the PAP2T is sending these "Destination unreachable" packets to different hosts.
Somehow it wants to signalize it can not reach the servers.

If, in the destination host, the IP module cannot deliver the datagram because the indicated protocol module or process port is not active, the destination host may send a destination unreachable message to the source host.

64.151.85.68 = Servepath
209.244.42.246 = Level 3 Communications, Inc.
216.93.181.86 = SERVEPATH


Seems as is there still a port missing so that not all necessary data is deliverd to the PAP2T.
Did you try (only as a test) to put the PAP2T into the DMZ ?

[Fatman]

THIS IS A FIRMWARE BUG THAT NEEDS CORRECTING, NO AMOUNT OF NAYSAY WILL CHANGE THIS
(this is directed to people who are going to come in and tell me that "oh I have xyz and it works okay so its your fault" or "you're doing it wrong because bla bla bla and it bla bla bla for me" - I've been in the business longer than you, I know what I'm doing, please shh.  I don't want to be hostile, but some of the members in this forum have forced me to insert this text.)

See, the problem with putting a message like this in is simple, it sets the hostile tone even before a naysayer has a chance to get his heart rate up on his own about your issue.

You have made an extremely bad assumption, I don't know how long you have been in "the business", but I can guarentee you were not the first one in it (as there can not be a business if only a single person is active, you have to have at least an equal), and therefore can not know that you have been in it longer than all comers.

Additionally such statements tend to paint your knowledge in a rather negative way, because now there is a prerequsite that no matter what minutia we discuss, I am going to belive that you are an expert (given all your experiance in "the business" and the fact that you flat told me you know what you are doing).

As such when I see you posting ICMP type 3 messages, I assume sloth rather than ignorance is your issue and have no sympathy.

I don't want to be hostile, but I thought you should know the above.


The links below will greatly assist your knowledge of what an ICMP Type 3 message (blocked or not) means.

Since you are clearly in the know as it were I will start with the dry technical documentation.
http://lmgtfy.com/?q=icmp+type+3&l=1

In case you need to pass this off to lesser beings, this is all the same information, but is a little more readable (there is no simple english Wikipedia version yet, perhaps that can be your contribution today!).
http://en.wikipedia.org/wiki/ICMP_Destination_Unreachable

Given your experiance I would appriciate when you approach with demands that we change our product for you, you actually bring evidence of a problem to the table.  A technical issue with the operation of the product or perhaps evidence of it mangling or not passing particular traffic.  As you know clearly what you are doing, I would expect that this should be fairly common sense for you.

It is not possible to ask for assistance without admiting ignorance, and it is not possible to demand we fix something you can't prove.  Come back with one of the above before I lock this thread.

Again I am not being hostile, I just wanted to head you off at the pass.


***Edited by Fatman because his spacebar is failing, and he can't spell besides.

[Demonized]

Since the DIR is never used as being connected directly to the WAN, you might want to check your internet gateway device/modem.

[Clancy]

It ain't over 'till the Fatman sings. I think I hear "Figaro...Figaro..." in the distance.

[Fatman]

Truthfully Clancy, I am just hoping Tsumeone here has a taste for tongue in cheek humour (and double entendres)

[lotacus]

haha Fatman is great.

[Tsumeone]

The links below will greatly assist your knowledge of what an ICMP Type 3 message (blocked or not) means.

Since you are clearly in the know as it were I will start with the dry technical documentation.
http://lmgtfy.com/?q=icmp+type+3&l=1

In case you need to pass this off to lesser beings, this is all the same information, but is a little more readable (there is no simple english Wikipedia version yet, perhaps that can be your contribution today!).
http://en.wikipedia.org/wiki/ICMP_Destination_Unreachable

Given your experiance I would appriciate when you approach with demands that we change our product for you, you actually bring evidence of a problem to the table.  A technical issue with the operation of the product or perhaps evidence of it mangling or not passing particular traffic.  As you know clearly what you are doing, I would expect that this should be fairly common sense for you.

Why is the router blocking them?  I don't find that information in your post.  And no, I probably haven't been in it longer than everyone here, but I have been in it long enough to know that putting the PAP2T into the DMZ should stop any type of blockage from occuring including these.

I skimmed over everything in your post about my statement, because it was not directed to you.  It was directed to one specific member in this forum who has no idea what he is talking about but HAS to comment in every thread.  I was hoping to nip it in the bud, without mentioning said user's name.  My apologies if I offended you.

And as I said earlier, I didn't know if the ICMP message was related to the problem I'm having with dialing out.  It was right there in my post that I didn't know if it was related.  I gather from your post that it is probably not related.  Why do you think the DIR is causing the issue where I can't dial out?  Again, here is where I said I wasn't sure the blocked packet was the problem, a contribution of my admitted ignorance to the omnipotent D-Link technical engineer: 

I'm not sure if the blocked packet in the log is the problem, or something else with the DIR-655, but when I hook directly to the cable modem there are no issues.

How would you like the evidence of the problem?  Would you like me to record a video of me, going through each page of my configuration, of both my dlink and pap2t, and then a demonstation of the problem when i try to dial out, and then a demonstration with the pap2t connected directly to the cable modem?  I can do that, it will be a pain in the ass, but if I need to prove it because you can't test it on your end then I will give it a go.  I do not have the equipment here to intercept packets between the PAP2T and whatever it's plugged in to.  I'd assume you do.  Hence the offer for you to test it with my PAP2T.  Again, I have done everything ever suggested to me ever by D-Link support.  I would like some suggestions, but since there aren't any, I'd like some testing on D-Link's end.  Did you read what I tried?

It is not possible to ask for assistance without admiting ignorance,

I'd like to see some assistance that solves the issue... but there doesn't appear to be any, and I've exhausted most avenues of support.

and it is not possible to demand we fix something you can't prove.

Really?  Cause I'm pretty sure I did make the demand.  Oh snap!  The world as we know it is ending, the laws of tech support forum physics have been broken...

Come back with one of the above before I lock this thread.

In all seriousness, I'd like you to tell me what you want me to do to prove to you that the DIR-655 is indeed causing the problem.  What proof, specifically, do you want?  As I typed earlier, I can make a video.

[Lincey]

i has same problem. please help meh

[EddieZ]

It was directed to one specific member in this forum who has no idea what he is talking about but HAS to comment in every thread

That must be me. Thanks for honouring me this way. 

[Demonized]

Some clarification on the "modem" part:
It's too simple ofcourse, but haven't seen anything about that in your analysis; When you connect
the VOIP device directly to the modem the UPnP mechanism will automatically do the work for you (open ports etc). When you put the router in between, the VOIP device and the router will use the UPnP principle (when enabled), but between the router and modem there is no automatic configuration of ports.

Would not be the first to have ports closed or a modem blocking ICMP traffic because of its firewall.

Just a simple option to consider, even geniuses can sometimes forget about the easy solution.

[Tsumeone]

Some clarification on the "modem" part:
It's too simple ofcourse, but haven't seen anything about that in your analysis; When you connect
the VOIP device directly to the modem the UPnP mechanism will automatically do the work for you (open ports etc). When you put the router in between, the VOIP device and the router will use the UPnP principle (when enabled), but between the router and modem there is no automatic configuration of ports.

Would not be the first to have ports closed or a modem blocking ICMP traffic because of its firewall.

Just a simple option to consider, even geniuses can sometimes forget about the easy solution.

Modems do not route nor block traffic and therefore do not have UPNP.  Thanks, though.

[Tsumeone]

That must be me. Thanks for honouring me this way. 

I didn't mention any names... 

[Demonized]

Modems do not route nor block traffic and therefore do not have UPNP.  Thanks, though.

Maybe yours doesn't, but my modem (xDSL) surely has it: Speedtouch 780. There's more modems around than dumb Motorolo's for cable. 

[Tsumeone]

Maybe yours doesn't, but my modem (xDSL) surely has it: Speedtouch 780. There's more modems around than dumb Motorolo's for cable. 

Mine's a dumb moto for cable   It's good because I know it doesn't interfere with my traffic :p