Packet forwarding with a working routing table on one network

So far, we have gotten a working router with one network per interface. This week, we have gotten all interfaces to work under one network. With a little guidance and a lot of research, we found a semi-efficient way to get all the interfaces on one network to communicate with each other.

So the first thing we changed from last week was the promiscuous mode. Last week, we tried to enable "'ENABLE_PHY_LOOPBACK" but that actually ended up causing us too many problems. From what we could figure out, when this option was enabled, the PHYs would setup differently (The usual start up code did not appear). None of our previous code would work with this setting (notably they would never reach the ARP forwarding we had programmed in). So with the advisement of Professor Pak Chan, we just enabled ALTERA_TSEMAC_CMD_PROMIS_EN_MSK. This would let the PHYs start up the right way and all our code was still intact. From here, we first had to make sure our promiscuous mode worked. We ran the same ARP tests as least week and we could see the ARP replies now.

Next, we started ironing out the details for ARP forwarding. The first thing we did was broadcast any ARP packet coming in that wasn't destined for the interface that the packet was received on. Since our ARP forwarding was already working, we just sent the packet to multiple interfaces except the interface that it was received on. Next we tried to get the ARP reply to forward correctly. The problem was that we didn't have a working ARP table yet so we could not reroute a packet easily. Because of this problem, we worked on getting the ARP table to setup correctly first. We would add an entry for each ARP request and reply (using make_arp_entry()) while also adding the MAC address into the table before each packet is sent back out. Once we could confirm this was working correctly, we finished forwarding the ARP reply part. To do this, we would call find_oldest_arp() (returns either an empty entry or finds the entry you are looking for) to find the ARP table entry that the packet is destined for and send the packet out that way.

Once ARP forwarding was all done, we moved onto working on the routing table. The problem here was that although the ARP packets were moving correctly through the router, any other packets would automatically be routed to interface 1 (eth0). After thinking about it for a while, we realized that because all our interfaces were on one network, we could use the ARP table to help route our packets. As we traced the way the packet would get the net interface, we found that it would often end up at the function send_via_arp() in et_arp.c. We saw that the only reason the packet wasn't actually being sent out the right interface was because the packet struct's NET value is never set to the right interface. So before the et_arp() (will send packet based on ARP information) function is called in send_via_arp(), we would change the interface to whatever interface was returned from an earlier call of find_oldest_arp(). After this slight change, all the packets forwarded to the right place but when investigating the routing table, all of our entries all pointed to the same network interface which is wrong. To fix this, we looked at where add_route is called. This function is mostly called from ip_route() so we looked into how ip_route() would add a route. It turns out it would look at the interface IP address and as long as it matched our destination IP address' subnet, it would add that to the routing table. To fix this, we have ip_route() calling find_oldest_arp() instead and using the ARP entry to add the right interface to the routing table.

After this, we are able to communicate through the network. We have tested using simple pings along with SSH to test TCP packets also. Next, we are going to split up for a bit to look into two parts. I am going to look into how I'm going to route into another network while David is going to look at optimizing packet buffers. After adding another network and routing correctly to it, I will probably have to look into implementing some sort of address translation.