[Bug 51818] New: Reporting packet length is always 0
https://bugs.winehq.org/show_bug.cgi?id=51818 Bug ID: 51818 Summary: Reporting packet length is always 0 Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wpcap Assignee: wine-bugs(a)winehq.org Reporter: marc_aurel(a)me.com Distribution: --- Created attachment 70703 --> https://bugs.winehq.org/attachment.cgi?id=70703 same source for linux/mac/win Source code for an example program is attached. I compiled it on linux, mac and windows and it is always working as expected meaning it produces a terminal output like: listening on Pseudo-device that captures on all interfaces... 14:47:05,000000 len:62 Destiny MAC: 00:00:00:00:00:00: Source MAC: 00: 00: 00: 00: 00: 00: etc (blanked out the mac addresses) Wheres running the windows .exe in wine always reports a packet length of 0 (I tested on wine 6.18(linux)/6.16(linux)/6.0(linux/mac)). Modifying the program to show the packet content leads to a segfault in wine but works just fine again on win/linux/mac (which is kinda expected I guess since it thinks the packets are empty). Running native/wine versions side by side you can see that it is capturing the same packets, which are clearly not empty. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #1 from Hans Leidekker <hans(a)meelstraat.net> --- Could you provide build instructions too? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #2 from marc_aurel(a)me.com --- Created attachment 70725 --> https://bugs.winehq.org/attachment.cgi?id=70725 Visual Studio solution -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #3 from marc_aurel(a)me.com --- On *nix it is just gcc wpcap_test.cpp -lpcap -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #4 from marc_aurel(a)me.com --- binaries should also be included in the archive above -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to marc_aurel from comment #4)
binaries should also be included in the archive above
Thanks. The problem is that the structure layout of pcap_pkthdr is different between 64-bit Linux and 64-bit Windows. It's defined like this: struct pcap_pkthdr { struct timeval ts; /* time stamp */ bpf_u_int32 caplen; /* length of portion present */ bpf_u_int32 len; /* length of this packet (off wire) */ }; The size of struct timeval is 8 bytes on 32-bit and 64-bit Windows but on 64-bit Linux it's 16 bytes. This means len is at a different offset (12 vs 20). A 32-bit build of your test app should work. To make this work for 64-bit apps we'll need to convert between native and win32 versions of this structure. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 marc_aurel(a)me.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc_aurel(a)me.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #6 from marc_aurel(a)me.com --- Thanks for looking into it! Unfortunately 32 bit is not an option for my use case… This might be unrelated but I also noticed some c# pcap libraries crashing with a segfault as well when using pinvoke on int pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf); -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- Created attachment 70729 --> https://bugs.winehq.org/attachment.cgi?id=70729 patch Here's a patch that should fix the 64-bit case for pcap_handler(). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #8 from marc_aurel(a)me.com --- As far as I can tell the patch fixes the length issue and even dumping packages just works now :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #9 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to marc_aurel from comment #6)
Unfortunately 32 bit is not an option for my use case… This might be unrelated but I also noticed some c# pcap libraries crashing with a segfault as well when using pinvoke on
int pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf);
Because pcap_if structures aren't compatible, probably. Feel free to open a new bug report for this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #10 from marc_aurel(a)me.com --- (In reply to Hans Leidekker from comment #7)
Created attachment 70729 [details] patch
Here's a patch that should fix the 64-bit case for pcap_handler().
I just tested pcap_next and pcap_next and they have the same issue... Tried fixing it but the program just hangs now -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #11 from marc_aurel(a)me.com --- Created attachment 70730 --> https://bugs.winehq.org/attachment.cgi?id=70730 pcap_next and pcap_next_ex patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #12 from marc_aurel(a)me.com --- pcap_dispatch works fine since it uses the same wrap_pcap_handler -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #13 from marc_aurel(a)me.com --- (In reply to Hans Leidekker from comment #9)
(In reply to marc_aurel from comment #6)
Unfortunately 32 bit is not an option for my use case… This might be unrelated but I also noticed some c# pcap libraries crashing with a segfault as well when using pinvoke on
int pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf);
Because pcap_if structures aren't compatible, probably. Feel free to open a new bug report for this.
Will try to create a minimal working example for that then -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #14 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to marc_aurel from comment #10)
(In reply to Hans Leidekker from comment #7)
Created attachment 70729 [details] patch
Here's a patch that should fix the 64-bit case for pcap_handler().
I just tested pcap_next and pcap_next and they have the same issue... Tried fixing it but the program just hangs now
Yes, I'm working on a patch that should fix all cases. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #15 from Hans Leidekker <hans(a)meelstraat.net> --- Created attachment 70731 --> https://bugs.winehq.org/attachment.cgi?id=70731 patch Can you try these patches? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #16 from marc_aurel(a)me.com --- Can confirm that all functions that return a package header are now working properly, though the c# issue is still present; will open a new bug report about that soon. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |a999d57d6a1757078d678a9ab0a | |e9734a7f8ecc6 --- Comment #17 from Hans Leidekker <hans(a)meelstraat.net> --- Fixed with a999d57d6a1757078d678a9ab0ae9734a7f8ecc6. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 --- Comment #18 from marc_aurel(a)me.com --- *** Bug 51835 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51818 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #19 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.19. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla