next topic »

[Reply #15 on:]

@zoomkat: Correct. A two-way communication with the first device only. If the destination ip is localnet, the destination ip device directly. If the destination ip is not localnet, the gateway router.

[Reply #16 on:]

edit: The endPacket success return value does not indicate the packet got to its destination if the destination is not on your localnet, only whether the gateway router took it or not.

So this indicates a two way UDP communication with the router?

I wouldn't expect so. UDP is an unreliable protocol (meaning that there is no delivery acknowledgment, no explicit error detection/reporting, transmission can fail without the sender being informed). In some situations you might get an ICMP error message but that's not really part of UDP. Does endPacket() wait for ICMP responses? That would be a strange thing for it to do.

[Reply #17 on:]

I wouldn't expect so. UDP is an unreliable protocol (meaning that there is no delivery acknowledgment, no explicit error detection/reporting, transmission can fail without the sender being informed). In some situations you might get an ICMP error message but that's not really part of UDP. Does endPacket() wait for ICMP responses? That would be a strange thing for it to do.

Would you be so kind as to tell me how UDP packets get to their destination without being routed? It would be a good thing for me to know, being a routing specialist for an ISP.

[Reply #18 on:]

A two-way communication with the first device only. If the destination ip is localnet, the destination ip device directly. If the destination ip is not localnet, the gateway router.

Why does this require two way communication. I would think the router is coded to localnet non internet routable IP addresses and pass the rest outbound. No need for two way communication.

[Reply #19 on:]

Did you see my "Question of the Day" above?

How do the NTP response packets (UDP) from the server in Atlanta, or the DNS response packets (UDP) from the server in Fort Walton, get through my router back to my Arduino on a localnet ip, through my firewall and NAT without the routers communicating with each other?

Your router does the same. There is no connection. Unlike TCP, the UDP response packet is not associated with the request packet in any way as far as the enroute routers are concerned. They can't tell a request from a response with UDP. How does it know that particular port on my router's public ip is associated with the UDP port on my Arduino localnet ip to pass that response packet back? Magic pixie dust? Salted peanuts?

I'm not talking about source to destination two way communication like a TCP connection, just router to router as they pass the packet towards the destination ip.

As I said before, if you think this isn't it, please enlighten me on how it works. It would be a good thing for me to know.

[Reply #20 on:]

How does it know that particular port on my router's public ip is associated with the UDP port on my Arduino localnet ip to pass that response packet back? Magic pixie dust? Salted peanuts?

From my understanding the packet sent by your router has your router's public IP address and specific port contained in it (like a return telephone number and extension), which stays in the packet until it reaches its destination or expires. The destination server may or may not send a response back to your router using the IP address contained in the origional packet. If the return packet reaches your router, the router should be programmed to use the port number origionally sent to identify the LAN originating IP address. No magic pixie dust or salted peanuts needed (at least on this end).

[Reply #21 on:]

You haven't really clarified what you mean by the delay "when there's nothing on the other end". If the remote device is powered down then I suspect the problem is related to ARP.

Although at layer 3 (IP) you send to an IP address, at layer 2 (ethernet) your packet needs to have the MAC address of the destination in it in order to be sent. With your destination device on the local subnet, your source device will try to get the receiver's MAC address through ARP resolution. If it's not there, the ARP will fail and the packet won't be sent. The ARP request is likely to have a timeout associated with it that may be the cause of the delay.

[Reply #22 on:]

If the return packet reaches your router, the router should be programmed to use the port number originally sent to identify the LAN originating IP address. No magic pixie dust or salted peanuts needed (at least on this end).

How is that happening? Who or what is programming it? The source address ip in this case is originally a localnet ip. 192.168.2.2. How does the router know that it is my computer that requested the time (or dns)? I did not set the destination NAT in my router. Neither do you on your router. Doesn't DNS and NTP work behind your router? They are both UDP. They work on all my networks. Did you program your router to accept those packets and forward them to your localnet computer ips? If not, according to you, NTP and DNS would not work behind anybody's router. The firewall and NAT would block the packets.

The request packet source address was modified by the NAT in my router to my public ip and port. The return packet destination from the NTP server is now my public ip and port. The packet should be stopped by the router firewall at this point, but it isn't. Why not?

[Reply #23 on:]

I suspect the problem is related to ARP.

That seems like the most likely explanation. If the destination host had been specified by name then we'd expect to see a DNS lookup and it wouldn't be unreasonable for that to happen when the name was specified. However, in this case the destination seems to have been specified as an IP address so the address and port should have simply been stored locally at the client - in this implementation, by sending them to the W5100. It's possible that the W5100 does an ARP lookup for the destination IP at this point, although the timing seems premature to me; since there is no way to indicate or deal with any error in the lookup at this stage it seems strange to initiate the lookup this soon in the transaction and even stranger to then make the client wait for it to complete. It's credible that this is what it does, though. A protocol trace would soon reveal what was really happening.

[Reply #24 on:]

How is that happening? Who or what is programming it?

I programmed it per my netgear 614 router user's manual. Perhaps you should actually refer to good documentation for your issues.

The packet should be stopped by the router firewall at this point, but it isn't. Why not?

I would suspect that a unique identifier is located in the transport layer of thr UDP packet, generated when the UDP client process generated the packet. You haven't looked?