On Jan 12, 2018, at 10:56 AM, Ralph Schmieder <ralph.schmieder@xxxxxxx> wrote:
> running tshark on Fedora 26 (TShark (Wireshark) 2.2.8 (wireshark-2.2.8)). I get packets in pcap-ng format from a REST API which I feed via stdin into tshark like this:
>
> curl $API | tshark -l -r - -T text
>
> This basically works. However, the output is buffered, despite using the '-l' option.
The output is "buffered" in the sense that it doesn't write every character to the standard output as soon as it's generated; however, all buffered data *is*, in fact, written out at the end of the dissection of each packet, which means -l does what you want...
...as long as TShark *sees* the packets as soon as they're written to the pipe by the program piping to it.
The problem is that the code in libwiretap that *reads* from the capture file - or the standard input - is buffered, even when reading from a pipe, in such a way that 4096 bytes need to have been written by the program piping to TShark before it'll even finish *opening* the input. That means that the first packet probably *won't* be seen by TShark until *several* packets have been written by the program piping to it (enough packets to cause at least 4096 bytes to be written to the pipe).
Please file a bug on this, at http://bugs.wireshark.org/. (Fixing it would be a bit complicated; putting a bug in the bug database 1) leaves a record in the bug database to keep track of the bug and 2) provides a place to put the analysis of the bug.)
> Found the below links, so it seems like I'm not entirely alone.
>
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2874
> https://osqa-ask.wireshark.org/questions/62677/tshark-l-does-not-function-force-tshark-realtime
Those are separate problems. This issue needs its own bug.
