Fails to capture traffic from most non-physical interfaces

[vi]

Describe the bug

It works for wlan0 or veth interfaces, but fails for non-Ethernet-like things like any or wireguard.

To Reproduce

1. Install sniffnet v1.0.0 using cargo install sniffnet on Linux Debian 11.
2. Start sniffnet.
3. Choose e.g. any.

Expected behavior

It considers the same packets as e.g. tcpdump -i any.

Actual behavior

"No traffic can be observed because the adapter you selected has no active addresses"

or

"No traffic has been observed yet. Waiting for network packets..."

[GyulyVGC]

For the "No traffic has been observed yet. Waiting for network packets..." I can do nothing: it depends on what pcap is actually able to sniff in term of kind of interface.

Thank you for having reported the problem with the "any" interface though, I think I have the solution for that one.

In the meantime, you can observe the traffic by choosing the specific interface (wlan0 and other actually receiving packets)

[3lpsy]

Not sure if it's the same issue, but I get the same message for the any, wg0 (wireguard), and tailscaled0 interfaces. wlan0 works though.

For reference, i'm running Arch linux with the linux-hardened kernel and systemd-networkd for networking + wireguard.

Are there specific flags for outputting debug logs via the cli?

[GyulyVGC]

Not sure if it's the same issue, but I get the same message for the any, wg0 (wireguard), and tailscaled0 interfaces. wlan0 works though.

For reference, i'm running Arch linux with the linux-hardened kernel and systemd-networkd for networking + wireguard.

Are there specific flags for outputting debug logs via the cli?

I confirm that it's the same issue.
And no, currently no debug logs are available in stdout/stderr.

[muzzah]

Similar issue but maybe not identical. I use wirguard on MacOS and tunnel everything through that interface. I am only able to observe updates when selecting the wlan interface but all that shows is that it is communicating with my wg-server endpoint. It does not actually seperate out the different connections being made through wg.

When I select any of the other interfaces in the list, it just says waiting for packets/data.

Is it possible to use something like wg and see what is being sent through the tunnel itself in more detail?

[GyulyVGC]

If no packets are received through a given interface, the problem is not related to Sniffnet itself but to what rust-pcap is actually able to sniffs.

[muzzah]

Understood. Packets are captured as per the screenshot attached. The first entry there in the Network host list is my wireguard server (with the swiss flag). So what happens is every connection gets put under that host so I cannot see the individual connections being made and sent through the tunnel. Its the other tunnel interfaces which seem not to capture any packets.
I guess what my question is, is it possible to unbundle the connections being made so that I can actually see whats being sent through the wireguard tunnel?

[GyulyVGC]

If you click on the network host you are interested in, you will see a list of its connections. Isn't it?

[muzzah]

Not really, I still get everything bundled as per the screenshot below. The two entries in that list are basically the UDP packets (that contain encrypted packets) between my local laptop and the wireguard server. So I still cannot see the details of the connections being made. If I look at the detailed logs, similar results along with what look like ipv6 related entries which have very few packets associated with them.

[GyulyVGC]

Sniffnet currently defines a "connection" by the network-5-tuple:

• Source IP
• Source port
• Destination IP
• Destination port
• Transport protocol

If you see only one connection it means that all the exchanged packets are from/to the same ports.

[muzzah]

Yes, technically that is correct. Because. wireguard being a tunelling protocol, all connections that my laptop makes gets sent through this tunnel from my laptop to the server. The server then acts a forwarding proxy and makes the actual connection to the desired remote server.

So currently sniffnet just sees that all packets are going from my laptop to my server. I guess what I am hearing is that it is not possible for sniffnet to intercept the packets prior to them being encrypted and sent through the tunnel so as to see where the request is actually being made.

Great project though. Thanks for your efforts

[GyulyVGC]

Sniffnet can see everything directly incoming/outgoing to/from your network card.

If it doesn't see some specific interfaces, it's a problem related to pcap which I'd like to better understand myself.

[GyulyVGC]

I think I've finally understood the nature of this problem: so far Sniffnet was only able to read interfaces whose "link_type" was Ethernet.

Today I've found out that I wasn't able to monitor the traffic on my OpenVPN TUN adapter because it uses Null/Loopback as link type (see the screenshot below made using Wireshark).

So, I'm considering to add support for the Null/Loopback with the hope to solve the problem you guys mentioned as well, which is strictly related.

Before proceeding I would like to know if even in your scenarios the link type is Null/Loopback.
You can easily verify it by using Wireshark on the desired adapter and clicking on a packet entry.

Thank you in advance for your cooperation @vi @muzzah @3lpsy

[GyulyVGC]

Related issue: JulianSchmid/etherparse#78

[GyulyVGC]

This issue is being closed by #421
Now interfaces based on raw IP and null/loopback are fully supported by Sniffnet, covering the vast majority of possible use cases and scenarios.

Unluckily, parsing packets from the any interface on Linux is still not supported because this particular interface is based on a peculiar link type (known as LINUX_SLL or Linux cooked) that adds to packets a special header.

I'm opening a separate issue to also keep track of that.