-
Notifications
You must be signed in to change notification settings - Fork 68
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
[FR] fragment order #79
Comments
Good point. I will implement this. -- WIll get back to you shortly. |
Fernando Gont dixit:
Good point. I will implement this. -- WIll get back to you shortly.
Thank you!
|
Fernando Gont dixit:
Is it just fine to e.g. allow reverse order, or would you need more
granularity such as specifying the order as in "Frag #3, Frag #1, Frag
#2"?
For me, reverse order would suffice. I’m adding diagnostics to a qdisc
LKM, and there’s desire to tag TCP/UDP traffic with IPs and ports, so
I need to be able to test fragment info caching.
Thanks,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be great if the tools had switches for ordering the fragments, if fragmentation is enabled. I need to test both “first fragment is received first” and “nōn-first fragment is received first” in the kernel changes I’m working on.
The text was updated successfully, but these errors were encountered: