Re: [racket-users] Confusion with udp-receive!
Hi Greg, On Wed, Sep 25, 2019 at 3:33 PM George Neuner wrote: > > Hi David, > > On 9/25/2019 1:08 AM, David Storrs wrote: > What you are overlooking is that UDP is a level 4 [end-to-end] protocol, > but you are trying to get level 3 [routing] information. > > Neither UDP nor TCP normally records the path a packet takes - only the > routers themselves know what they do to forward the packet. The path > between 2 machines is never fixed, and it may change abruptly due to > congestion or outage along the way."traceroute" uses a special > (level 3) IP packet which explicitly commands each router along the way > ... and the end destination as well if the packet gets there ... to send > back a response to the traceroute initiator. The path is discovered > dynamically from the responses. I don't think this is correct. NAPT is defined here: https://www.ietf.org/rfc/rfc3022.txt The relevant section is 4.1 (NB: "TU port" means "TCP or UDP port") start quote 4.1. IP, TCP, UDP and ICMP Header Manipulations In Basic NAT model, the IP header of every packet must be modified. This modification includes IP address (source IP address for outbound packets and destination IP address for inbound packets) and the IP checksum. For TCP ([TCP]) and UDP ([UDP]) sessions, modifications must include update of checksum in the TCP/UDP headers. This is because TCP/UDP checksum also covers a pseudo header which contains the source and destination IP addresses. As an exception, UDP headers with 0 checksum should not be modified. As for ICMP Query packets ([ICMP]), no further changes in ICMP header are required as the checksum in ICMP header does not cover IP addresses. In NAPT model, modifications to IP header are similar to that of Basic NAT. For TCP/UDP sessions, modifications must be extended to include translation of TU port (source TU port for outbound packets and destination TU port for inbound packets) in the TCP/UDP header. ICMP header in ICMP Query packets must also be modified to replace the query ID and ICMP header checksum. Private host query ID must be translated into assigned ID on the outbound and the exact reverse on the inbound. ICMP header checksum must be corrected to account for Query ID translation. end quote The firewall that I'm behind, like most modern NAT instances, is a NAPT instance -- a single external address that maps multiple internal addresses based on a semi-randomly-chosen port assigned when the initial connection is made. As stated above, the differences between the two are: Basic NAT rewrites - IP header -- IP address for source (on outbound) or destination (on inbound) -- IP checksum UDP header: UDP checksum NAPT rewrites: - IP header -- IP address for source (on outbound) or destination (on inbound) -- IP checksum - UDP header: -- UDP checksum -- TU port for source (on outbound) or destination (on inbound) In short, the connection should go like this: local machine (192.168.1.221, port 25891) sends message to :54545 by way of router (192.168.1.1). At each step the source/destination are: local machine -> router (source: 192.168.1.221:25891 dest: :54545) router -> AWS-server (s: :X <--- arbitrary port number for this session d: :54545) AWS-server -> router (s: :54545 d: :X) router -> local machine (s: :54545 d: 192.168.1.221:25891 Did I misunderstand something? If not, then I think that the udp-receive! on the AWS server should return IP address and port . This matches when Matt Flatt is seeing, but not what I'm seeing. As yet, I have no explanation, but it's obviously something to do with my specific setup. > > > Hope this helps, > George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKocBySEa-_58_U0Cs2tR%2BMMOG4pwBJqd1Tsd6WLugypQ-g%40mail.gmail.com.
Re: [racket-users] Confusion with udp-receive!
Hi David, On 9/25/2019 1:08 AM, David Storrs wrote: udp-receive! is giving me unexpected results when my local machine -> router -> server shows the UDP port of the process running on the local machine instead of the one from the router. I'm not sure how to get the router's port instead. NAT routing is transparent: you are - or at least, should be - seeing the port number of the remote machine. But remember that - unlike TCP - UDP can send on the same port that it listens to. If the "client" is sending on the same port as the server is listening, you won't be able to distinguish them by port alone. The AWS server does this: (define-values (len senders-host senders-port) (udp-receive! socket buffer)) What I'm actually getting is: senders-host: senders-port: 25890 ; this is the UDP port bound by the process on the local machine What I'm expecting is: senders-host: senders-port: You won't get the address of the router - you'll get the address of the client. (see below) I've been digging through the RFCs for UDP and Traditional NAT (https://www.ietf.org/rfc/rfc768.txt and https://www.ietf.org/rfc/rfc3022.txt) to make sure that I haven't randomly gotten confused about how routers work but it seems to be what I recall: The local machine sends to the router using the port number 25890, the router rewrites it to an arbitrary port number chosen on the fly, the AWS server sees the router's assigned port and not 25890. What am I missing here? I'm sure it's something embarrassingly obvious. What you are overlooking is that UDP is a level 4 [end-to-end] protocol, but you are trying to get level 3 [routing] information. Neither UDP nor TCP normally records the path a packet takes - only the routers themselves know what they do to forward the packet. The path between 2 machines is never fixed, and it may change abruptly due to congestion or outage along the way. "traceroute" uses a special (level 3) IP packet which explicitly commands each router along the way ... and the end destination as well if the packet gets there ... to send back a response to the traceroute initiator. The path is discovered dynamically from the responses. Hope this helps, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/a0373ae3-5246-8b06-ea58-6689059d4d3c%40comcast.net.
[racket-users] Confusion with udp-receive!
udp-receive! is giving me unexpected results when my local machine -> router -> server shows the UDP port of the process running on the local machine instead of the one from the router. I'm not sure how to get the router's port instead. The AWS server does this: (define-values (len senders-host senders-port) (udp-receive! socket buffer)) What I'm actually getting is: senders-host: senders-port: 25890 ; this is the UDP port bound by the process on the local machine What I'm expecting is: senders-host: senders-port: I've been digging through the RFCs for UDP and Traditional NAT (https://www.ietf.org/rfc/rfc768.txt and https://www.ietf.org/rfc/rfc3022.txt) to make sure that I haven't randomly gotten confused about how routers work but it seems to be what I recall: The local machine sends to the router using the port number 25890, the router rewrites it to an arbitrary port number chosen on the fly, the AWS server sees the router's assigned port and not 25890. What am I missing here? I'm sure it's something embarrassingly obvious. Simplified form of code for reference: --- shared code --- (struct Message (message-id attributes) #:prefab) (struct Binding-Request Message () #:prefab) (struct Binding-Success-Response Message () #:prefab) (struct transport-address (ip port) #:prefab) (define (write-to-bytes v) (define out (open-output-bytes)) (write v out) (get-output-bytes out)) --- local machine: --- (define socket (udp-open-socket #f #f)) (udp-bind! socket #f 25890 #t) (thread (thunk (define-values (len senders-host senders-port) (udp-receive! socket buffer)) (log-msg-debug "host: ~a, port ~a, buffer ~a " senders-host senders-port buffer))) (udp-send-to socket default-host default-port (wrap (Binding-Request 17 (hash - AWS server: - The server has its own UDP socket (bound to 54545, fwiw) and a receive loop that identifies the Binding-Request and routes it to the following code: (define-values (len senders-host senders-port) (udp-receive! socket buffer) (define mapped-address (transport-address senders-host senders-port)) (define msg-out (Binding-Success-Response mid (hasheq 'mapped-address mapped-address))) (udp-send-to socket senders-host senders-port (wrap msg-out)) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKocpG6W_vMz%3D0PvveAd-_Y%3DmZVBAwnPZ7cYCKM83TOsBzw%40mail.gmail.com.
