D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: Tsumeone on June 16, 2009, 01:45:22 PM
-
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 :)
-
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 ?
-
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.
-
Since the DIR is never used as being connected directly to the WAN, you might want to check your internet gateway device/modem.
-
It ain't over 'till the Fatman sings. I think I hear "Figaro...Figaro..." in the distance.
-
Truthfully Clancy, I am just hoping Tsumeone here has a taste for tongue in cheek humour (and double entendres)
-
haha Fatman is great.
-
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.
-
i has same problem. please help meh
-
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. ;D
-
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. ;)
-
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.
-
That must be me. Thanks for honouring me this way. ;D
I didn't mention any names... :-X
-
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. ;)
-
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 :D It's good because I know it doesn't interfere with my traffic :p
-
image removed
You're really sick :'(. If this won't ban you I'll eat my hat.
-
You're really sick :'(. If this won't ban you I'll eat my hat.
That image was not removed when I dropped in this morning. You are correct Demonized and unfortunately, such is the way of internet anonymity. Such a person would never dare attempt to do that in a crowded room but if he did, he'd have his cell phone in hand with a finger on his Dentist's speed dial number.
-
If I look from Turkey the image is still there, this can get this website banned in Turkey and by a lot of providers worldwide.
The guy is really sick and I would really like to see this DEGENERATE banned for life.
You're really sick :'(. If this won't ban you I'll eat my hat.
-
I removed the image from my quote. Repeating it would double his fun probably. Very sad person, I reported the post and specifically asked for an IP ban. A bit more effective hopefully.
-
I removed the image from my quote. Repeating it would double his fun probably. Very sad person, I reported the post and specifically asked for an IP ban. A bit more effective hopefully.
I agree. An IP ban would be the only way because I think this person has been popping up recently under various nom-de-plumes and I have immediately reported those posts as well as this one . This is disturbing and goes far beyond the pale of civilized behavior. I was furious when I saw what this "person" had done. Angry not just at the act but also because it was a direct personal attack and no matter what anyone's opinion of another person might be, this behavior shall not pass.
-
It's been done.
-
I am going to take the liberty of boiling your post down to a single sentence of value and I will discuss a couple of other interesting phrases of no real value afterwards.
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?
You are absolutely right to tell me to put up or shut up. Here is the issue, in a perfect world I would want the below.
Access to a device identacle to your VoIP device, I know you offered to loan us yours, but I don't think I can take you up on that offer. Which means I need the next best thing, which is the below list.
- A config file from your DIR.
- A packet capture of half a dozen normal phone calls taken without the router in place.
- A packet capture form the WAN side of the router showing half a dozen calls. This capture should cover from the power up of the router, through the power up of the device, and finally the calls.
- A packet capture from the VoIP device showing half a dozen calls. This capture should cover from the power up of the router, through the power up of the device, and finally the calls. These would ideally be the exact same calls as the above (router WAN) capture, and would come with an exact time difference listed so I can make use of the timestamps in both captures as representing the same time.
This would show pretty clearly if this router is dropping or mangling any traffic. The rub is that this kind of difficult to get all this information, you would need a hub or switch capable of doing port mirroring (2 if you are going for the preferred form on the 2nd and 3rd captures). It also requires a bit of experiance to set up this test environment.
Short of the above we are in dangerous waters, as we don't have any logged relevant dropped traffic and if I read correctly the call still goes through it just has a silent delay (which I might add is really weird). Those together tell me the problem is either not a dropped packet that would be logged (I know of nothing that wouldn't be logged, but this isn't my product), or it is one that is dropped because of an issue such as NAT incompatability (have you tried any other routers?). If NAT compatability is the issue you would not see a dropped packet because the dropped packet would be on your providers side. That said that isn't my first thought because the call eventually goes through, maybe it is some sort of NAT failover on your providers side, there is no way for me to tell.
My cop out for the day is the fact that SIP was never designed to work in a NAT environment.
So the question becomes, could you provide the above list of requisites, or any significant portion thereof?
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.
No worries, I am much harder to offend than that, I am also attempting to stand between users with beef. My biggest point was that opening with a salvo like that guarentees a response in kind.
omnipotent D-Link technical engineer
This however offends me, I am not omnipotent because I am a D-Link employee, I am just plain omnipotent! The other D-Linkers, varying degrees of less so.
If only I was omnipresent I could solve this issue for you, but as is descussed above I can't predict the issue and this leaves me rather omnimpotent in that department.
*** modified by Fatman because he can't leave well enough alone and wants to play with bbcode formatting.
-
Short of the above we are in dangerous waters, as we don't have any logged relevant dropped traffic and if I read correctly the call still goes through it just has a silent delay (which I might add is really weird). Those together tell me the problem is either not a dropped packet that would be logged (I know of nothing that wouldn't be logged, but this isn't my product), or it is one that is dropped because of an issue such as NAT incompatability (have you tried any other routers?). If NAT compatability is the issue you would not see a dropped packet because the dropped packet would be on your providers side. That said that isn't my first thought because the call eventually goes through, maybe it is some sort of NAT failover on your providers side, there is no way for me to tell.
I did work fine with my DI-624, between the router automagically rebooting itself anyway :) I'll try to find mentioned port mirroring switch on craigslist, or ill try to get another eth card for my spare PCs and maybe find some open source platform I can throw on there to get the job done. We'll see. I'm thinking pfSense might be able to handle this?
Edit: The call does go through, but only maybe 60% of the time. Sometimes, it just never happens. And rarely it will go through but I cannot hear the other party (they can hear me).
This however offends me, I am not omnipotent because I am a D-Link employee, I am just plain omnipotent! The other D-Linkers, varying degrees of less so.
If only I was omnipresent I could solve this issue for you, but as is descussed above I can't predict the issue and this leaves me rather omnimpotent in that department.
You gave me a good lol ;D Thanks!
-
I'll try to find mentioned port mirroring switch on craigslist
Look for the hub instead, if you can find one it will be hundreds cheaper. You could also cheat by hooking the following up to a hub and taking a single capture for the last two captures, though it is a little less clean to troubleshoot with (I can make do).
- LAN of router
- WAN of router
- VoIP device
- Modem
- Capturing PC (in the uplink port if it is a 5 port model)
You gave me a good lol ;D Thanks!
I am glad you approve, I was worried I was going to be called a blaspheming heretic and chased out with a broom. My work here is done.
-
It's been done.
I tip my hat to you, Lycan.
-
Look for the hub instead, if you can find one it will be hundreds cheaper. You could also cheat by hooking the following up to a hub and taking a single capture for the last two captures, though it is a little less clean to troubleshoot with (I can make do).
- LAN of router
- WAN of router
- VoIP device
- Modem
- Capturing PC (in the uplink port if it is a 5 port model)
I am glad you approve, I was worried I was going to be called a blaspheming heretic and chased out with a broom. My work here is done.
I could get two regular hubs for the last step and hook them up like 1 hub to modem, router [wan], and pc running wireshark, and another hub for router [lan], Linksys PAP2T, and another pc running wireshark. Since the hub is a "dumb switch" that just blasts traffic to every port, the wireshark logs should be just what you need from this setup. Would this work?
-
Absolutely!
-
Absolutely!
Sweet. Gonna go hit up the local computer outlet soon as I can :)
-
I am glad you approve, I was worried I was going to be called a blaspheming heretic and chased out with a broom.
Well Fatman, you are a blaspheming heretic. What's your point? I figured you'd be RIDING out on a broom. :-*
(And to think...., he has the power to nuke me on the spot. :o)
-
I have to thank you for not letting me down on my high expectations. You are a true friend.
-
I have to thank you for not letting me down on my high expectations. You are a true friend.
Truly, what are friends for, Stout Fellow?
I just took a peek at some of the latest posts on other D-Link product forums and HO-LEE CR*P! I'm surprised you guys don't just shut this thing down without fanfare or "how do you do" or Adios or Nothin'! I don't know if you or the rest of the moderators are moderating voluntarily or otherwise but I'm certain that you could find better things to do with your time than to take insults from the likes of ... of .... "someone's" name will come to mind any minute now but never mind that. I appreciate the time you do take to come down from Olympus and speak to mere mortals such as ... um... Xinot, so you'll never hear anything from me but encouragement and praise and high condemnation, er, commendation. Carry on Old Chap and if you don't mind, you need to pay more attention to MY posts and stop wasting you time with .... Xinot. Tootles. :P
-
... Carry on Old Chap and if you don't mind, you need to pay more attention to MY posts and stop wasting you time with .... Xinot. Tootles. :P
;) :)
-
It is a dirty job, but the job markets tight right now, I mean .......(um)....(where was I)..... but somebody has to do it.
The mods here are all people who have a position at D-Link, and who have the forum added to their list of tasks for the day. It is usually one of the more enjoyable tasks of my day though.
To be honest things have become more of a train wreck recently, it is a cyclical thing. All will get better soon. Either that or I will hang myself, I am sure one of them will happen.
Anyone have a length of rope they can lend me?
-
I'm following this thread with great interest since I am having similar if not identical issues with another piece of VoIP hardware (I had a thread in this forum a while ago) that I haven't been able to solve. Thanks for your efforts everybody!
-
We aint done nothing yet, hopefully Tsumeone's captures will shed some light. Also what we find here may not apply to your device, but it is too early to know anything for sure.
-
Anyone have a length of rope they can lend me?
Silk or hemp? ::)
By the way, I'm writing this from an underground tornado shelter so just TRY and find me. 8)
You do good work, Fatman. I always enjoy being misled by your posts. ;D
Yes, I guess I am trying to get another "SMITE" on my record for not staying on topic and hijacking the thread. For those of you who actually read this thread for your edification, my profound apologies if I disrupt the continuity. In spite of appearances, I also read to be edified. It is somewhat disconcerting to think that someone's Dogma is taking a bite out of my Karma. I was crushed when I got my first Smite. Now I have 2. I lost at least... 5 minutes of sleep. 1 minute tops. All business and no play makes D-Link a dull boy. I will stop with the harassment of one of our favorite moderators before he starts singing.......just for me. :-X
-
Back on topic, I do eagerly await the OPs results, this should be informative.
Silk or hemp? ::)
You must be a D&D player, only they ask silk or hemp, and them precede to tell you about a +2 circumstance checks to using silk rope. Good news my rope use check way exceeds the necessary to tie an effective noose, I will take a 10 on this one, scratch that, I will take my time and take a 20. Perhaps then I will check high enough for a circumstance bonus when using that knot, please don't make the DM a jerk on this one! Frayed knot, the DM will probably leave me high and dry on this one.
I was thinking paracord, the strength and stretch might be important. Might have to make an REI run, no more general stores that always sell hemp or silk rope only and always at the same price.
Don't worry about being off topic, I am not going to lock this thread any time soon, and I have the unlock button if anyone else interferes. That said I am going to *try* to settle down a bit.
-
Here is the thing reitton, with that alphabet soup after your name, you are more than equipped to realize ICMP type 3 is not the core issue and blocking it is done as a security measure. It is a wild goose chase.
Routers are not required to pass such messages by standard, on home devices there is no reasonable reason to allow them, and a couple of attacks speaking for blocking it.
DMZ allows all incoming traffic that passes existing security checks and is not otherwise directed by a NAT rule. It is not consulted in ANY WAY for outbound traffic.
-
The 'Alphabet soup' does have an advantage: These people are fully qualified to read through he relevant RFC's (792, 1122, 1191, 2003 and so on) themselves. ;)
-
My favourites are RFC1149 (http://tools.ietf.org/html/rfc1149 (http://tools.ietf.org/html/rfc1149)) and RFC2549 (http://tools.ietf.org/html/rfc2549 (http://tools.ietf.org/html/rfc2549)), more commonly known as IPoAC (IP over Avian Carriers) and IPoAC/QoS (IP over Avian Carriers with Quality of Service).
*** Modifiedby Fatman to add links, because Fatman is still playing with BBCode tags.
-
Darn. And I wanted to quote the nice man. I wanted to remind him that IT guys by default are devoid of social skills.
EXCEPT YOU Fatman. YOU, have excellent social skills.
Demonized, put the brick down!
-
You do crack me up Clancy, unfortunately that wasn't my call, apparently the guy (with such great social skills) who yells at all the customers has the most patience with them too.
-
You are all solid guys, no matter what everyone else says (and they do)!
-
I just gave the nice moderator a Karma point. Would it be considered un-cricket like if I made up another name just so I could pump up my own Karma points? In no time at all, people would be calling me "Bodhisattva". Sorry, off topic - again. Smite me Fatman, for I deserve it.
-
I won't smite you, I support blasphemy remember.
Besides, I can manually edit that number if I need to, and or you start playing funny games. That said, given this system is pretty weird as it, take an applaud.
-
OK, last post here because I can't type or sit up in my chair from laughing so hard.
-
I live to serve mi'lord!
-
I am running two PAP2T units with a DIR-655 and using ViaTalk and I have no such errors or problems like you are describing.
I dont use DMZ, port forwarding or any other special settings. The only thing I did was turn off the ALG for SIP and everything works perfectly.
I think you need to look beyond your router to your modem or maybe even your ISP.
-
i think you need to look beyond you router to your modem or maybe even your ISP.
I'm giving you a Karma point before you go negative for your last remark. Perhaps you are unaware that these boards are only for berating D-Link products and the engineers who moderate. ::)
-
I am glad you are having no issues, and with two of them no less.
That gives me a lot of hope we can get Tsumeone straightened out. As it proves at least one person has a working STUN implementation from behind a DIR-655 and is getting SIP through just fine.
His problems appear to be based strongly on getting the RTP streams forwarded, and potentially with a secondary SIP issue. It is very possible your SIP provider is running a more vanilla implementation of SIP that our router understands how to handle and that we may come to the conclusion that we are at an impasse between the router and the service.
That said, I am going to beat on my old drum, once we have captures we will know what the issue is.
So, Tsumeone, how go those captures?
P.S. Clancy that sig is only going to feed my ego, are you really sure you wanna go there?
-
There are some STUN settings in the PAP2 that can be changed to make SIP work better. VIATALK knows the settings, and I also use VIATALKS STUN server.
-
P.S. Clancy that sig is only going to feed my ego, are you really sure you wanna go there?
Well, yes. You are like a big brother. The one you go run and hide behind when someone wants to beat you up. You can take a punch, can't you? I was so in awe of your omnipotent power when you revealed that you have the ability to both reward and punish, or obliterate, that I'd better suck up to you like a Sears Shop Vac. Wipe that ugly thought from your mind right now. I ain't that kind of Vac. Now, please help me steer this thread back onto the highway with the light from your Karmic 3rd eye.
-
SIP ALG works perfect with firmware 1.11 and my PAP2T. The PAP2T employs his local (192.168.x.x) IP address as if it was part of global IP space. The DIR 655 ALG exchanges this address for the true external address (from my ISP) within all outgoing SIP/RTP packets. It works perfectly! You can disable all NAT traversal options in the PAP2T user interface.
This didn't work with any 1.2 firmware. I would love to upgrade to 1.3x, but as long as nobody can confirm that SIP ALG works in 1.3 it's not an option.
-
"There are some STUN settings in the PAP2 that can be changed to make SIP work better. VIATALK knows the settings, and I also use VIATALKS STUN server."
I'm having the same problems with the DIR-655 (firmware 1.21) and PAP2T. I can't even get a connection and receive the same ICMP outgoing errors. I've opened the 5060-5080 incoming to the local IP (192.168.0.198). I've also turned off the SIP ALG. Still no effect. The last thing my VOIPo support said was "Your network is blocking our STUN connection, which is typical of some kind of built in routing firewall. Sounds like you have some serious connection problems from the adapter."
I'll try a DMZ to the port to see if that helps. I'd like to know what might be changed on the PAP2T that might help. Can I or should I roll the firmware back to ver 1.11?
-
I had forgotten about this thread it had been so long since we had a post here.
I don't believe you can do that downgrade.
So Tsumeone, any results?
-
Hi
I just posted similar sounding problem on the DIR-615 (http://forums.dlink.com/index.php?topic=5716.0). Same symptoms, no ring when dialing out. Rings when dialing in but when I pick up it keeps ringing.
DIR-615 can't roll back either...
Fatman: Is there a way to get syslogs out of the router to help you? The debug log from the PAP2 doesn't show much.
-
Not really, what we need are captures as described in this thread.
-
Fatman:
Is this format ok for the dump? I will do a trace for the dir615C (with 3.10NA) and for the dir524 (which works)
11:53:12.625824 IP sbproxy01.sip > yoyo345.sip: SIP, length: 436
11:53:12.626025 IP sbproxy01.sip > yoyo345.sip: SIP, length: 501
11:53:12.626201 IP yoyo345.sip > sbproxy01.sip: SIP, length: 602
BTW, this is not directly related to using a PAP2T, it also fails on calls to my PBX from outside (when using the 3.10NA on DIR615.
Since I am doing this with a DIR615 do you prefer that I post in that section or shall we assume (for now) it is relevant to DIR655 as well?
-
FYI, I reverted back to 3.01 on the DIR615C. See thread http://forums.dlink.com/index.php?topic=5716.0 for details on how this is done, in spite of DLink saying that you can't downgrade the version.
Fatman: I have some traces of the style shown above. They are DIR524-call and idle with matching call and idle from DIR615C with 3.10NA. I am not likely to upgrade to 3.10NA again anytime soon as I need to get on with other things, like a new PBX and WHS.
-
Thanks for your assistance, the key part of what we needed with the captures was a simultaneous capture from both sides of the NAT during a failed and non failed call (if such things exist) so we can see at the packet level if we have any deformation or drops.
-
Ok, I will try to stitch that together from my 'tcpdump' traces.