Fails to capture traffic from most non-physical interfaces about sniffnet HOT 13 CLOSED

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

from sniffnet.

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)

from sniffnet.

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?

from sniffnet.

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.

from sniffnet.

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?

from sniffnet.

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.

from sniffnet.

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?

from sniffnet.

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

from sniffnet.

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.

from sniffnet.

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.

from sniffnet.

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.

from sniffnet.

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

from sniffnet.

Related issue: JulianSchmid/etherparse#78

from sniffnet.