1

I'm sorry if this question has already been asked but I haven't found it.

I have a netcat server listening on a local port and redirecting output to file.

nc -l -u -p 11000 > test.json

That's all well and good. The problem is that the 3rd party executable writing to that port is sending packets without any termination characters (e.g., carriage return or line feed). I know this because I've captured the packets in wireshark and inspected them. As a result the messages appear to be stuck in a buffer at some point and never get written.

The only work around I've found is to send spoofed packets from the 3rd party executable containing a line feed. These spoofed packets cause whatever buffer is capturing the messages to clear and redirect output to file at that point.

Here is an example of a spoof command that clears the buffer.

"" | nc -u -s 127.0.0.1 -p 61618 localhost 11000

My assumption is that the buffer exists within nc given that it seems to be source specific (i.e., I have to spoof the source of a packet to get the buffer to clear). The obvious solution would be to append line feeds to the packets I care about but unfortunately I don't have control over the 3rd party executable writing these packets.

Any suggestions? I'd rather not write an entire application to simply capture messages and write them to file. My shell environment is PowerShell so pseudo workarounds such as stdbuf or unbuffer don't work for me (and these wouldn't help anyways if the buffering is occurring in netcat as I suspect).

Mark Rucker
  • 6,952
  • 4
  • 39
  • 65
  • I am not sure why this is tagged PowerShell, as it's not a PowerShell code issue/feature or control. ***Yet, you show you have a successful workaround***, so, why bring PowerShell into the mix? The 3rdP thingy is the controller as you've noted, and PowerShell cannot change that. Having PowerShell get StdOut from 3rdP thingies is a thing, but if that 3rdP thingy is not giving it up, then that is a catch22. – postanote Jun 06 '21 at 01:05
  • Similar question: https://superuser.com/q/429128/1077440 – stackprotector Jun 06 '21 at 06:57
  • @stackprotector I had found that question but it doesn't quite seem to be the same. I'm fairly sure the OP wants to send the messages without end lines not receive them. – Mark Rucker Jun 06 '21 at 14:31
  • @postanote I'm not 100% certain the behavior is caused by nc. I actually haven't been able to find any documentation that indicates that nc buffers, it just seems to be the case here. I think it is still possible for the buffering to be happening in powershell redirection in which case powershell matters. Also, yes I have a work around but as I say I was looking for a better answer with this question. – Mark Rucker Jun 06 '21 at 14:42
  • 1
    @postanote I've done some more testing. There do appear to be "workarounds" in powershell if I want to write to default. That is, I can get the output to write to console without buffering using the solution in https://stackoverflow.com/a/40488979/1066291. So, if I could find a way to redirect to file without powershell telling nc that I'm redirecting I think I'd have an answer. – Mark Rucker Jun 06 '21 at 16:18

0 Answers0