Skip to content
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

Npcap wrong data link type? #1573

Open
bitbanditorg opened this issue Apr 26, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@bitbanditorg
Copy link

commented Apr 26, 2019

When capturing on a WWAN link there is no Ethernet header and Wireshark cannot decode the saved pcap correctly. The reason is that in the capture file LinkType is ETHERNET (or DLT_EN10MB) but the packets don't have ethernet headers, they are starting from the IP header. From the saved file it cannot be determied subsequently how to interpret the packets if the LinkType is wrong. I need to analyze pcap files programatically that's why the correct LinkType is essential.

I cannot override the LinkType by calling pcap_set_datalink (to DLT_RAW), it returns an error since pcap_list_datalinks returns only ETHERNET (1). This is a Sierra modem where the PDN is activated by an AT command (SCACT=1) then the device driver associates an IP address to the network interface. The Interface Type is 243 (IF_TYPE_WWANPP).

Why other link types don't supported/listed only the ETHERNET even though it's not even an Ethernet interface?

Alternatively, is there a way to override the LinkType in the pcap_file_header programmatically before saving the file or I have to write a custom save function and manually generate a pcap header? I don't like to postprocess files with editcap.

Another weird phenomena that pcap_datalink_val_to_name or pcap_datalink_val_to_desc cannot translate DLT_RAW but return nil.

Thanks!

@guyharris

This comment has been minimized.

Copy link

commented May 10, 2019

Do you supply NdisMediumWan in PacketGetNetType() calls for WWAN devices?

Currently, libpcap maps that to DLT_EN10MB; if all devices for which you supply NdisMediumWan in PacketGetNetType() calls provide raw IP packets with no link-layer headers, libpcap could just map that to DLT_RAW. If not, you may have to somehow figure out how to make PacketGetNetType() supply the appropriate NdisMedium value for WWAN devices, and tweak pcap-npf's pcap_activate_npf() appropriately.

Another weird phenomena that pcap_datalink_val_to_name or pcap_datalink_val_to_desc cannot translate DLT_RAW but return nil.

That seems... unlikely. That works in libpcap dating back at least as far as libpcap 1.8.0.

Does DLT_RAW have the value 12, or 14, in your program? (Yes, there are two different values, for binary compatibility reasons; OpenBSD uses 14, every other OS uses 12 - including Windows, unless __OpenBSD__ is somehow getting defined on Windows. That's why we have LINKTYPE_ values on the tcpdump.org link-layer header types page, and write LINKTYPE_ values, not DLT_ values, to pcap and pcapng files, and map between those types in APIs.)

What is returned if you pass the numerical values 12 and 14 to pcap_datalink_val_to_name() and pcap_datalink_val_to_desc()? In WinPcap and Npcap, 12 should give you "DLT_RAW" and "Raw IP" for 12 and NULL for 14.

@dmiller-nmap

This comment has been minimized.

Copy link

commented May 10, 2019

It appears we get this value via a OID_GEN_MEDIA_IN_USE query, which is not supported by NDIS 6.0 and later drivers. I think we need to update to OID_GEN_PHYSICAL_MEDIUM, which I'm guessing may solve a lot of compatibility problems with WAN, VPN, and WiFi drivers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.