On Tue, 11 Sep 2018, Michael Richardson wrote:
Steve Bourland <sbourl...@swri.edu> wrote:
> I'm a little confused, why would the capture mechanism matter for the
> pcap_inject call? I am capturing both senders packets on the same
> machine (a single tcpdump call). I was thinking my next move would be
> to grab the 18.04 kernel and install it on the 16.04 machine to see if
> that triggers the behavior on the 16.04 machine.
I'm sorry, I mis-understood. I read pcap_inject, then immediately forgot
that point... then understood that you were saying that there was garbage
at the end of the captured packets!
So I have no idea.
What kernel versions are involved?
What does strace on each show for the system call that sends the packet?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
No problem, I have found the 16.04 (using 4.4.0-<something>) was "good"
but once I installed kernel 4.15.0-34 it started misbehaving. Now
realized I have a third machine (does have different Intel NIC, but using
the same driver, so a bit of a difference there) that is "well behaved"
running 18.04...with kernel 4.15.0-32, so updating it to 4.15.0-34 to see
if that "ruins" its behavior....
Yes, things broke moving from 4.15.0-32 to 4.15.0-34, so it looks like the
change came with the move from -32 to -33 (the original machines showing
the problem have the -33 kernel installed).
These kernels are what come with Ubuntu 18.04 from Canonical. Should I
file a bug with them or do you have "better pull" and enough information
to follow up on this? I am more than happy to continue to follow this,
but I am going to be an unknown to folks vs. you.
Thanks so much for your help,
Steve
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
