This is my ninth week of being an intern at Aeste Works. This week was testing whether the lwIP stack had been configured correctly and whether the interface can be successfully initialized. To initialize the network stack in a lwIP single-threaded core, the function lwip_init is called and then the network interface is brought up by netif_add and netif_setup. To test whether the network interface could be brought up, the netif_is_up function was used which takes in the pre-allocated network structure that was setup by the previous netif_add and netif_setup functions. One of the LED’s on the board would light up signaling that the network interface was successfully brought up.
Once the network initialization was tested, it was time to test the low_level_input function I had written last week that allocates the pbuf structure, copies the payload from the readBuffer of the USB stack and returns it to be processed by the lwIP ethernet_input function. One of the LED’s would toggle once a pbuf structure would be passed to the ethernet_input function. Analyzing this function, there were different ways in which this function would process the pbuf structure. First, the ethernet destination, source addresses and ethertype (used to indicate which protocol is encapsulated in the payload of the frame) in the payload would be stored in a ethernet header structure to be processed. The ethernet destination and source addresses would be mainly used to check if the packet was a multicast or broadcast packet. The ethertype would be used to determine where the payload would go next. For example, the payload would be passed to the ip layer if it were an ip ethertype or it would be passed to the ARP module if it were an ARP ethertype and so on. One of many of the ethernet packets observed on Wireshark would be of an ip ethertype and thus should have passed the payload to the ip layer. However, testing with the LED’s on board, showed that it never does but would only free the pbuf structure containing the payload once the ethernet_input receives it.
I was stuck with this issue for some time in understanding the whole structure of the payload on Wireshark. One solution was to strip the first 64 bytes USB header information of the ethernet packet by offsetting the start of the transfer from the readBuffer to the payload by 64. I tested whether or not the USB header information was included in the actual payload by getting the number of bytes read from the device and found that it doesn’t include the header information. I would have to find an alternative and I hope I can finish all this by next week.
0 Comments