-
Notifications
You must be signed in to change notification settings - Fork 15
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
Duplicated "end" and "idle" events received for some flows #12
Comments
Yeah, this is indeed of interest. Thanks for reporting this. Will investigate asap. |
Can you check if one of those patches fixes your issue? |
Strange, the issue you described does not occur on any of my machines. |
On my OpenWRT box, I launched it with:
If you would like to test yourself, as for the receiver side, I launched my container with:
when running, just limit debug messages to errors (
At the same time, on the container side, check console messages:
and as you can see from the last six lines, there are duplications. I'm attaching here the
|
I further investigated the issue, just to be sure it really was a problem in the "incoming flows", and not related to some bug of my analyzer.
There are some more others.... but I think the above should be enough to start troubleshooting. Cheers, |
I am not sure, but the issue might be related to the UDP endpoint setting. Still investigating. |
While investigating your pcap file, i clearly see this unwanted behavior. But I was still not able to reproduce this on my side. |
I'll close this issue as, even from my side, the behaviour seems to have been disappeared. Should I detect it again, I'll open a new issue. Thanks |
While analyzing my incoming UDP-stream, I noticed that sometime (in the order of once every one thousand) my
nDPId-rt-analyzer
receive two consecutiveend
event or two consecutiveidle
event referred to the very sameflow_id
This lead my analyzer to complain, as it expect that for every flow_id, it should receive only one of
end|idle
event.I double checked my analyzer, and I bet that it effectively received the events twice, despite the fact that they are identical.
I have no problem getting rid of the spurious event... but probably, this could be of some interest to you.
I'm attaching a ZIP containing the JSON-dump of a selection of 4 distinct flows (id: 7337, 30684, 33023, 32921) where you can clearly see the final double events.
duplicated_evts_example.zip
The text was updated successfully, but these errors were encountered: