Now that I got all three ethernet port working, now I will make the board into a switch. I will have to modify arprcv so that when it gets a arp request it will send it out all the other port. I will have to modify the packet for each port that it will send out to. I also have to enable promiscuous mode, which allow arprcv to tell if packet is a request or a reply. I have to change IP route so the computer shows the it is receving a ping from the correct ip address. I am now able to ping correctly from the ports.
Saturday, May 26, 2012
Monday, May 21, 2012
[Hardware Router] Development (5/20-5/21)
Attempting to set up routing services for the NetFPGA platform on the Altera DE4 board...
After finishing compilation with just the bare essentials of the platform, the FPGA Ethernet ports were set up using user scripts (written in TCL). The power LEDs of all relevant ports were activated when cables are connected to those ports. Furthermore, when an active Ethernet connection exists on the other side of the port, the Rx light blinks in time with packet transmission. However, the Tx light does not work, indicating that the board is still not sending any packets, neither in reply (such as ICMP Ping packets), nor in forwarding (as router should). Therefore, I have begun by attempting Layer 2 connectivity testing. A linux utility called Linkloop was installed on the linux laptop that David was using.
Attempts to install Linkloop on the secondary Linux PC proved... difficult... due to the fact that the Linux PC does not have a C compiler! As a result, the decision was made to utilize Cygwin on my personal laptop as the second end-point of the Linkloop testing structure. Linkloop was installed on both devices, and layer 2 connectivity test progressed.
Layer 2 connectivity unsuccessful. The problem appears to be in the PHY layer, and unrelated to MAC. However, further testing is required.
The Altera DE4 board uses a Marvell Fast Ethernet Transceiver for the PHY. The PHY is configured during initial runtime setup by means of a user script. The script sets each of the required PHY register values, including speed (they are capable of 10mbps, 100mbps, and 1gbps), auto-negotiation, and Duplex value (half or full duplex). The remainder of the procedure is still mysterious to me, but is laid out nicely in the configuration script. Further detailed analysis is required in order to fully understand the process by which the PHY control registers are configured, and to understand why connectivity is not properly established, in terms of outward data transmission.
After finishing compilation with just the bare essentials of the platform, the FPGA Ethernet ports were set up using user scripts (written in TCL). The power LEDs of all relevant ports were activated when cables are connected to those ports. Furthermore, when an active Ethernet connection exists on the other side of the port, the Rx light blinks in time with packet transmission. However, the Tx light does not work, indicating that the board is still not sending any packets, neither in reply (such as ICMP Ping packets), nor in forwarding (as router should). Therefore, I have begun by attempting Layer 2 connectivity testing. A linux utility called Linkloop was installed on the linux laptop that David was using.
Attempts to install Linkloop on the secondary Linux PC proved... difficult... due to the fact that the Linux PC does not have a C compiler! As a result, the decision was made to utilize Cygwin on my personal laptop as the second end-point of the Linkloop testing structure. Linkloop was installed on both devices, and layer 2 connectivity test progressed.
Layer 2 connectivity unsuccessful. The problem appears to be in the PHY layer, and unrelated to MAC. However, further testing is required.
The Altera DE4 board uses a Marvell Fast Ethernet Transceiver for the PHY. The PHY is configured during initial runtime setup by means of a user script. The script sets each of the required PHY register values, including speed (they are capable of 10mbps, 100mbps, and 1gbps), auto-negotiation, and Duplex value (half or full duplex). The remainder of the procedure is still mysterious to me, but is laid out nicely in the configuration script. Further detailed analysis is required in order to fully understand the process by which the PHY control registers are configured, and to understand why connectivity is not properly established, in terms of outward data transmission.
Sunday, May 20, 2012
Change for the better
This weekend, we have successfully gotten our router to a point where an excess of packets will not crash our router. The first thing I tried was first make the router a packet generator/ receiver to see if the problem was with the PHY. I wrote a simple C socket program to make a send client/ recieve server. I tested this with the router and as long as the router was receiving/ sending, nothign would crash. Next, under the advisement of Professor Pak Chan, I added a descriptor memory for each TSE. He figured that what was probably happening was that since they were all sharing one descriptor memory to begin with, some information was being overwritten when a lot of packets come in at one time. After adding these descriptor memories, our router would no longer crash. Now, through a brief benchmark test, we have seen an average speed of about 22MBit/s.
Professor Pak Chan also recommended we enable burst mode on the SGDMA but after an initial trial, it seemed to disable interrupts completely. After talking to David, it seems like by eneabling burst, I may have disabled a global interrupt value that I need to re-enable. We will test this tomorrow.
Professor Pak Chan also recommended we enable burst mode on the SGDMA but after an initial trial, it seemed to disable interrupts completely. After talking to David, it seems like by eneabling burst, I may have disabled a global interrupt value that I need to re-enable. We will test this tomorrow.
Wednesday, May 16, 2012
NIOSII board - Success / Week 13
Here is how I set the two ports.
Ethernet 0 (on board)
Your Ethernet MAC address is 00:07:ed:ff:75:4a
Static IP Address is 192.168.1.100
Ethernet 1 (daughter card)
Your Ethernet MAC address is 00:07:ed:24:8e:da
Static IP Address is 192.168.0.101
I tested both ethernet ports and I was able to get pings from both ethernet ports successfully.
Now I will add another daughter card to the board, so I will have three ethernet ports.
I added the daughter card to the SOPC builder so that both daughter cards share the same address and data pins. Then I have to set the pins for the upper daughter card and logic for irq also. In the code I change it so it will support 3 ethernet ports.
Ethernet 0 (on board)
Your Ethernet MAC address is 00:07:ed:ff:75:4a
Static IP Address is 192.168.1.100
Ethernet 1 (daughter card)
Your Ethernet MAC address is 00:07:ed:24:8e:da
Static IP Address is 192.168.0.101
I tested both ethernet ports and I was able to get pings from both ethernet ports successfully.
Now I will add another daughter card to the board, so I will have three ethernet ports.
I added the daughter card to the SOPC builder so that both daughter cards share the same address and data pins. Then I have to set the pins for the upper daughter card and logic for irq also. In the code I change it so it will support 3 ethernet ports.
[Hardware Router] Development (5/15 - 5/16)
Today I received an email from Professor Tessier at the University of Massachusetts Amherst, who worked on a version of the NetFPGA platform compatible with Altera boards.
Examining the files sent by Professor Tessier, development was begun based on the NetFPGA platform. The NetFPGA was originally designed for use on Xilinx boards, but a modification of the system files should allow it to work on the Altera DE4 board.
Analyzing the system's implementation, it seems that the Ethernet controller is implemented largely in hardware. The port interfaces are instantiated in verilog by means of sequential always blocks causing the ports to advertise a "ready" signal unless synchronous reset signal is sent. Continuous assignments then set the ready signals. The rest of the assignments are also handled with continuous 'assign' statements. The NetFPGA core module is instantiated to provide error detection through the CRC checker. The core module also pipes data into the interfaces.
The NetFPGA Core module acts as the main top level design (with some exceptions). The SRAM and other storage structures (FIFOs) are instantiated here, and the logic in the core provides for the sending and acknowledgment portion of network connectivity. Frame errors are generated here, as well as other Ethernet sink errors, such as those dealing with malformed datagrams. Additionally, data path transmission is taken care of in this module, including timing and control signal handling.
Other portions of the design, such as various FIFOs used to hold Ethernet frame data, including payloads and header/tail fields, are self-explanatory.
Finally, the system relies on configuration scripts sent through the JTAG interface in order to configure the device. That is, instead of having the MAC addresses, IP addresses, routing tables, and ARP data hard-coded into the verilog (which would result in very tedious recompilation complications), user scripts are used to dynamically allocate all of the data during initial setup on runtime. After initial setup, the router is self-sufficient, but the JTAG connection may be maintained to maintain output of data relevant to debugging.
Next step is designing routing services for the device...
Examining the files sent by Professor Tessier, development was begun based on the NetFPGA platform. The NetFPGA was originally designed for use on Xilinx boards, but a modification of the system files should allow it to work on the Altera DE4 board.
Analyzing the system's implementation, it seems that the Ethernet controller is implemented largely in hardware. The port interfaces are instantiated in verilog by means of sequential always blocks causing the ports to advertise a "ready" signal unless synchronous reset signal is sent. Continuous assignments then set the ready signals. The rest of the assignments are also handled with continuous 'assign' statements. The NetFPGA core module is instantiated to provide error detection through the CRC checker. The core module also pipes data into the interfaces.
The NetFPGA Core module acts as the main top level design (with some exceptions). The SRAM and other storage structures (FIFOs) are instantiated here, and the logic in the core provides for the sending and acknowledgment portion of network connectivity. Frame errors are generated here, as well as other Ethernet sink errors, such as those dealing with malformed datagrams. Additionally, data path transmission is taken care of in this module, including timing and control signal handling.
Other portions of the design, such as various FIFOs used to hold Ethernet frame data, including payloads and header/tail fields, are self-explanatory.
Finally, the system relies on configuration scripts sent through the JTAG interface in order to configure the device. That is, instead of having the MAC addresses, IP addresses, routing tables, and ARP data hard-coded into the verilog (which would result in very tedious recompilation complications), user scripts are used to dynamically allocate all of the data during initial setup on runtime. After initial setup, the router is self-sufficient, but the JTAG connection may be maintained to maintain output of data relevant to debugging.
Next step is designing routing services for the device...
Tuesday, May 15, 2012
NAT delay
NAT was not as easy to implement as I thought it was and I did not finish this weekend. The main part I had problems with was setting up the NAT table itself. While editing the headers is not too hard, I overlooked what it took to implement the NAT table itself. What I realized is needed is a separate add, delete, and search function for the NAT table. One of these functions should also be capable of recycling entries which are not used (because the table itself is static). For now, here is what I propose for each function:
int add(IP, port): Adds entry to NAT table.
Returns the new port that is assigned to this IP and port combo.
void delete ( IP, port): Will delete an entry from the NAT table.
***Not sure if this is needed if there is a recycle function built into add***
NATOBJECT lookup(IP, port): Will search through the table for the IP and port combo and return the entry.
I am going to try to model this after the existing routing and ARP tables except my implementation will be a lot more basic.
Monday, May 14, 2012
Troubleshooting the router crashing and more...
Over the past few weeks, I have been trying to find a way to optimize the speed of our router as well as finding a way such that the router does not crash when being sent a large number of packets at one time. Once, we were able to get speeds of up to 20 Mbits/sec, but it crashed instantly after and it became frustrating from there. A lot of it probably had to do with optimizing our code a bit as well as disabling the debug mode, but I figured the packet buffer might've been the cause of the crashing problem. So I investigated how the buffer actually worked and ran some tests on the two buffers that were being used: one for small packets, specifically ping and ARP packets for example, and one for large packets, such as those from large file transfers in FTP or benchmark testing. Along the way, I was able to make the buffers a lot bigger by modifying some values in ipport.h and enabled TCP window scaling to attempt to fix the router from crashing. I had thought that by enabling TCP window scaling, packets would be able to go over the maximum window size (65,535) so the packets can handle large amounts of data at one time. However, I found out that the buffers do not actually fill up through testing and observation of the number of packets in each buffer compared to their maximum length defined within the Nichestack, so the case of buffer overflowing has been ruled out. Matt has suggested creating a new project and make a controlled experiment to see if the router crashes with mostly original code (no changes to routing but two interfaces were enabled). It turned out that the router still crashes with the original code. When it crashes, all the interfaces goes down, but one connection stays alive. Matt and I suspected that another case is that somewhere in our code, the router is actually turning off the interfaces, so I am investigating that at the moment by going through the parts of the routing where the program may actually be forcing the interface off. More to come...
Sunday, May 13, 2012
NIOSII - Week 12
Now that I got the daughter card working, I am working on getting two ethernet port working together on the stratix board. This week I am was looking throught the code to figure out how to figure out which port is using each function, so I can give it the correct values. I was able to get some parts working, so far only the on board ethernet port is setup correctly. The daughter card doesn't get the correct values in the register. Have to edit every function to support both ethernet devices. I got everything set up and almost working. The only thing not working is the daughter card, it not doing the interrupt correctly. When interrupt is callled both ethernet ports get the on board chip interrupt value. I was able to get interrupt working for both ethernet ports, and I think they should be able to work. All I need to do now is test them.
Wednesday, May 9, 2012
Minor progress and address translation research
The past week has been spent mostly ironing whatever bugs we could find with two networks while also testing speed and optimization. Some bugs we had had to do with initial packets being lost along with packets not being formatted correctly.
After fixing this, I have moved on to starting to understand what I need to accomplish and do for address translation. What I will be trying to implement is similar to a full-cone NAT (or as Alex likes to call it, PAT). In full-cone NAT, each device on the interior network is given one port. This association is stored in a table. All packets being sent out to an exterior network will have it's headers edited. The source IP and port will be changed to match the aforementioned table when a packet is outgoing. When a packet is incoming, the router will change the destination IP and port along with then sending the packet to the right interface. If an incoming packet is not destined for a specific port defined in the table, then the packet will be dropped.
At the moment, I have not finished writing this so I have no testing done. I also fear that after implementing this, David's modifications to the packet buffer (along with his slight speed modifications) will break. I will need to dedicate some time to work with David to implement this and then merge back together and help him improve speeds.
After fixing this, I have moved on to starting to understand what I need to accomplish and do for address translation. What I will be trying to implement is similar to a full-cone NAT (or as Alex likes to call it, PAT). In full-cone NAT, each device on the interior network is given one port. This association is stored in a table. All packets being sent out to an exterior network will have it's headers edited. The source IP and port will be changed to match the aforementioned table when a packet is outgoing. When a packet is incoming, the router will change the destination IP and port along with then sending the packet to the right interface. If an incoming packet is not destined for a specific port defined in the table, then the packet will be dropped.
At the moment, I have not finished writing this so I have no testing done. I also fear that after implementing this, David's modifications to the packet buffer (along with his slight speed modifications) will break. I will need to dedicate some time to work with David to implement this and then merge back together and help him improve speeds.
Monday, May 7, 2012
[Hardware Router] Weekly Progress 4/30 - 5/06
Monday - Designed a simple Cyclic Redundancy Check module in verilog in order to modify the frame check sequence of Ethernet frames, as a first step in developing Ethernet for the DE4 board (in hardware). The frame check sequence is a portion of the Ethernet Frame Header that requires a CRC (Cyclic Redundancy Check) in order to determine whether or not the frame was transmitted properly. The CRC Module uses bitwise XOR with specific bits of data, and an enable bit, in order to generate the checksum. A so-called "magic number" of
32'hC704DD7B is used to determine whether or not an error has taken place. The "magic number" is calculated from a polynomial value. If there was an error, then the frame has tainted data, and must be discarded or corrected.
Tuesday - Designed simple FIFO to be used as a packet buffer and a Tristate Controller for use with the data pathways. The FIFO will hold the data from the Ethernet frames, as they come in, and release them after the headers are modified and the destination selected. The tristate controller will be used to output a hi-Z value onto the data line from one end so that the bus can be used by other locations. Went home early today due to sore throat.
Wednesday through Saturday - Home sick with influenza.
Sunday - Began work on initialization module. This module is used to initialize the PHY of the DE4 board. Each PHY should be reset for a period of time (several milliseconds?) in order for it to work properly when turned on. Use a simple counter and case statement to determine when to halt the reset.
32'hC704DD7B is used to determine whether or not an error has taken place. The "magic number" is calculated from a polynomial value. If there was an error, then the frame has tainted data, and must be discarded or corrected.
Tuesday - Designed simple FIFO to be used as a packet buffer and a Tristate Controller for use with the data pathways. The FIFO will hold the data from the Ethernet frames, as they come in, and release them after the headers are modified and the destination selected. The tristate controller will be used to output a hi-Z value onto the data line from one end so that the bus can be used by other locations. Went home early today due to sore throat.
Wednesday through Saturday - Home sick with influenza.
Sunday - Began work on initialization module. This module is used to initialize the PHY of the DE4 board. Each PHY should be reset for a period of time (several milliseconds?) in order for it to work properly when turned on. Use a simple counter and case statement to determine when to halt the reset.
Friday, May 4, 2012
NIOSII - Week 11
I was able to get the input from the daughter card working. I used ip_dump(pkt); to print out the info gotten from the packet, here is what it outputs when connected to the router. s91_rcvdata is the function for receving the data. I fixed it by combining two RD into one and put into the data.
IP packet header:
ver/hlen: 45, TOS: 00, len: 0155, id: 0009
flags/offs: 0000, TTL 96, protocol: 11, cksum: 71eb (ok)
src: 192.168.1.1 dest: 239.255.255.250
ip address 101a8c0
It printed the ARP info to check that it is getting the ARP correctly and it is working correctly.
Arp received
hardware address length: 6
protocol header length: 4
Source IP: 192.168.1.14 Dest IP: 192.168.1.234
Source MAC: 20:cf:30:2d:76:e2 Dest MAC: 00:07:ed:ff:75:4a
Now I have to change s91_senddata to get the data sending correctly. I got it working by splitting the 32bit data into two 16bit data and then send them one at a time. I got it working and is able to ping into it.
IP packet header:
ver/hlen: 45, TOS: 00, len: 0155, id: 0009
flags/offs: 0000, TTL 96, protocol: 11, cksum: 71eb (ok)
src: 192.168.1.1 dest: 239.255.255.250
ip address 101a8c0
It printed the ARP info to check that it is getting the ARP correctly and it is working correctly.
Arp received
hardware address length: 6
protocol header length: 4
Source IP: 192.168.1.14 Dest IP: 192.168.1.234
Source MAC: 20:cf:30:2d:76:e2 Dest MAC: 00:07:ed:ff:75:4a
Now I have to change s91_senddata to get the data sending correctly. I got it working by splitting the 32bit data into two 16bit data and then send them one at a time. I got it working and is able to ping into it.
Subscribe to:
Posts (Atom)