jsmeast
asked on
UDP packets get changed to ICMP packets
While debugging an app, I discovered that packets I sent as UDP had been changed to ICMP packets when sent over the internet. As a test, I did the following from a Mac running OS-X 10.5:
1. Open a terminal window with "nc -u -l 1028" to listen for UDP packets.
2. Open another terminal window with "nc -u x.x.x.x 1028" to send UDP packets.
3. With x.x.x.x set to 192.168.0.8, the IP address of the Mac I'm using, text sends just fine from one window to the other.
4. With x.x.x.x set to my internet IP address, packets never show up on the listening window.
5. Using the Wireshark packet sniffer, the transmitted packet appears as UDP, as expected.
6. The received packet, however, is shown as an ICMP packet, 28 bytes longer. The data portion of the content is correct.
The fact that the packet sniffer shows an incoming ICMP packet indicates that the packet is not being blocked by any firewall (set to forward port 1028 to 192.168.0.8). My internet connection is Verizon FIOS, using their Actiontec wireless router.
In short, UDP between two terminal windows on the same machine works fine when using the local machine address, but does not work when routing through the internet to the machine's internet IP address because the packets somehow get changed to ICMP packets. Any ideas would be appreciated. Thanks.
1. Open a terminal window with "nc -u -l 1028" to listen for UDP packets.
2. Open another terminal window with "nc -u x.x.x.x 1028" to send UDP packets.
3. With x.x.x.x set to 192.168.0.8, the IP address of the Mac I'm using, text sends just fine from one window to the other.
4. With x.x.x.x set to my internet IP address, packets never show up on the listening window.
5. Using the Wireshark packet sniffer, the transmitted packet appears as UDP, as expected.
6. The received packet, however, is shown as an ICMP packet, 28 bytes longer. The data portion of the content is correct.
The fact that the packet sniffer shows an incoming ICMP packet indicates that the packet is not being blocked by any firewall (set to forward port 1028 to 192.168.0.8). My internet connection is Verizon FIOS, using their Actiontec wireless router.
In short, UDP between two terminal windows on the same machine works fine when using the local machine address, but does not work when routing through the internet to the machine's internet IP address because the packets somehow get changed to ICMP packets. Any ideas would be appreciated. Thanks.
Can you tell me the type of ICMP message recieved? Is it type 3?
I didn't expect ICMP, so I set tcpdump filter to listen for UDP only.
Which version of firmware do you have? I'll contact the user and ask for deatails. Besides that I'll try to set another debug session because I kind of gaveup. I'll try your method using "nc".
Which version of firmware do you have? I'll contact the user and ask for deatails. Besides that I'll try to set another debug session because I kind of gaveup. I'll try your method using "nc".
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The strange part is the content. Echo responce will repeat the content of Echo request. Unreachable messages don't include any data portion. "nc" test works in LAN and doesn't when crossing the router.
Bamit99, we are trying to find as much as possible, so your input is really appreciated.
ASKER
Thanks for the clues, guys. The ICMP packet is type 3 (unreachable). Since nc to nc works on the local network, the UDP listen port is obviously reachable internally. However, since it doesn't work through the internet, something, presumably my Actiontec router, must be blocking port 1028. I'll double check port forwarding and report back. Obviously, all UDP packets are not being blocked, since DNS and other UDP-based services work fine. To be continued...
To be continued... Looks like there is no expert for this problem :) so we are on our own and Verizon :( Is it possible that Actiontec is trying to understand the protocol and fails?
ICMP Type 3 Does contain the header of the original UDP Packet, rather to be accurate it contains "the first 8 bytes of the original datagram's data". And 'jsmeast' just mentioned it is a Type 3 only. Now, as for other UDP packets like DNS are considered standard over the Internet, most of the firewall allow them but anything out of ordinary will be blocked as you see with your App.
Also, incase you feel the Firewalls are completely out of the picture then make sure that the Destination Machine is actually listening on the UDP port for which you are trying to sent the Data.
BTW, do you see trivial pings on the sfiffer at x.x.x.x? You said that UDP datagramms don't make their way to x.x.x.x. I kind of overlooked this statement. Try to send DNS request to x.x.x.x even if you don't have a server and see it on the sniffer.
ASKER
Problem solved, although I don't know exactly why. Re-checking the received ICMP packet, I confirmed that it was type 3 and saw that the "code" said "port unreachable". On re-reading the link provided by Bamit99, it finally became clear that the only router that could know if that port was unreachable was my Actiontec residential gateway.
I carefully looked through every setting, but didn't see anything suspicious. Still, it had to be that router, so I did a factory reset. After reconfiguring everything and adding a forward for port 1028 to my local machine, everything worked--nc to nc worked, and my app worked. The settings look no different now than they did before. Apparently, something not visible through the web interface had gotten changed in the Actiontec router.
Bamit99, I hadn't realized that a router would respond with an ICMP packet to a failed UDP send. That information, and the link you provided, were the keys to resolving the problem. Thanks.
tvman_od, thanks for your suggestions, too. All along, I've had reliable service on other UDP ports, e.g. DNS, streaming audio, etc., so I think we may have different problems. Should you decide to try a "Restore defaults" on your Actiontec, bear in mind that it wipes out all user settings. Login info goes back to the defaults of "admin" and "password". If you have lots of user configuration, you might consider saving a copy of the configuration files first, so you can restore to your previous settins, if necessary. Good luck!
I carefully looked through every setting, but didn't see anything suspicious. Still, it had to be that router, so I did a factory reset. After reconfiguring everything and adding a forward for port 1028 to my local machine, everything worked--nc to nc worked, and my app worked. The settings look no different now than they did before. Apparently, something not visible through the web interface had gotten changed in the Actiontec router.
Bamit99, I hadn't realized that a router would respond with an ICMP packet to a failed UDP send. That information, and the link you provided, were the keys to resolving the problem. Thanks.
tvman_od, thanks for your suggestions, too. All along, I've had reliable service on other UDP ports, e.g. DNS, streaming audio, etc., so I think we may have different problems. Should you decide to try a "Restore defaults" on your Actiontec, bear in mind that it wipes out all user settings. Login info goes back to the defaults of "admin" and "password". If you have lots of user configuration, you might consider saving a copy of the configuration files first, so you can restore to your previous settins, if necessary. Good luck!
Hey!!, I am glad it got resolved. Yes, sometimes resetting the setting back to what you already got...helps !!...:). Take care, Cheers !!
I was banging my head why my VoIP application is not working over FIOS with Actiontec router. Another FOIS connection with different router works just fine and all other sorts of connections work just fine, this the only one. So it must be a problem in the firmware. I'd like to resolve it for you and myself. Which UDP ports your application whants to use? A TFTP client behind the Actiontec will work with multiple errors. TFTP Server reports multiple DUP requests. I had to decrease TFTP block size down to 512 bytes. Adjusting MTU on the server didn't give any resilts. The application can download a firmware image over TFTP and then cannot start properly. UDP requests can reach the server and I see answers going toward the client behind the Actiontec but I don't see anything in local LAN. Firewall is completely disabled. Tryed to set the application client's host as DMZ host, so any kind of unmatched by NAT traffic will hit this host didn't give any results. Troibleshooting with Verizon level 3 support didn't help. This is the information which I have discovered so far.