I am trying to debug why a DNS query packet that looks perfect on Wireshark is not getting a response from our network (sent from our embedded project prototype). I have looked at an almost identical packet from Windows when issuing a PING request. I first did a "ipconfig /flushdns" to make sure I got the DNS query from the PING request. The only thing I see that is different (that I think makes a difference) is that our ethernet controller puts an extra 0x00 as the last byte of the packet, making it 1 larger than the Windows generated DNS packet. Wireshark says it is a VSS Monitoring Ethernet Trailer. What is that? I haven't found anything online that says what that is used for, or if that is my issue or not. Apparently, my ethernet controller does that. If someone says that shouldn't matter, I can post my two packets (my prototype and Windows). Maybe someone can figure out what is different. I have gotten DHCP and ARP packets to work, just not the DNS yet. Also, does anyone know which packet headers (IPV4, etc) actually require the checksums to be present. I've just not used them (0x00 0x00), and everything seems to work. I'll do the checksums later, but wanted to know if any of them were required in other ethernet packets. Thanks. Sutton asked 13 Dec '16, 15:18  dodge55 showing 5 of 6 show 1 more comments |
One Answer:
Let's start with the checksums:
So if you did not calculate the IP checksum, that is probably the reason why it was not processed. If you did calculate the IP checksum, then something else might be wrong. In that case, could you post the packets somewhere (cloudshark, dropbox, onedrive, etc.)? answered 14 Dec '16, 00:46  SYN-bit ♦♦ Thanks for your reply. I've posted the packets on CloudShark. The first packet (#32) is my Windows Ping DNS query, which is followed by the response. The packet at #205 is my embedded system sending out a DNS query, which never receives a response. Not sure why. Maybe you can spot something. https://www.cloudshark.org/captures/98f030ba8df9 Here is a filter so you only have one screen. eth.addr == 70:B3:D5:B8:20:04 || udp.port == 68 || udp.port == 67 || ip.addr == 10.0.0.184 || eth.addr == 70:B3:D5:B8:20:09 || ip.addr == 10.0.0.62 Thanks. Sutton (14 Dec '16, 06:17) dodge55 When I open your capture file and enable checksum checking in the IP and UDP protocol preferences, I see that both are not correct. So that is why your DNS request is not answered. Please review your checksum calculation routines... (14 Dec '16, 07:16) SYN-bit ♦♦ Another packet capture. Packet #105. Still no reply. UDP CS of 0x7eba and IPV4 CS of 0x25e6 should be correct now. Wireshark doesn't display any FCS regardless of what packets are captured. Not sure why. My controller documentation (ENC28J60) says it does the FCS and host doesn't need to do it. (14 Dec '16, 12:51) dodge55 Most network cards remove the FCS before passing the frame towards the driver (and before libpcap or winpcap sees it), so that is why you don't see the FCS. IP checksum is now correct, however, UDP checksum is still incorrect: Did you include the pseudo-header in your checksum calculation? (14 Dec '16, 13:11) SYN-bit ♦♦ I'll recheck. I had another person confirm 0x7eba. However, doesn't the IP CS include the UDP CS? I used UDP CS 0x7eba in the IP calculation. So, how could the IP be correct? The IP CS starts with the 0x45 0x00 bytes. The UDP CS starts with the 0xC0 0x00 bytes. (14 Dec '16, 14:34) dodge55 Also, I noticed on a Windows DNS query (on our network) that the IP checksum is 0x00 0x00, which I assume is optional. You indicated I should calculate that, which is probably a good idea. But, is it really optional? (14 Dec '16, 14:44) dodge55 I recalculated and still got 0x7eba. Not sure how you arrived at 0x69b5. I'm starting at 0xc0 0x00 thru the end of the packet. (14 Dec '16, 14:50) dodge55 I went into WireShark preferences and under UDP protocol checked "Validate UDP checksum" and it failed. But, the Windows DNS query that works from the command prompt window fails the CS too when this checkbox is enabled. So, not sure what's up with that. Still not sure how to get 0x69b5. Add bytes in groups of 2 until the end of the packet. Add the carry. Flip the bits. (14 Dec '16, 14:56) dodge55 As I see ARP packets with a length of 42 bytes from your Windows PC in in the first tracefile, I assume the packet capture was made on the Windows PC. This means you see the outgoing network packets before they are handled by the NIC. Most network drivers these days offload checksum caclculation of the IP/UDP/TCP layers to the NIC, therefor in the capture they appear invalid, while on the network they are indeed valid. As for the calculation of the UDP checksum, you need to calculate it over more than just the UDP part, you need to add a pseudo header and calculate over the pseudo header too. There is an example on http://www4.ncsu.edu/~mlsichit/Teaching/407/Resources/udpChecksum.html (14 Dec '16, 15:27) SYN-bit ♦♦ I got it working. So thanks for the continued responses. My IPV4 checksum (the only one really necessary) was computing too many bytes. (15 Dec '16, 13:41) dodge55 showing 5 of 10 show 5 more comments |
Note, use
nslookupto generate a DNS request. Ping may or may not require an external lookup as the address may be cached before generating the ICMP echo request which is the true purpose of the ping command.For my Windows DNS query, I do a "ipconfig /flushdns" before my PING. That works.
Ok, type two commands rather than one if you wish, also flushdns requires an elevated prompt.
Thanks for your tip. However, still haven't figured out the DNS issue yet.
Have you seen my last comment on my answer? Your checksums are not correct, that's why the DNS packet is dropped...
I did find a checksum computing bug, and now it appears the checksums are computed correctly. But the DNS packet still doesn't get a reply yet. I've been working on it all day. I will post new packets when I can. Thanks.