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

I have some hardware connected by Ethernet to an XP system via a USB adaptor. The hardware is sending a UDP broadcast packet to the XP every 3 seconds. Wireshark running on the XP system sees these packets:

Frame 1 (342 bytes on wire, 342 bytes captured)

Ethernet II, Src: 40:5f:c2:b9:21:d1 (40:5f:c2:b9:21:d1), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 0.0.0.0 (0.0.0.0)

User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)

No activity at all is seen in the Ethernet connection status: no packets are received.

The Windows firewall is disabled.

An AVG firewall is set to pass these packets and is not showing any being blocked (if I disable the permission to pass the packets, I then see them being blocked).

Any suggestions as to what is dropping these packets and how to let them through to my program?

asked 23 Dec '12, 06:22

Peter%20Robertson's gravatar image

Peter Robertson
15346
accept rate: 0%


Other people seem to have the same problem and it looks like TI did it intentionally.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/57903.aspx

Cite TI Employee: "Regarding the BOOTP packet. The DM648 BOOTP format is TI specific and will not work with standard BOOTP server. You will have to use a custom server which accepts all 0 as IP address."

Cite TI Employee: "There is no detailed documentation on how to write the server. You can use PCAP library (http://en.wikipedia.org/wiki/Pcap) to achieve these functionalities (capture and send the packet). I have used RAW sockets to send/receive the packets."

So, they also recommend (win)pcap :-)

http://www.ti.com/lit/ug/spruec6g/spruec6g.pdf

Cite: The Ethernet-ready announcement frame is made in the form of a BOOTP request so it can use a standard format. No response is processed for this message and it is constructed in such a way that most if not all BOOTP and DHCP servers discard it.

Aha !

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/t/67820.aspx

So, WinPcap sounds like a possible solution. However, I'm not sure if you will be able to establish a complete communication that way (delivering a firmware image to the DSP). I'm sure you will figure out.

The other option would be to use Windows 7 as BOOTP server, as you said raw sockets do work there, even with the destination ip address of 0.0.0.0. HOWEVER I would not rely too much on that 'feature' as that is probably not intentional and Microsoft may change that behavior without notification.

One last idea: You could try to enable IP Forwarding on Windows XP. Maybe the packet then gets far enough into the IP stack to intercept it with raw sockets.

Good luck!

Regards
Kurt

permanent link

answered 25 Dec '12, 14:52

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 26 Dec '12, 06:46

Following your suggestion, I have managed to get this working using WinPcap to detect the BOOTP packets and then switching to sockets for the actual two-way communication once the MAC address of the DSP has been determined.

It looks like another 'feature' that TI hasn't bothered to think through properly.

Thanks for your work on this.

(25 Dec '12, 23:19) Peter Robertson

Following your suggestion, I have managed to get this working using WinPcap

Good to hear !

It looks like another 'feature' that TI hasn't bothered to think through properly.

:-)

Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(26 Dec '12, 00:04) Kurt Knochner ♦

I recommend to uninstall AVG. Not having any message in the log, does not mean that AVG works flawlessly ;-)

BTW: What you do see, if you connect your 'hardware' to the on board ethernet port of your WinXP instead of using a USB adapter?

Regards
Kurt

permanent link

answered 23 Dec '12, 07:22

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 23 Dec '12, 07:22

AVG is not the problem; I get identical behaviour on another system without AVG installed. Connecting the hardware direcly to XP also changes nothing. In both cases, Wireshark continues to see the packets but the status shows nothing received.

It is fairly clear that something in XP itself is discarding the packets.

The program I need to run manages to connect to port 67, so it's not as if something else is listening there.

