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 Robertson |
2 Answers:
Other people seem to have the same problem and it looks like TI did it intentionally.
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 :-)
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 !
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 answered 25 Dec '12, 14:52  Kurt Knochner ♦ edited 26 Dec '12, 06:46 |
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 answered 23 Dec '12, 07:22 Kurt Knochner ♦ 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.
Do you see any changes for these parameters. (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
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.
well, it looks like BOOTP. However, RFC 951 defines how the packet should look like. So, the packet you have shown is not a real BOOTP packet.
well, there you have it. As I suspected, the IP stack of Win XP just drops those packets.
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.
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
(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
:-(. The packet is for sure not RFC compliant. You could ask TI for sample code to handle those packets on Win XP.
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 |
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.
Good to hear !
:-)
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.