DNS Malformed Packet

Question

I’m trying to set up DNS using the W5100S and ioLibrary on my TI CC1310 (32-bit) ARM processor. I’m running into a problem where the data that is arriving at the gateway is completely different to the data in the buffer that I am initialising with dns_init() and sending with dns_run(). I can see this buffer being correctly constructed with all the right DNS packet data, but I see it coming out on wireshark as ‘Malformed’. My code: // Resolve an IP address from given domain name static void dnsRequest(void)//(void* domain, uint8_t* ip) { int32_t ret; uint8_t dns[] = {192,168,1,101}; // temporarily use PC IP to view dns request DNS_init(SOCKET_DNS, dnsBuf); // SOCKET_DNS = 3; dnsBuf length = 256; ret = DNS_run(&dns[0], domainName, domainIp); // TOOD doesn't work (wrong if(ret){ ret=0; } } The packet: image758×587 23.7 KB I can see the packet in its correct form all the way through to wiz_send_data() in w5100s.c, so I am fairly certain the data at the address in the buffer pointer is not being corrupted. Anyone have any idea?

becky · Answer

image1003×564 22.8 KB I tested DNS using the W5100S-EVB and ioLibrary. But it worked well. I see flag is wrong in your packet unlike my packet. Opcode is not 1010, it should be 0000. Likewise, Questions is not 4164, it should be 1. So i think there may be a problem with your hardware, interface or environment.

CraigTZ · Answer

As a follow up to this, I’ve also read back the socket Tx buffer on the W5100S and have seen that the memory does in fact store the correct data. My process was: WIZCHIP_READ_BUF() to read socket tx buffer → view in debugger initialise new packet data buffer call sendto() function, passing the packet data buffer WIZCHIP_READ_BUF() to read socket tx buffer → observe change in data in that buffer So it seems the data is being written where it’s being told… When wizchip_send_data is called I can see where the data is being put in memory, which seems to be based on some calculations and a call to getSn_TxBASE(Sn). I’ve looked the values for each socket: Socket 0: 0x4000 (txBase) Socket 1: 0x4400 Socket 2: 0x4800 Socket 3: 0x4A00 You’ll notice that there is only 1KB between those memory locations, but in my initialisation sets all Tx and Rx buffers at 2KB! So it seems that the chip is assuming the buffers are 2KB long, but the driver is treating them as if they are 1KB. Funnily enough, if I send data to socket 2 (txBase+21KB), then send to socket 1 (txBase+11KB), I will see nonsense in the first packet and the first packet’s data coming from the second packet: Send “Sck2” to socket 2 → nonsense packet comes out Send “Sck2” to socket 1 → “Sck2” comes out Either the ioLibrary driver has an error in it, or I am missing an additional step to configure the socket Tx buffer size in the chip.

becky · Answer

image570×728 123 KB This is the W5500’s Memory organization. The W5100S is similar to this. Therefore, CraigTZ: You’ll notice that there is only 1KB between those memory locations, but in my initialisation sets all Tx and Rx buffers at 2KB! it is not true. There is 2KB of physical memory. If you can give me your firmware, I’ll check. Please email me at becky@wiznet.io.

CraigTZ · Answer

I’m not near my computer right now, but I can send firmware later. I know there is supposed to be 2kB of memory, but there definitely is only 1kB between socket memories when the tx memory is written. I can literally see the memory locations it is trying to access and they are 1024 bytes apart! So what I am seeing is the ioLibrary is storing the socket TX buffers only 1kB apart, but reading as if they are 2KB apart. This explains a few other issues I had been seeing with incorrect packet data. I had mistakenly thought socket 0 and socket 1 worked, but socket 1 was in fact just seeing what I had previously tried to write from socket 2. I feel like I may have just missed some sort of configuration step because as you say this is not how it’s supposed to be. Can you look at the w5100_init function I posted and let me know if I have missed anything? Or are there any other strange config options/defines required? For now I have implemented a quick hacky fix which multiplies the socket tx memory offset by two so it stores the packet in the correct location for the chip to send from. uint32_t getSn_TxBASE(uint8_t sn) { int8_t i; #if ( _WIZCHIP_IO_MODE_ == _WIZCHIP_IO_MODE_BUS_DIR_) uint32_t txbase = _W5100S_IO_BASE_ + _WIZCHIP_IO_TXBUF_; #else uint32_t txbase = _WIZCHIP_IO_TXBUF_; #endif for(i = 0; i < sn; i++) txbase += (getSn_TxMAX(i)<<1); // HACKY FIX: bit shift to work for 2KB memory sizes! return txbase; }

CraigTZ · Answer

Hi, I’ve already done as much as I feel I can to resolve this myself… I spent an entire day troubleshooting this to find and understand the source of the problem before implementing a fix that I feel may not be necessary. I would really appreciate some help from WIZnet to figure out how this problem happened and how to resolve it without implementing a hacky fix to the driver. Thanks

CraigTZ · Answer

Still waiting on a real resolution for this! I’m also apparently not getting the correct information back from my DNS request. I can see I am getting a packet received, but it contains no information. I’m thinking it could be a similar issue to this memory misalignment.

CraigTZ · Answer

STILL waiting on a reply from WIZnet on this issue!

becky · Answer

Sorry, CraigTZ: Hi, I’ve already done as much as I feel I can to resolve this myself… I spent an entire day troubleshooting this to find and understand the source of the problem before implementing a fix that I feel may not be necessary. I would really appreciate some help from WIZnet to figure out how this problem happened and how to resolve it without implementing a hacky fix to the driver. Thanks I thought you solved the problem because of this post. In fact, I have experienced this situation. I also debugged it like you did to make sure the data fits in buf, but the actual packet was sent with different data. So i downloaded the latest version of iolibrary and created a new project, thus the same code worked. I think there is a problem with your project configuration or interface. So hope you like me too.

CraigTZ · Answer

Thanks Becky, it does appear there has been a fix issued at some point. If there isn’t one already (I can’t find one) perhaps it would be a good idea to maintain a public changelog and release notes to allow people to identify if their problems have been solved? Its difficult to know without this. I also noted that there is possibly another error in the latest version: line 542 of dns.c makes a call to wizchip_close() function which does not exist.