One step forward, two steps back

So this past week was spent mostly investigating and understanding how exactly a packet arrives at the DE4. We did spend a good time writing a simple algorithm to route packets but unfortunately, we probably won't end up using this as this was more to learn how the routing process works. In doing this, we found a major flaw in our program.

First, we started by tracing how a packet arrives. First we found that it seems to all start in the TK_ENTRY() function defined in netmain() in netmain.c. Here it polls for a change in the queue (rcvdq.q_len) to see if it changed. If the length changed, it will call the function pktdemux() which should then call the ip_rcv function to demux and then ip_rcv_phase2() which will attempt to route the packet.
Next we looked into how the queue is changed. First, there is an interrupt function called from tse_sgdmaRx_isr inside ins_tse_mac.c. Inside thsi function, it checks if there is room inside rcvdq and looks at the SGDMA status. If allowed, it will then go into the tse_mac_rcv(). Inside this function, the bits are adjusted to form a correct frame length and then puts the packet into the queue.

After we understood how the packet arrives, we wanted to write a simple packet sniffer such that every packet coming in is printed out. Instead, we just ran ipdump() at the ip_recv function. Next we wanted to use this information and try to rewrite headers and send out the modified packet using raw_send() from the PACKET struct. At the same time, we haven't been able to thoroughly test this since a packet not destined for the device does not get to the ip_recv function because of a problem.
It was here we saw problems sprout. The first problem we saw was that raw_send() didn't seem to send out the type of packet we wanted to. The next problem was that we finally realized that with our previous configuration, all packets were sent out only through one interface.
The final, more immediately important, problem was that we found that any packet with the destination that wasn't the interface it was sent to would have a different offset in the IP header. An example would be if we send a ping from 192.168.0.104 to 192.168.0.102 (eth1 on the DE4 board), the board would read this correctly .If we send a ping from 192.168.0.104 to 192.168.0.137, the board would not read this correctly and the packet header would show that the source was 118.226.192.168 and the destination was 0.4.0.0. This is the important issue right now because any packet coming in that isn't destined for the devices on the board will not be read in correctly and will not be analyzed by the ip_rcv function.