Using Example 4: basic cap no callback why is the Local Host data Ethernet II and not IP

[Terry550]

I ran your example 4, basic cap no callback to capture Local Host data, and then opened my saved .pcap file in Wireshark (v3.4.4).
It appears the local host data was recorded but not sure why it shows up in Wireshark as Ethernet II and not IP TCP.
Is this as expected?
Thanks
Terry

[Terry550]

I've attached my VS2015 dotnetframework v4.6.1 solution and a pcap file I captured for loopback adapter.
Any help would be greatly appreciated.
Thanks
Terry
LoopBack_Capture_VS2015_NetFW4.6.1_SharpPcapv5.4.zip
EMS_EthernetMonitorServer_WPCAP_NPCAP LocalHost Example.zip

[chmorgan]

Hi @Terry550. What adapter are you capturing from? I'm trying to recall the specifics, something about when you capture at the loopback layer where you end up losing the link layer type comes to mind.

Looking at the captured data it doesn't look like Wireshark can decode any of the packets. What happens if you capture from the same device from Wireshark?

[Terry550]

In wire shark the same interface shows up as 127.0.0.1 and Tcp traffic. I’m using packet dot net version 1.2 is there a newer version than that I should be using ?thanks for your help. Terry

…

On Wed, Mar 31, 2021 at 8:58 PM Chris Morgan ***@***.***> wrote: Hi @Terry550 <https://github.com/Terry550>. What adapter are you capturing from? I'm trying to recall the specifics, something about when you capture at the loopback layer where you end up losing the link layer type comes to mind. Looking at the captured data it doesn't look like Wireshark can decode any of the packets. What happens if you capture from the same device from Wireshark? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATMRCJWHHK3MOYERQQQERPDTGPHKVANCNFSM42E2LLCA> .

[Terry550]

Hi chmorgan,
I have more info to provide. I updated to VS2019 and tried the framework 4.8 but had issues compiling it kept saying I need DotNetStandard 2.0 ref but I already had installed the Nuget packet DotNetStandard 2.0 for this project.
So I tried VS2019 with framework 4.6.1, same sample program with the same output results.

I then simultaneously captured your capture sample program (vs2015 version) along w/ wireshark to compare the results.
I compared the two (@same timetag) and found the difference seems to be that SharpPcap doesn't recognize Encapsulation type Null/Loopback. I attached pics of the comparison of the two.

Thanks for your help!
Terry

[Terry550]

I noticed Closed Issue #17 seems to talk about the same issue.
I'm using Nuget release SharpPcap v5.4 and PacketDotNet v1.2, Did the fix get rolled in a later version?
Did it get fixed for both Linux and windows?
Thanks,
Terry

[chmorgan]

@Terry550 what capture library are you using? npcap 1.2? I'm asking because looking at your code there shouldn't be any modification to the packets by SharpPcap or npcap. So maybe Wireshark is writing to it differently?

[Terry550]

Hi chmorgan,
Thanks for getting back with me.
I'm using NPcap v1.20 and the file versions found in the System Npcap folder are:
wpcap.dll (1.10.1 - PRE-GIT)
packet.dll (5.1.20.305)

In your example I had to modify the following line because it would compile for me:
device.Open(mode: DeviceModes.Promiscuous | DeviceModes.DataTransferUdp | DeviceModes.NoCaptureLocal, read_timeout: readTimeoutMilliseconds);
to
device.Open(mode: DeviceMode.Promiscuous, read_timeout: readTimeoutMilliseconds);
Maybe that will be a hint.

Have you had a chance to run my solution to see if it gives you the same pcap output?
Thanks,
Terry

[Terry550]

I'm wondering if you have a newer version of libpcap since it says "PRE-GIT" when I look at the properties.
Also, maybe the newer version allows this device.Open method:
device.Open(mode: DeviceModes.Promiscuous | DeviceModes.DataTransferUdp | DeviceModes.NoCaptureLocal, read_timeout: readTimeoutMilliseconds);

[kayoub5]

@Terry550 how did you create the pcap writer, and did you create it before or after opening the device?

