[arm-allstar] Debugging port forwarding

[Dave Miller]

After doing a reset of the router and many things I can't remember Tom
reports it works. The nmap also works from outside my network.
We will take it as a victory. Still don't know what I did differently.
Confused but happy.
Thank you everyone for the help.
Dave
VE7PKE

On Fri, Feb 27, 2015 at 12:16 PM, Joel <x-rad at frontier.com> wrote:

> Dave Miller wrote:
>
>> I am trying to get a simple test case working to hit the correct
>> party squarely on the head.
>>
>> I have been try to use the various online port checkers to see if I
>> am open. They all show closed. Even tried a different DSL router that
>> allegedly was in bridge mode. Still same results.
>>
>
>
> When you sent a UDP packets (with a scanner or an application), the
> receiving host will....
>
> a) If it has a listening daemon to that port - it will pass the packet
> onto the daemon (Asterisk in this case). If the daemon does not respond,
> from the receivers end - the packet will seem to go into oblivion because
> no response of any sort is received.
>
> b) If the port is closed, the host TCP stack will return a icmp port
> unreachable packet to tell you that "no one here is listening to that port".
>
> Problem with "b" is that many firewalls block the return ICMP packets
> thinking that increases security. Back in the Windows 98 days the TCP stack
> was so fragile that things like malformed ICMP packets could blue-screen
> the computer. So everyone started blocking them. A bad idea because it
> breaks networking in many ways... But the bottom line is, your port
> forwarding could be all correct and when you probe you will get "a" above
> but never know if the daemon is ignoring you for some reason, or a firewall
> is stopping the inbound UDP packet, or the return ICMP packet.
>
> To diagnose this - you need to sniff packets! Most distro's have tcpdump
> installed - if not find the package and install it...
> pacman -S tcpdump
>
> Then on the receiver side (the one you can't connect to) do (change port
> number if needed!)...
>
> tcpdump -n -nn udp and port 4569
>
> Then from the other node (the one that is trying to connect but can't)
> issue a connect command... Watch on the receiver to see if any packets
> arrive from the far end.
>
> If nothing is arriving - then you have a problem inbound. Ideally would be
> to sniff packets on your routers WAN address. I've seen plenty of routers
> with correctly set UDP forwarding rules that still do no forward the
> packets... I've helped Netgear and D-Link nail bugs in their firmware that
> did this in the past.
>
> 73's
> Joel/N7GLV
>
> _______________________________________________
>
> arm-allstar mailing list
> arm-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB web page - http://www.crompton.com/hamradio/
> BeagleBoneBlackAllstar/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20150227/589674bb/attachment-0001.html>