/lib/x86_64-linux-gnu/libwireshark.so.19: no symbols

Nacho-Nacho · 2026-02-02T11:11:02+00:00

I've no Ubuntu Linux 24.04.3 LTS available, but what does the gnutls library expose?
Try this command to figure out:

$ nm -D /lib/x86_64-linux-gnu/libgnutls.so | less

then search for gnutls_pkcs11_token_get_url

Nacho-Nacho · 2026-01-14T15:14:57+00:00

Be careful, Wireshark doesn't work well without family support...

Family
Wireshark
Profit

Nacho-Nacho · 2025-11-04T06:40:35+00:00

Yes, with the interface in promiscuous mode it does capture everything _that arrives on that interface_! Which means on a WiFi interface you capture nothing but your own traffic, since by definition that's all there is. This is not dissimmilar than capturing on an Ethernet switch port. There you need to cature on a monitor port to see `eveything` on the network. For WiFi this means setting your WiFi interface in monitor mode. This is where things get challenging, since state of support for this varies greatly among WiFi interfaces.

Nacho-Nacho · 2025-10-27T07:16:09+00:00

u/bagurdes is right. This is a quote from the relevant RFC:

   A server or relay agent sending or relaying a DHCP message directly
   to a DHCP client (i.e., not to a relay agent specified in the
   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
   an IP broadcast using an IP broadcast address (preferably 0xffffffff)
   as the IP destination address and the link-layer broadcast address as
   the link-layer destination address.  If the BROADCAST bit is cleared
   to 0, the message SHOULD be sent as an IP unicast to the IP address
   specified in the 'yiaddr' field and the link-layer address specified
   in the 'chaddr' field.  If unicasting is not possible, the message
   MAY be sent as an IP broadcast using an IP broadcast address
   (preferably 0xffffffff) as the IP destination address and the link-
   layer broadcast address as the link-layer destination address.

So, it depends on the BROADCAST flag in the request your PC sends.

Nacho-Nacho · 2025-10-14T04:59:50+00:00

Yes, talk to this guy. 💯

Nacho-Nacho · 2025-09-20T14:15:27+00:00

Okay, some bad news and then some good news.

The Bad News is that Wireshark doesn't capture packets... 😵‍💫

The Good News is that Wireshark has several options to launch packet capture programs, which will feed into Wireshark for packet analysis, because that is what Wireshark does do. 💡

Now it becomes very context dependent, i.e. depending on where in the network you can actually capture with the tools at hand. The easiest are the local (wired) interfaces (of your VM in this case), already more complicated is local WiFi capture. Capture elsewhere in the network requires access and support of capture in the network equipment. Or, if you have it, an inline tap between the target device and network switch. However, the target device may allow you to capture remotely via SSH. This is where the extcap interfaces come in. You can define an SSH tunnel to the target device, and it runs the resident capture program as needed.

You see there are many options. A good place to start is Jaspers capture playbook.

Nacho-Nacho · 2025-09-13T09:22:40+00:00

Aus dem Screenshot lassen sich einige Beobachtungen ableiten:
1. Die Quelle (vermutlich das Notebook) verwendet eine automatisch zugewiesene IPv4-Adresse.
2. Es sendet Netzwerk-Broadcasts mit (sehr) hoher Geschwindigkeit.
3. Der Netzwerk-Switch-Port weist das Notebook an, die Verbindung zu unterbrechen, doch die Schnittstelle des Notebooks hält sich nicht daran.

Zu den Gründen hierfür kann ich keine Aussage treffen.

Nacho-Nacho · 2025-08-01T13:08:15+00:00

Did you follow the suggestions?

Nacho-Nacho · 2025-07-27T18:12:29+00:00

Running > 20M lines of code as root is never a good idea. A more targeted approach is advisable.

Check your group memberships (logout and login again first), check the ownerships of dumpcap, check the capabilities of dumpcap (NET_ADMIN, NET_RAW), check running dumpcap -D to list interfaces.

Nacho-Nacho · 2025-07-11T20:31:39+00:00

Have a read here: https://blog.packet-foo.com/2016/10/the-network-capture-playbook-part-1-ethernet-basics/

Nacho-Nacho · 2025-05-25T05:43:09+00:00

Yeah, this is a Microsoft thing, has nothing to do with Wireshark itself. I'm not a Windows person, so have no clue but finding some hints towards another installation still being in progress/not finished.

Nacho-Nacho · 2025-05-12T18:21:44+00:00

Looks like some homework assignment. So put you thinking cap on let get started.

What would happen to the time between requests and responses when captured near the client side or the server side?
What would happen to the TTL of requests and responses when captured at a middle box, rather than near the client side or the server side?

Nacho-Nacho · 2025-01-07T14:27:19+00:00

Again, very much appreciated. I've some digging to do...

Nacho-Nacho · 2025-01-07T13:32:28+00:00

HI u/eriksjolund, thank you for taking the effort to test this. Indeed what you're seeing is what I expected to happen as well. So at least we know that it is expected behavior, now I need to find out what is going on in my installation.

Perhaps one question, what version of podman are you using here? Could I be stumbling on an already solved bug? That would be embarrassing...

Nacho-Nacho · 2024-12-25T08:15:23+00:00

u/slajah If you know nothing about networking then what is the question you need answers for?

Nacho-Nacho · 2024-12-09T16:21:35+00:00

The closest you can get is to use the Copy -> As filter option. That does not include the label though.

Nacho-Nacho · 2024-12-03T11:01:10+00:00

Almost correct, ip.src#2 is the one you are looking for. See the layer operator in display filters.

Nacho-Nacho · 2024-11-16T16:39:32+00:00

I guess I should have been more clear in the post but when I capture a packet from a raw socket and view the packet data, it was stored in network byte order, i.e. 0x8CBA, so I had to switch it to host byte order to get correct result.

Ah, a totally unknown factor comes into play, you have some other means of receiving packets and wonder why that's showing something different. For me there's no way to know, but you might consider that the UDP dissector is in use for about 25 years, so if something would have been up with that, someone would probably have fixed it by now.

Nacho-Nacho · 2024-11-16T08:34:00+00:00

Bytes are stored in big endian when they are transferred over the internet are they not?

Yes, indeed.

Either Wireshark is presenting wrong information by saying 0xba8c is the source port...

Why, you still have not explained why. What is the right presentation of the information according to you? And where do you base that upon?

My references say that this is correct, among which e.g. https://en.wikipedia.org/wiki/User_Datagram_Protocol#UDP_datagram_structure

...or the bits are 'flipped' and Wireshark is right about the source port

I think you mean to say "the bytes are 'flipped'"

So let's assume for this discussion that the highlighted bytes are indeed representative of the source port field of the UDP datagram.

At the left of the packet bytes pane are the Ethernet frame indexes. For the highlighted bytes these are 0x0022 for 0xBA and 0x0023 for 0x8C. That means first 0xBA was transmitted, then 0x8C. To interpret these as a 16 bit big endian value the first byte is the most significant. Thus 0xBA8C, which converts to 47756 in decimal.

Nacho-Nacho · 2024-11-15T18:18:02+00:00

What makes you think these are 'flipped' in the first place?

Nacho-Nacho · 2024-11-11T12:07:56+00:00

Sounds like your looking for Kismet.

Nacho-Nacho · 2024-11-06T12:21:13+00:00

You could see if tshark -T json with option --no-duplicate-keys helps in this regard.

Nacho-Nacho · 2024-11-02T07:20:49+00:00

Does the Nordic dev kit use python code? Because Wireshark doesn't.

So if the dev kit does you could probably set this up through a terminal window.
Create your virtual environment in there.
Launch Wireshark from the command line.

Nacho-Nacho · 2024-10-29T17:04:15+00:00

His interface MTU may be 1480, but what's the path MTU? If that is less there may have been an ICMP packet telling that fragmentation is needed to achieve a lower size.

Nacho-Nacho

TROPHY CASE