Just divert packets until the timeout is reached, i.e., don't impose a
hard-coded cutoff of 20 packets. Also exit with status 0 as long as any
packets were received. This makes the utility easier to use in tests
which set up TCP connections, and I believe it won't compromise any
existing tests.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 75770 Build 72653: arc lint + arc unit
Event Timeline
I've stumbled upon that if (npkt >= 20) condition, and now I recall why it's there. Originally, this app was created to test a fix of a defect where a packet could end up in a loop. So, the divert-to.sh test sends a single packet (ping -c1) and the divapp is programmed to catch not only the first one and break a loop eventually. This also explains the strict check at the end to expect a single packet only, if (npkt != 1).
Obviously, this behavior is not useful for other cases like TCP connections. Probably, we want to parameterize it, so we can ask it to break a potential loop after N packets, and by default it would not care about loops. Similarly, it could be optionally instructed to verify that exactly K packets were received (even for intentional K=0 case), and care about capturing at least one by default. That is, the default behavior could be exactly as this patch.
Potentially, we could avoid adding extra logic and just keep this simplest version, if we decide that explicit testing for potential loops is not required.
Probably a simple parameter like in the following patch could be good enough and a bit more descriptive: https://reviews.freebsd.org/D59067.