(23 Dec '12, 07:39) Peter Robertson

O.K. the packet you have shown, looks almost like DHCP, however the destination IP is not 255.255.255.255 (broadcast address).

Do you have any software on WinXP that can handle that special packet?

As the packet is sent to 0.0.0.0 and not 255.255.255.255, your WinXP IP stack may simply ignore (drop/discard) it, as it's neither a packet sent to the broadcast address nor to one of it's configured IP addresses.

What is the output of the following command, after you have seen some packets in Wireshark? Run the command before and after.

netstat -s -p ip

Do you see any changes for these parameters.

  Packets Received                   
  Received Address Errors
  Datagrams Forwarded                
  Unknown Protocols Received         
  Received Packets Discarded         
  Received Packets Delivered         
(23 Dec '12, 13:04) Kurt Knochner ♦

My understanding is that the MAC addr FF:FF:FF:FF:FF:FF indicates a broadcast. The packet is actually a BOOTP packet.

Received address errors appears to be counting the BOOTP packets that are being dropped.

(23 Dec '12, 15:08) Peter Robertson

one other thing - I can read these packets without difficulty under W7.

(23 Dec '12, 15:15) Peter Robertson

My understanding is that the MAC addr FF:FF:FF:FF:FF:FF indicates a broadcast.

That's just the ethernet broadcast and that's the reason why you see the packet in Wireshark. If you want the IP stack to handle the packet, you need to use either an IP broadcast address or one of the configured IP addresses of the Win XP machine.

The packet is actually a BOOTP packet.

well, it looks like BOOTP. However, RFC 951 defines how the packet should look like.

3. Packet Format

   In the IP header of a bootrequest, the client fills in its own IP
   source address if known, otherwise zero.  When the server address is
   unknown, the IP destination address will be the 'broadcast address'
   255.255.255.255.  This address means 'broadcast on the local cable,
   (I don't know my net number)' [4].

So, the packet you have shown is not a real BOOTP packet.

Received address errors appears to be counting the BOOTP packets that are being dropped.

well, there you have it. As I suspected, the IP stack of Win XP just drops those packets.

one other thing - I can read these packets without difficulty under W7.

another IP stack might handle those packets differently.

Conclusion: I don't think there is anything you can do, unless you have the option to change the behavior of Win XP (unlikely) or your 'hardware device'.

(24 Dec '12, 01:24) Kurt Knochner ♦

Thanks for your comments. The device is a DSP from Texas Instruments and they have explicitly chosen those values and have been steadfastly silent about how they expect anyone to read them. AFAIK it's not possible to change what is sent.

(24 Dec '12, 01:24) Peter Robertson

well, then you are out of luck on Win XP.

One possible solution could be the use raw sockets in your application.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740548%28v=vs.85%29.aspx

However there are some limitations with raw sockets, and I leave it to you to check if it's possible to receive those kind of packets with a raw socket.

An alternative would be the use WinPcap within your application to intercept those packets (just like Wireshark does). See the programming guide of WinPcap

http://www.winpcap.org

(24 Dec '12, 01:31) Kurt Knochner ♦

Once again screwed by TI! My application DOES use raw sockets. That's how I know it works under W7.

I'll look at WinPcap.

(24 Dec '12, 01:43) Peter Robertson

Once again screwed by TI!

:-(. The packet is for sure not RFC compliant. You could ask TI for sample code to handle those packets on Win XP.

My application DOES use raw sockets. That's how I know it works under W7.

Then you're out of luck on Win XP. I suggest to ask the same question on stackoverflow.com. Maybe there is a way to make it work on XP.

Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(24 Dec '12, 02:34) Kurt Knochner ♦

"You could ask TI for sample code to handle those packets on Win XP." Why do you think I said they have been steadfastly silent?

(24 Dec '12, 03:00) Peter Robertson

Please don't blame those who want to help you ;-)

(24 Dec '12, 03:02) Kurt Knochner ♦
showing 5 of 11 show 6 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×166
×87
×23
×14

question asked: 23 Dec '12, 06:22

question was seen: 4,911 times

last updated: 26 Dec '12, 06:46

p​o​w​e​r​e​d by O​S​Q​A