Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intermittently rendering blank responses #173

eimermusic opened this issue Feb 12, 2020 · 1 comment

Intermittently rendering blank responses #173

eimermusic opened this issue Feb 12, 2020 · 1 comment


Copy link

@eimermusic eimermusic commented Feb 12, 2020

What OS?

  • [ X ] Windows
  • [ X ] Mac
  • Linux (Which distro?)

Description of issue

Calling a TCP server, it is expected to always output a response. The response is always ascii strings. Simple true/false responses or some data or the string error.

Using Packet Sender on both Mac and Windows I am getting intermittent blank responses rendered in the UI. I cannot find a pattern to it really. Seems to happen most when the response would be false or error. However is does also blank out other responses and occasionally also render false but very rarely the error string. Response times are all within the margin of network transfers. However, in good network conditions (LAN) the blank results seem to all take around 0.01s whereas the expected results take around 0.006s

The reason I am reporting this as an issue with Packet Sender is that nectat (nc) does not output any blank responses (for me, pretty much ruling out the TCP server as the source of the problem).
In other words, the following will always output a response.

echo -n 'string command for the TCP server' | nc 1234
@dannagle dannagle added the bug label Feb 12, 2020
@dannagle dannagle self-assigned this Feb 12, 2020

This comment has been minimized.

Copy link

@dannagle dannagle commented Feb 12, 2020

Thank you for this detailed bug report.

This is a known old problem with the TCP log in Packet Sender. A fix is still in the works. Newer versions will filter out those blank lines.

A detailed report deserves a detailed response.... if you are curious, the bug occurs as it is waiting for responses. It gets an ACK (expected) but the logger treats that like a normal packet with empty data. Thus, an empty line gets rendered in the log.

The reason this bug has persisted for so long: The core problem is the logger is not smart enough to know the difference between bare ACKS and standard packets with empty data. It seems my previous decision, log everything as an empty packet, has caused more confusion than that has helped. The next version will have that filtered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.