This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Packets only received when monitoring with wireshark

0

Hi,

I am sending ARP packets from a DSP evaluation board to software on my laptop, when I have wireshark monitoring traffic the pc software connects to my board and starts its process of sending data out. when I don't have wireshark running it fails to connect, monitoring with Microsoft network monitor instead shows that the arp request from my dsp software isn't being received, if I run both microsoft network monitor and wireshark, I can see on both packages that the ARP packets and subsequent SYN SYN-ACK ACK packets get through.

I'm hoping this is something wireshark is doing for me when it is running which I should be doing myself, does anyone have any idea what could be happening? i'm stumped at the moment and am running out of things to try.

Regards, Graham

asked 13 Mar '14, 03:26

Sly_Raccoon's gravatar image

Sly_Raccoon
6113
accept rate: 0%


2 Answers:

2

Possibly Wireshark is set to enable promiscuous mode which then allows the packet to be processed? I think this question has come up previously here, may be here.

An ARP request is sent to the subnet broadcast address, as by it's nature it can't be directed (the reply is), so maybe your laptop isn't recognising the ARP broadcast for some reason, maybe malformed by your DSP software.

Can you post a sample capture of the traffic somewhere (cloudshark, etc.) and post the link back here?

Edit:

As discussed below, the DSP is sending Ethernet frames that are 18 bytes shorter than the minimum, so the laptop NIC is dropping them when not in promiscuous mode.

answered 13 Mar '14, 04:11

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

edited 13 Mar '14, 09:10

Cheers, I have disabled promiscuous mode on wireshark and it doesn't see the ARP request so that looks like the reason why it worked.

the capture details of the request I am sending are shown below, I am very new to the whole TCP/IP thing but I can't see anyting wrong with it when comparing to other ARP requests.

No. Time Source Destination Protocol Length Info
1 0.000000000 c6:6a:03:ee:08:02 Broadcast ARP 42 Who has 10.
0.0.3? Tell 10.0.0.2
Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Interface id: 0
Encapsulation type: Ethernet (1)
Arrival Time: Mar 13, 2014 11:15:49.933948000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1394709349.933948000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 42 bytes (336 bits)
Capture Length: 42 bytes (336 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:arp]
[Coloring Rule Name: ARP]
[Coloring Rule String: arp]
Ethernet II, Src: c6:6a:03:ee:08:02 (c6:6a:03:ee:08:02), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the
factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: c6:6a:03:ee:08:02 (c6:6a:03:ee:08:02)
Address: c6:6a:03:ee:08:02 (c6:6a:03:ee:08:02)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the
factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: ARP (0x0806)
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: c6:6a:03:ee:08:02 (c6:6a:03:ee:08:02)
Sender IP address: 10.0.0.2 (10.0.0.2)
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 10.0.0.3 (10.0.0.3)
(13 Mar '14, 04:36) Sly_Raccoon

I have set up two .net applications to talk to each other over ethernet, using the same two IP addresses as above and that works, the only difference I could see was the .net applications sent out an extra 18 bytes of 00 value after the data I was sending out. I added this to my DSP software and it works.... nowhere have I seen any reference to what these extra bytes would mean and I havent seen them on any other ARP request packets so i'm still as confused as ever.

(13 Mar '14, 08:18) Sly_Raccoon
1

Minimum Ethernet frame length. It's 64 bytes, and your DSP wasn't doing that.

In your sample the frame length was 42 bytes, which (usually in Wireshark) doesn't include the FCS, so your frame was 18 bytes short. When not in promiscuous mode your laptop dropped the "too-short" frame, but accepted it when promiscuous mode was on.

Adding the padding brought the frame up to the minimum length.

(13 Mar '14, 09:03) grahamb ♦

Aha, no I have written a lot of the software running on the DSP so as I wasn't aware of this minimum length, it wasn't included. the PC i'm connecting to sends out ARP requests which are the same I have above, without the padding bytes so I copied that.

Cheers grahamb, you've been a great help.

(13 Mar '14, 09:25) Sly_Raccoon

@Sly_Raccoon

Doing it the hard way by writing your own stack :-)

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(13 Mar '14, 09:33) grahamb ♦

0

Graham, your DSP device probably does not have the same subnet address as your computer. In order for Wireshark to see an ARP broadcast without having promiscuous mode turned on, the subnet addresses have to match.

The subnet address is the part of the address that is left after being masked by the subnet mask. For example if your computer address is 192.168.1.100, and your mask is 255.255.255.0, the subnet address is 192.168.1.0/32. If your DSM device were broadcasting to the 10.0.0.0/8 subnet, Wireshark (or any other capture software for that matter) would not be able to see it, because the NIC itself would filter it out rather than pass it up the stack. Promiscuous mode just removes that filter, so you see everything that reaches the NIC.

Gil

answered 13 Mar '14, 06:47

Gil%20Yoder's gravatar image

Gil Yoder
112
accept rate: 0%

Why would IP subnets matter for the ARP request which is an Ethernet (MAC) address broadcast?

(13 Mar '14, 07:08) grahamb ♦