[Terry550]

I created the capturefileWriterdevice as a static and opened the writer after opening the device. Today I ran the NPCAP example called savedump.c on the loop back adapter and the capture looked good in wireshark but still can’t get the Sharp Pcap to work. Thanks Terry

…

On Fri, Apr 2, 2021 at 1:27 PM Ayoub Kaanich ***@***.***> wrote: @Terry550 <https://github.com/Terry550> how did you create the pcap writer, and did you create it before or after opening the device? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATMRCJSJQAKZJ766KBRKJ3DTGYEBXANCNFSM42E2LLCA> .

[kayoub5]

that would be the issue, you did not provide the link layer argument to the writer, so it's using ethernet link layer by default

[Terry550]

Should the link layer type be null?

…

On Fri, Apr 2, 2021 at 2:35 PM Ayoub Kaanich ***@***.***> wrote: that would be the issue, you did not provide the link layer argument to the writer, so it's using ethernet link layer by default — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATMRCJUTMF6ENB6S5MJUEUDTGYL6PANCNFSM42E2LLCA> .

[kayoub5]

The link layer is device dependent, see LinkLayer property of the device.

For npcap loopback it is null.

[Terry550]

Yea! That worked. So if I want to capture loopback traffic and non-loopback traffic to the same Pcap File is that possible using only one capture writer. Or can I use multiple capture writers writing to the same Pcap file?

…

On Fri, Apr 2, 2021 at 3:16 PM Ayoub Kaanich ***@***.***> wrote: The link layer is device dependent, see LinkLayer property of the device — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATMRCJUSGGAXEY4BTXU35ETTGYQYXANCNFSM42E2LLCA> .

[kayoub5]

In a normal pcap file, you can't mix multiple link layers, it's a file format restriction, not a writer restriction.
however, pcapng files can do it.
for pcap some special link layers like ppp can be used as wrapper for other link layers.

[chmorgan]

Doesn’t libpcap support pcapng format now? Is there an API flag that lets the user select which format is to be used? I can’t remember seeing any.

…

On Fri, Apr 2, 2021 at 4:37 PM Ayoub Kaanich ***@***.***> wrote: In a normal pcap file, you can't mix multiple link layers, it's a file format restriction, not a writer restriction. however, pcapng files can do it — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJH4AAAUWB7BYP55PM2W7DTGYTJNANCNFSM42E2LLCA> .

[kayoub5]

Ironically, libpcap support for PCAPNG is extremely limited:

• It only supports reading PCAPNG
• It only supports reading a PCAPNG that contains one link type, see https://github.com/the-tcpdump-group/libpcap/blob/bcca74d2713dc9c0a27992102c469f77bdd8dd1f/sf-pcapng.c#L1237

[Terry550]

Thank you guys for your EXPERTISE!! And solving my issues!

…

On Sat, Apr 3, 2021 at 5:38 AM Ayoub Kaanich ***@***.***> wrote: Ironically, libpcap support for PCAPNG is extremely limited: - It only supports reading PCAPNG - It only supports reading a PCAPNG that contains one link type, see https://github.com/the-tcpdump-group/libpcap/blob/bcca74d2713dc9c0a27992102c469f77bdd8dd1f/sf-pcapng.c#L1237 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATMRCJUKXOAUYXZFJXA255LTG3VYTANCNFSM42E2LLCA> .

[kayoub5]

@chmorgan both this issue and #174 originate from the fact that the writer does not check that the packet link layer and the file link layer matches, maybe we should add a check and make it throw to avoid any confusion?

[chmorgan]

Yeah that does seem like a good idea. There doesn’t seem to be a better way to do without checking each packet...

…

On Sat, Apr 3, 2021 at 10:44 AM Ayoub Kaanich ***@***.***> wrote: @chmorgan <https://github.com/chmorgan> both this issue and #174 <#174> originate from the fact that the writer does not check that the packet link layer and the file link layer matches, maybe we should add a check and make it throw to avoid any confusion? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJH4AHDA56WXTZBJVZSST3TG4STHANCNFSM42E2LLCA> .