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

Getting UnknownInterfaceException in docker while tshark works #681

Open
oresot opened this issue Jan 11, 2024 · 0 comments
Open

Getting UnknownInterfaceException in docker while tshark works #681

oresot opened this issue Jan 11, 2024 · 0 comments
Labels

Comments

@oresot
Copy link

oresot commented Jan 11, 2024

Describe the bug
I want to run pyshark in a sidecar container in Kubernetes, but while starting a LiveCapture like this:

import pyshark
capture = pyshark.LiveCapture(interface="eth0")
for packet in capture.sniff_continuously(packet_count=5):
    print('IP: {} Length:{}'.format(packet.ip.src, int(packet.ip.len)))

I'm getting the error:

pyshark.capture.live_capture.UnknownInterfaceException: Interface 'eth0' does not exist, unable to initiate capture. Perhaps permissions are missing?
Possible interfaces: ciscodump
Cisco remote capture
dpauxmon
DisplayPort AUX channel monitor capture
randpkt
Random packet generator
sdjournal
systemd Journal Export
sshdump
SSH remote capture
udpdump
UDP Listener remote capture
wifidump
Wi-Fi remote capture

I tried running the tshark command and it can actually capture packets:

root@test:/# tshark -i eth0 -P
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
tshark: cap_set_proc() fail return: Operation not permitted

tshark: cap_set_proc() fail return: Operation not permitted

 ** (tshark:144) 14:03:16.756729 [Main MESSAGE] -- Capture started.
 ** (tshark:144) 14:03:16.756902 [Main MESSAGE] -- File: "/tmp/wireshark_eth0W4RXG2.pcapng"

    1 0.000000000 fe80::88b:b0ff:fe4b:875 → ff02::2      ICMPv6 70 Router Solicitation from [...]
    2 507.908007438 fe80::88b:b0ff:fe4b:875 → ff02::2      ICMPv6 70 Router Solicitation from [...]
    3 1638.400006110 fe80::88b:b0ff:fe4b:875 → ff02::2      ICMPv6 70 Router Solicitation from [...]
    4 1757.230692304   10.0.10.41 → 192.168.69.145 TCP 66 11662 → 80 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM WS=2048
    5 1757.230728360 0a:8b:b0:4b:08:75 → Broadcast    ARP 42 Who has 169.254.1.1? Tell 192.168.69.145
    6 1757.230742211 ee:ee:ee:ee:ee:ee → 0a:8b:b0:4b:08:75 ARP 42 169.254.1.1 is at ee:ee:ee:ee:ee:ee
    7 1757.230747893 192.168.69.145 → 10.0.10.41   TCP 66 80 → 11662 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM WS=2048
    8 1757.230992593   10.0.10.41 → 192.168.69.145 TCP 54 11662 → 80 [ACK] Seq=1 Ack=1 Win=65536 Len=0
    9 1757.231108020   10.0.10.41 → 192.168.69.145 HTTP 135 GET / HTTP/1.1 
   10 1757.231119852 192.168.69.145 → 10.0.10.41   TCP 54 80 → 11662 [ACK] Seq=1 Ack=82 Win=65536 Len=0
   11 1757.231541984 192.168.69.145 → 10.0.10.41   TCP 292 HTTP/1.1 200 OK  [TCP segment of a reassembled PDU]
   12 1757.231713076   10.0.10.41 → 192.168.69.145 TCP 54 11662 → 80 [ACK] Seq=82 Ack=239 Win=65536 Len=0
   13 1757.231727693 192.168.69.145 → 10.0.10.41   HTTP 669 HTTP/1.1 200 OK  (text/html)
   14 1757.231866950   10.0.10.41 → 192.168.69.145 TCP 54 11662 → 80 [ACK] Seq=82 Ack=854 Win=65536 Len=0
   15 1757.232028620   10.0.10.41 → 192.168.69.145 TCP 54 11662 → 80 [FIN, ACK] Seq=82 Ack=854 Win=65536 Len=0
   16 1757.232063484 192.168.69.145 → 10.0.10.41   TCP 54 80 → 11662 [FIN, ACK] Seq=854 Ack=83 Win=65536 Len=0
   17 1757.232196571   10.0.10.41 → 192.168.69.145 TCP 54 11662 → 80 [ACK] Seq=83 Ack=855 Win=65536 Len=0

Seems like the main issue is that tshark -D is not correctly reporting the interfaces, even though capture works:

root@test-traffic-exporter:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
3: eth0@if141: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 

root@test-traffic-exporter:/# tshark -D
Running as user "root" and group "root". This could be dangerous.
1. ciscodump (Cisco remote capture)
2. dpauxmon (DisplayPort AUX channel monitor capture)
3. randpkt (Random packet generator)
4. sdjournal (systemd Journal Export)
5. sshdump (SSH remote capture)
6. udpdump (UDP Listener remote capture)
7. wifidump (Wi-Fi remote capture)

There doesn't seem to be a way to disable the _verify_capture_parameters funtion, even though the parent function says Optionaly verify

def _verify_capture_parameters(self):

To Reproduce
Steps to reproduce the behavior:

Deploy a Pod in kubernetes with pyshark and try to capture packets from eth0 interface.

Expected behavior
The same packets that tshark command is able to capture should be captured by pyshark, but the capture doesn't even starts because a verification fails previously

Versions (please complete the following information):

  • OS: Linux
  • pyshark version: pyshark-0.6
  • tshark version: TShark (Wireshark) 4.0.11 (Git v4.0.11 packaged as 4.0.11-1~deb12u1).

Example pcap / packet
If applicable, add an example pcap file as an attachment, or post the packet as a hex string or a JSON/XML (export packet dissection in wireshark/tshark).

@oresot oresot added the bug label Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant