Re: nc(1), GNU netcat and FIN segments after all data has been sent
On 06/23/11 21:05, Christopher Zimmermann wrote: ... Maybe you can force nc(1) not to send a FIN segment by using something like this: cat infile - |nc host 1234 This works. Thanks!
nc(1), GNU netcat and FIN segments after all data has been sent
Hello, I've noticed that there's a difference in behavior between nc(1) and GNU netcat when they talk to some daemon via TCP. The commands in the following example are basically the same: GNU netcat: netcat host 1234 infile nc(1): nc host 1234 infile nc(1) sends a FIN segment after all data has been read from stdin: shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. GNU netcat doesn't do this. I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. I think both variants are allowed in RFC 793. Would it make sense to add a further option to nc(1) which allows to toggle between both variants? Regards Andreas
Re: nc(1), GNU netcat and FIN segments after all data has been sent
I've noticed that there's a difference in behavior between nc(1) and GNU netcat when they talk to some daemon via TCP. Note there are 3 netcats. There was the original non-free one by Hobbit; he did not want to free it and the code was quite a mish-mash. Then there was our rewrite, which is now being used by lots of other projects. We made it behave exactly like the original, and then added a few small features. Then there is this new non-free one that some GNU people have written, which is clearly incompatible. One could argue that they can have creative control if they were operating in a vacuum, except they are not. They must follow what the others do, or they are incompatible and broken. If they wrote their own GNU ssh and all the options acted differently from OpenSSH, who do you think would be to blame? They would be. The commands in the following example are basically the same: GNU netcat: netcat host 1234 infile nc(1): nc host 1234 infile nc(1) sends a FIN segment after all data has been read from stdin: shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. GNU netcat doesn't do this. GNU netcat is wrong. The original Hobbit netcat and OpenBSD nc do an early shutdown intentional, to use the full behaviour of sockets. I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. Yes, those daemons are broken. Their select/poll loops are unaware that writeability and readability of a socket is independent. One of the reasons that netcat should do be doing this, is so that such bugs can be triggered. It is a good thing for them to be triggered. The half-open socket semantics are the real world and they happen all the time. I think both variants are allowed in RFC 793. Would it make sense to add a further option to nc(1) which allows to toggle between both variants? There is no variation. Sockets can be half-closed. Sure, a particular client or server could leave it open until completely, but now you are testing less. You are saying it is a variation when you use less than full functionality of a socket? That's not a variation. It's called a subset. But I think your real problem is that GNU netcat is incompatible. Typical.
Re: nc(1), GNU netcat and FIN segments after all data has been sent
Hi Theo, On 06/23/11 18:30, Theo de Raadt wrote: ... I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. Yes, those daemons are broken. Their select/poll loops are unaware that writeability and readability of a socket is independent. One of the reasons that netcat should do be doing this, is so that such bugs can be triggered. It is a good thing for them to be triggered. The half-open socket semantics are the real world and they happen all the time. yes, you're right. I've noticed that the behavior is different while doing some work related stuff with some server software which is proprietary and buggy -- and it probably will never get fixed... The irony is that testing buggy software worked only with buggy software in this particular case. I think both variants are allowed in RFC 793. Would it make sense to add a further option to nc(1) which allows to toggle between both variants? There is no variation. Sockets can be half-closed. Sure, a particular client or server could leave it open until completely, but now you are testing less. You are saying it is a variation when you use less than full functionality of a socket? That's not a variation. It's called a subset. But I think your real problem is that GNU netcat is incompatible. Typical. My problem was related to the server side. I needed GNU netcat in order to trigger (possibly even more buggy) responses from the (buggy) server side. My particular use case was not about right or wrong but about triggering some stuff on the server side. I'm aware that the current behavior of nc(1) is the intended way to handle TCP sessions according to RFC 793. I was not sure if the GNU variant is actually non-compliant. Regards Andreas
Re: nc(1), GNU netcat and FIN segments after all data has been sent
On 06/23/11 14:10, Andreas Bartelt wrote: Hello, I've noticed that there's a difference in behavior between nc(1) and GNU netcat when they talk to some daemon via TCP. The commands in the following example are basically the same: GNU netcat: netcat host 1234 infile nc(1): nc host 1234 infile nc(1) sends a FIN segment after all data has been read from stdin: shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. GNU netcat doesn't do this. I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. Maybe you can force nc(1) not to send a FIN segment by using something like this: cat infile - |nc host 1234 Christopher I think both variants are allowed in RFC 793. Would it make sense to add a further option to nc(1) which allows to toggle between both variants? Regards Andreas
