We first found out why there was a strange header offset before. The problem we were having was that we put both interfaces on the same network. At first, we tried to go through the ARP functions (et_arp.c) and just forward requests through but upon more research, we found that this was very unsafe. What we didn't know was that when clients try to ping each other on the same network, they send an ARP request packet. The ARP packets have different headers than IP packets which is why we were seeing the offset.So we immediately discarded all of our changes to the et_arp.c file we edited earlier.
The next thing we did to get the packets to start forwarding was to make the interfaces static (whereas before, they were DHCP clients). We set each of our two interfaces on their own network by giving them the IP addresses of 192.168.0.51 and 192.168.1.51. To do this, we had to comment out #define DHCP_CLIENT in our bsp/system.h file but then add #define DHCP_CLIENT 0 to bsp/iniche/src/h/niosii/ipport.h. We then gave each interface it's own IP address.
Now that our two interfaces were up on different networks, we ran into a problem. Our previous algorithm for doing simple packet forwarding seemed to block ARP replies. This was strange because the ARP check would check the packet before sending it to our packet forwarding algorithm anyways. So to bypass this, we removed our simple algorithm, enabled IP_ROUTING, and let the iniche stack do it's own forwarding. So instead of using our own algorithm, we took advantage of the function ipdemux.c:ip_rcv_phase2 to do the general packet forwarding.
No comments:
Post a Comment