We think this is a seperate issue due to the router logs you'd sent. I have someone looking at it for now you.Quote:
Originally Posted by dbmaven
Printable View
We think this is a seperate issue due to the router logs you'd sent. I have someone looking at it for now you.Quote:
Originally Posted by dbmaven
Craig,
I have looked at both your syslogs and your network traces that are currently being sent to the server it looks like you have a few issues going on. The first being A) loosing registration, I sent you a call and as soon as it was over it seems as if your registration has dropped. After doing extensive research with your syslog information you sent over to me, I found an error that looks to be involved between your router / firmware: "ip_nat_mangle_udp_packet: undersized packet" -- doing a quick google on this quickly brings up results with routers having odd results such as calls actually rebooting their router.
B) The other issue at hand as far as why you are not re-registering properly is that it seems you are not receiving our "401 Unauthorized" Response to your original SIP REGISTER request.
The way it works is as follows:
A) PAP2T sends registration to SERVER without "realm" and "credentials" i.e. your "SIP Authentication Information"
B) SERVER sends "401 Unauthorized" -- which means "Give me my credentials to authorize you"
C) You receive the 401 and send back a REGISTER request with Proxy-Authorization header / credentials & realm set.
This process is not occurring? Why one may ask... the answer is simple. The packet is not making it to your PAP2T, as for the reason to that, there can be a myriad of reasons, to name a few: firewall, ports not forwarded, router / firmware issues, etc.
Is it possible for you to setup a network sniffer on your side and see if you are indeed getting these 401 responses to your registration request? If you are then perhaps you have a defective ATA -- however I'd bet it's a 99% chance that the PAP2T is not receiving this message.
As for going back to Issue A -- I'd like to continue to work with you and perhaps get some more syslog information perhaps at the precise time, of a call being placed / etc.
This is why we tell users to forward ports -- (even if their router allows it when the device is DMZ'ed) -- since it is all to common that most routers do not interact properly, and forwarding ports will more than likely fix your registration issues.
Not having seen this - I updated the ticket by sending a new - small - router log.
Last week this was working fine with a pretty "stock" router config.
No ports forwarded.
SPI Firewall enabled.
Ports 5062 and 5079.
Now I'm seeing 5061 and 5079.
Coincidentally, perhaps, with the datacenter/latency issues, it started failing again.
I forwarded ports. No love.
For the log file - the SPI was disabled and no ports were forwarded.
Unfortunately, I don't have a sniffer to capture packets. But I'll do whatever diagnostics you want.
If we really believe that the router is the issue - intermittently or regularly - I can retrieve my 'old' WRT54GS and set it up as the internet router, and hang the PAP2 off it, with my WRT610N as an internal router, and a static custom route from the 54 to the 610N. It's a PITA, because I have N devices that I need - but I'll do it.
If that resolves the issue - somebody needs to beat Cisco/Linksys with a very big stick - 'cause that means as more people go to their higher end "n" routers you're going to see a lot of unhappy customers...
Let me know how you want to proceed.
dbmaven, Here are few trouble shooting steps..
* Update latest firmware ( you probably already did this). Sometimes going back one rev will fix things too.
* Try turning off STUN on PAP2T and disable SPI on router. No port forwarding. See if it works. When you are doing these steps, keep the registation interval to 1 minute, so that the registration expires quickly. Also wait for 1 minute before you goto the next step.
* If it doesn't work, turn on STUN in PAP2T, disable SPI on router, See if it works. There are lot of parameters for STUN in PAP2T. You might have to change things few times.
* Try port forwarding. 5061 and 5062 are PAP2T defaults. I am not sure if they changed one of those to 5079 for you. 5079 was used by GS 502. Since you had problems with registration, I think just forwarding those ports will check if the registration will stick.
* See this thread (see sipmaster posting) http://forums.linksysbycisco.com/lin...=99574#M126691
He seems to say 610N modifies SIP packets and maybe doing it incorrectly.
http://forums.linksysbycisco.com/lin...id=99574#M3724
* If you are able to get it to work, then you can add SPI firewall and see if it breaks things.
* To sniff the packets, you need wireshark and a hub. Put the pap2t and pc behind the hub. Connect the hub to the router. Use Wireshark to capture the packets.
http://forums.linksysbycisco.com/lin...=99574#M126691
That seems to validate what Brandon has been seeing in my logs and/or the diagnostics/traces that have been done.
Thank you for finding that - the search function on their forums is horrible - I should have been able to find that before I posted a thread about the same topic that got zero (useful) responses.
I don't think I'm going to waste any more time with this - probably going to go get my WRT54GS and set it up as the main internet router and use the 610N as an internal router.
I want to post a closing comment to my ridiculous saga.
I spent quite a bit of time this afternoon with Brandon - trying all sorts of interesting router and pap2/server configurations.
I even set up my 'old' WRT54GS as the internet router, and hung the PAP2 off it, taking the WRT610N out of the picture.
The behavior was identical.
I ended up flashing the 54GS to DD-WRT.
And.....
IT JUST FREAKIN' WORKS
No port forwarding
No port triggering
No DMZ
No nothing
As basic a router config as you can get.
It just works.
Somebody needs to take whoever is responsible for the NAT section of the LINKSYS firmware, and put him in a room with a couple dozen recalcitrant Linksys routers and PAP2s. Tell him/her they can come out when they just work properly all the time.
Many thanks to Brandon, and Tim - for their dedication and patience.
Now to compose a nastygram for the President of Cisco...... :p
This is what we fight every day with getting through it through to users...but most don't believe us and insist that it must just be that the service is unreliable for everyone.Quote:
Originally Posted by dbmaven
The majority of the users with problems just don't realize they're being caused by their routers.
I know it's crazy, but the newer, more advanced the routers are, the more problems they seem to have.
Users think that because they don't have anything forwarded on them the router won't mess with them. The new ones mostly seem to rewrite ALL traffic though so it causes issues.
Glad to hear you're up and running. :)
I'm glad too - and I know you and Brandon are ;)Quote:
Originally Posted by VOIPoTim
Sooner or later you and other VoIP providers are going to have to deal with Cisco on stuff like this - along with those of us having the issues and fighting through them. The average guy/gal really does want this stuff to be plug and play - and if it isn't - they'll bail. The router works for internet and everything else - but it doesn't work for VoIP - must be VoIP's problem.....
I'll be happy to help in any way I can.
I followed dbmaven's lead and went DD-WRT across the boards. Running a WRT54G v4 into the cable modem and a WRT54GL as a wireless bridge.
I also learned it's not best to do it late night after some drinks.
Linksys firmware is crap on purpose. Lets see you have a company making money and doing really well selling $50.00 routers that people in turn take and install other firmware on and they make it work like a 300.00 (or more) router. This in turn spreads by word of mouth and a company (Cisco) starts losing business on its "high end" products.Quote:
Originally Posted by dbmaven
So if you can not beat them buy them out, cut out some of the extra space, memory, install crappy firmware , and while your at it lets stop using open source firmware and instead we will use something we can (try unsuccessfully ) to keep a secret.
EDIT -- I forgot to mention the really crappy tech support.
My WRT54G V2 was great. It died and I went to Walmart and purchased another (V6). It would not work out of the box so I returned it and got another (surely it must of been a bad apple right). The replacement (WRT54GS) did not work either.
I had to connect directly to the internet, download the newest firmware, install it just to get dns to work. Then ssh connections would die after about 10 minutes of use. I repaid Linksys for my wasted time by taking my dead V2 and sticking it in the box the new one came in and returning it to Walmart. I mean I can not be expected to pay for something that does not work right (lol).
Eventually they came out with DD-WRT micro and instructions on how to install it on the V6. Installed it and never looked back. Lots of control, ssh never disconnects (been connected for days at a time), and so many new features.
If you follow the directions flashing your Linksys with DD-WRT is safe. I know some folks here love tomato but its not compatible with any of the newer Linksys models except (maybe) the WRT54GL which still has the Linux based open source firmware.