Re: netcat: datagram client blocks indefinitely after EOF

I notice now that I forgot to include help/usage changes. But more importantly, after playing with this patch a bit more I find that while it "seems" to work in a single-core VM, in other situations this can lead to a race between client and server. What happens is that the client fires off its

Re: netcat: unix datagram listener dies if peer is unbound

astian: > If a client sends a unix datagram without having bound the socket to an > address, the recvfrom in the server will return an empty-path, > smaller-than-normal (16 bytes instead of 106) sockaddr_un on OpenBSD, FYI, after testing a bit, it seems that other kernels will al

netcat: misleading error message

When a client nc fails to bind a unix datagram socket to a path it prints an error message but it mentions the remote socket path instead: $ rm -f /tmp/srv; nc -vUul /tmp/srv & Bound on /tmp/srv $ touch /tmp/cli $ nc -Uu -s /tmp/cli /tmp/srv nc: /tmp/srv: Address already in use It

netcat: fix report_sock-related bugs

There were 3 related bugs here: 1. The same report_sock call would sometimes print information about the peer socket and sometimes about the local socket. This confusion may have been enabled by its duplicitous API. This is fixed by dropping the path parameter and renaming it to

netcat: unix datagram listener dies if peer is unbound

If a client sends a unix datagram without having bound the socket to an address, the recvfrom in the server will return an empty-path, smaller-than-normal (16 bytes instead of 106) sockaddr_un on OpenBSD, which netcat does not check and uses in a subsequent connect(), which is invalid: $ ./nc

netcat: datagram client blocks indefinitely after EOF

Consider: $ nc -Nul 127.0.0.1 9911 & $ echo blah | nc -Nu 127.0.0.1 9911 That client blocks "forever". This is because after EOF in stdin, netcat still waits for a HUP from the remote end of the socket, but this will only work for streams not for datagrams. It would be nice if this didn't

Datagram disassociation should be done via AF_UNSPEC

(Sorry if you are getting this message duplicated, I tried sending it to tech@ before but it seems to get stuck somewhere along the way.) I found this while looking at netcat and it seemed odd: if (family == AF_UNIX && uflag) { if (connect(s, NULL, 0) == -1)

netcat: veiled filesystem prevents access to remote end socket

netcat tries to associate a datagram unix socket to the remote end by calling connect(), but the path of that remote end unix socket has not been "unveiled" and furthermore is arbitrary so it cannot be anticipated. $ nc -vUul /tmp/a & Bound on /tmp/a $ echo asd | nc -vUu /tmp/a Bound on

netcat: user-provided socket path is unlinked

For unix datagram client sockets netcat will either generate a temporary socket path or use the one provided by the user. However it unlinks the file in both cases. Since the path for a listening unix sockets (which is always provided by the user) is not unlinked, for consistency this one should

Re: Datagram disassociation should be done via AF_UNSPEC

Ping? A week ago I also create 6 other threads about netcat, I wonder if they were received. Cheers. astian: > (Sorry if you are getting this message duplicated, I tried sending it to > tech@ before but it seems to get stuck somewhere along the way.) > > I found this while looki