-
Notifications
You must be signed in to change notification settings - Fork 229
RawNetworkInterfaceDriver/labgrid-raw-interface Fixes #1745
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
RawNetworkInterfaceDriver/labgrid-raw-interface Fixes #1745
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1745 +/- ##
========================================
- Coverage 45.3% 45.3% -0.1%
========================================
Files 172 172
Lines 13517 13530 +13
========================================
Hits 6131 6131
- Misses 7386 7399 +13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
The current tcpdump timeout handling does not work. This is supposed to exit after 5 seconds: tcpdump --interface=eth0 -w - -G 5 -W 1 But that does not work if no packets are received. So in order to make the timeout actually work, prefix tcpdump with coreutils' timeout command instead: timeout --signal=INT --preserve-status <timeout> <tcpdump command> By sending SIGINT (`--signal=INT`), tcpdump exits gracefully and finishes writing received packets. Combined with `--preserve-status`, tcpdump's actual exit status is preserved, being 0 even on SIGINT if nothing else went wrong. An alternative would be to use subprocess, but that would prevent us from using `os.execvp()`, replacing the process. So the timeout command is the better approach here. Signed-off-by: Bastian Krause <bst@pengutronix.de>
…ptional The intention of labgrid-raw-interface was to have an optional "count" argument, allowing for packet capture on an interface until a timeout is reached, no matter how many packets are received. This is used when calling: RawNetworkInterfaceDriver.start_record(filename, timeout=10) However, the missing `nargs="?"` kwarg when adding the argument actually required the argument to be given: usage: labgrid-raw-interface tcpdump [-h] [--timeout TIMEOUT] ifname count labgrid-raw-interface tcpdump: error: the following arguments are required: count The original commit introducing the option actually included it [1]. Fix that by re-adding `nargs="?"`. [1] 90cf941 ("helpers: add labgrid-raw-interface helper") Fixes: c1aec37 ("helpers/labgrid-raw-interface: introduce subparsers per program, pass options") Signed-off-by: Bastian Krause <bst@pengutronix.de>
…ture started The expectation of RawNetworkInterfaceDriver.start_record() is that it returns once the packet capturing is running, so later code can start right away generating packets that are received on the interface. This does not work reliably currently because the labgrid-raw-interface helper (wrapping tcpdump) is started via subprocess.Popen(), but that does not mean the capture is actually running just yet. To fix this, wait until the subprocess emits "tcpdump: listening on", which is tcpdump's way of telling that it's now actually capturing. Signed-off-by: Bastian Krause <bst@pengutronix.de>
8801164 to
eef08fe
Compare
|
I think this is good to get merged. |
70f6150
into
labgrid-project:master
Description
Fixes:
RawNetworkInterfaceDriver.record(..., timeout=<timeout>)/start_record(..., timeout=<timeout>)never stopping tcpdump if no packets were received.RawNetworkInterfaceDriver.record(..., count=None)/start_record(..., count=None)calling labgrid-raw-interface leading to an error.RawNetworkInterfaceDriver.record(...)/start_record(...)returning before the actual capture started, leading to missed packetsChecklist
Fixes #1157
Fixes #1320
/cc @JoshuaWatt @nick-potenski