Open jgaulon opened 3 years ago
Currently support for pcapng depends on the libpcap version being used. old libpcap versions do not provide pcapng.
Hi Julien, what capture library and version are you using?
On Mon, Sep 27, 2021 at 12:29 PM Ayoub Kaanich @.***> wrote:
Currently support for pcapng depends on the libpcap version being used. old libpcap versions do not provide pcapng.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/chmorgan/sharppcap/issues/328#issuecomment-928050851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4AH3DNJOZQRAUBCTAETUECLX7ANCNFSM5EZ3SYHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I'm on windows 10 with latest wireshark version x64 3.4.8 and Npcap 1.31. I will install Npcap 1.55 and check is this makes any difference.
Same behavior with Npcap version 1.55, based on libpcap version 1.10.2-PRE-GIT
@jgaulon this seems odd, I think I confirmed things working here on osx. Assuming we don't have a test for pcapng files it could help us in fixing it to add one. Lets see what @kayoub5 says below if we are testing this case or not.
@kayoub5 have you tested with any pcapng files? I can't tell if any of the files in Test/capture_files/ are ng format, 'file' shows:
cmorgan@MacBook-Pro capture_files % file *.pcap
10k_packets.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
arp_request_response.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
arp_with_vlan.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 262144)
ip_packet_bogus_length.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
ipv6_http.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
ipv6_icmpv6_packet.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
tcp.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
tcp_with_extra_bytes.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
test_stream.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
udp_dns_request_response.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 65535)
@chmorgan currently PCAPNG depends on the libpcap/npcap underlying support, this support is limited as best (no multi-interface support for example).
We don't have tests for PCAPNG, since we are not testing libpcap itself, and we don't have any PCAPNG specific code (Libpcap API is the same regardless of the the file format).
The best solution would be to adopt an existing PCAPNG library into dotpcap group, that way we won't have to deal with libpcap specific limitations.
Candidates:
@chmorgan another solution, that does not involve supporting our own PCAPNG implementation is using an existing C one through PInvoke, I am currently maintaining one at https://github.com/Technica-Engineering/LightPcapNg
@kayoub5 I like using that lightpcapng library but I worry that we'd be pulling in more unmanaged code and for portability, if it isn't a performance improvement, using managed code seems like it could be better.
Are any of these options sufficient for us to add them as a dependency? I know we discussed reaching out to see if the authors would want to fold the library into the dotpcap suite.
Thoughts?
I like using that lightpcapng library but I worry that we'd be pulling in more unmanaged code and for portability, if it isn't a performance improvement, using managed code seems like it could be better.
You either use managed code for both PCAP and PCAPNG, or make a wrapper. Don't try to mix unmnaged implementation for some formats (using Libpcap/Npcap), and managed for others (PCAPNG). We are already wrapping many drivers, lightpcapng would just be another one.
Are any of these options sufficient for us to add them as a dependency? I know we discussed reaching out to see if the authors would want to fold the library into the dotpcap suite.
I would prefer to merge projects, or at least make project move to dotpcap group, rather make it a dependency otherwise we risk a "dependency hell" and having to deal with bugs/feature requests that can only be done in the dependency.
@kayoub5 if you'd prefer lightpcapng (and you are the maintainer) then lets go with that for both pcap and pcapng reading/writing. Agree on using the same approach across both pcap and pcapng formats.
@chmorgan I got approval from my employer to open source their C# PCAP/PCAPNG reader/writer (I wrote most of it).
The only condition is that the source files that you will get will keep the Copyright © Technica Engineering GmbH
notice as publicity for them.
Shall I open the PR?
Copyright sounds good, credit is deserved and doesn’t conflict with the project license.
Very good man!!
On Mon, Jan 10, 2022 at 9:00 AM Ayoub Kaanich @.***> wrote:
@chmorgan https://github.com/chmorgan I got approval from my employer to open source their C# PCAP/PCAPNG reader/writer (I wrote most of it).
The only condition is that the source files that you will get will keep the Copyright © Technica Engineering GmbH notice as publicity for them.
Shall I open the PR?
— Reply to this email directly, view it on GitHub https://github.com/dotpcap/sharppcap/issues/328#issuecomment-1008899042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4ACLUDL44PHJSGIGPATUVLQ6LANCNFSM5EZ3SYHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Hi, is there any update regarding PCAPNG support?
Thanks in advance!
The pcagng file format doesn't seem to be supported. When I open (with wireshark Version 3.4.8 on windows 10) the file
[ipv6_http.pcap](https://github.com/chmorgan/sharppcap/blob/master/Test/capture_files/ipv6_http.pcap)
, save it as ipv6_http.pcapng file, and then run the CaptureInfinite() unitest with this new file, the test fails to open the pcapng file and throws a PcapException.The
adapterHandle.IsInvalid
returns true (line 120 in CaptureFileReaderDevice class).Is this an issue? Or is the pcapng format not supported (yet)? Thanks for the support.