<div dir="ltr"><div><div><div><div>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.<br></div>We will take it as a victory. Still don't know what I did differently.<br></div>Confused but happy.<br></div>Thank you everyone for the help.<br></div>Dave<br><div><div><div><div>VE7PKE<br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 12:16 PM, Joel <span dir="ltr"><<a href="mailto:x-rad@frontier.com" target="_blank">x-rad@frontier.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Dave Miller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am trying to get a simple test case working to hit the correct<br>
party squarely on the head.<br>
<br>
I have been try to use the various online port checkers to see if I<br>
am open. They all show closed. Even tried a different DSL router that<br>
allegedly was in bridge mode. Still same results.<br>
</blockquote>
<br>
<br></span>
When you sent a UDP packets (with a scanner or an application), the receiving host will....<br>
<br>
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.<br>
<br>
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".<br>
<br>
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.<br>
<br>
To diagnose this - you need to sniff packets! Most distro's have tcpdump installed - if not find the package and install it...<br>
pacman -S tcpdump<br>
<br>
Then on the receiver side (the one you can't connect to) do (change port number if needed!)...<br>
<br>
tcpdump -n -nn udp and port 4569<br>
<br>
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.<br>
<br>
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.<br>
<br>
73's<br>
Joel/N7GLV<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
<br>
arm-allstar mailing list<br>
<a href="mailto:arm-allstar@hamvoip.org" target="_blank">arm-allstar@hamvoip.org</a><br>
<a href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar" target="_blank">http://lists.hamvoip.org/cgi-<u></u>bin/mailman/listinfo/arm-<u></u>allstar</a><br>
<br>
Visit the BBB web page - <a href="http://www.crompton.com/hamradio/BeagleBoneBlackAllstar/" target="_blank">http://www.crompton.com/<u></u>hamradio/<u></u>BeagleBoneBlackAllstar/</a><br>
</div></div></blockquote></div><br></div>