Introduction
For my project, I wished to design something that would really test the full capabilities of the Motorola Coldfire system, and at the same time, still produce a product that would be utilized by a large audience, especially in the commercial sector. Knowing that the main focus of businesses everywhere is their migration to the digital age and more specifically the Internet, I decided I would build some sort of network device. After studying what I had to work with and weighing different options, I decided that I would design a network bridge, which would allow two Local Area Networks (LANs) to communicate with each other without degradation to either isolated network.
Background
First, I will give a little networking background on why the network bridge is such a vital piece of today’s corporate networks. Today’s networks are generally configured in what is called a Star network. This means that all the computers, called nodes, meet at one single point. This single point is usually a hub, a device that takes input from one node and sends the message to every other node. Hubs can be linked together to form bigger networks, and thus a LAN is born.
The problem is that there are limitations placed on LANs, depending on the level of ethernet technology you are using. These limitations include but are not limited to: number of users and distance between users. As more nodes are added to a LAN, the number of collisions that occur also increase. Different ethernet technologies can not be mixed on the same LAN either. This is all because the hub device works at the "physical layer" of the OSI network model. This means that it does not analyze any of the data that it receives, it merely takes input, amplifies the electrical signal, and sends it back out. A bridge overcomes all these problems.
The main advantage of a bridge is that it works at the "data link layer" of the OSI network model. This makes the bridge an intelligent device. It can examine the packets that come into it’s interfaces from the nodes, and forward those packets to the correct outgoing interfaces. This allows the bridge to isolate each LAN into it’s own collision domain. This means that each LAN may have its maximum number of users and its maximum distance. It also reduces collisions over the network by not sending data not destined for the opposite LAN. A bridge can also link different ethernet technologies together.
The way a typical corporate network is set up is by arranging each LAN in a star configuration around a hub to its maximum ability, then joining the LANs together with a bridge. This is referred to as a backbone bridge.
Theory of operation
To implement my network bridge, my first requirement was that I use two Motorola Coldfire boards. Each board had a RJ-45 socket with a programmable ethernet controller. By connecting the two boards through their DB-9 ports, I was able to make a physical circuit through which data could flow as packets were received from each LAN.
This is all the hardware setup that was required. The bridge is entirely software driven, using the same assembly program on each board. The following is a brief description of the firmware for the bridge. The complete source code, as well as an easier to follow flow chart are included in the appendix. Click here for a demo.
Actual Implementation
I ran into a major problem when designing the device. Unfortunately, the ethernet controller is impossible to program from the debug module. It’s only function in this mode is to receive S-records uploaded to the board. The only way to actually use the ethernet port is to use the linux kernel, which I could not accomplish. However, I have designed away to successfully simulate the sending and receiving of packets, proving that the bridge would work.
To simulate the features of the bridge, I used a combination of the parallel port and the terminal interface. More specifically, I used the following pin assignments:
P4: Interrupt signal that a packet has been received from the LAN
P5: Interrupt signal to end the bridge program
P6: Interrupt signal to display the current bridge table
These signals are all set to high during the initialization and their events are triggered when they are set to low. When these signals are all high, the program is trapped in a loop, waiting for either data to be received over the UART, or one of the signals to go low.
The key action is when P4 is tied to a ground. The terminal requests a source address, which has to be exactly twelve characters, simulating a 6-byte LAN address. A subroutine is then run to determine if the address needs to be added or not to the bridge (routing) table. The terminal then requests a destination address, also 12 characters long to simulate the 6-byte LAN address. Another subroutine is then called to search through the table. If a match is found, the program goes back into the wait loop, since the data does not need to be passed to the opposite LAN. If not, then the terminal requests data to be sent.
Once the user hits the enter key, an ethernet frame is created at address 0x39000. A 10-byte header is entered first, 7 bytes of AA, 1 byte of AB, and then two bytes for the length of the data. The data is then stored directly after it. The whole frame is then transferred a byte at a time across the UART to the second board, which would be connected to the other LAN. On it’s terminal screen is displayed the source and destination address of the frame that was just sent, as well as the data. Both boards go back to their wait states for another interrupt signal or another packet to come across the UART.
Conclusions
Overall, I believe this was a good design project. However, the device does have some set backs that would need to be addressed during the manufacturing process.
First and foremost, it would need to be able to use the onboard ethernet controller. All of today’s corporate networks are based on the ethernet standard, with out this, the product is not a viable option for most businesses.
Also, expandability would be an issue. Because the bridge makes use of the Serial (DB-9) port, only two boards can be connected together. This means that only two LANs can be connected together with this type of bridge.
Lastly, there is a bandwidth issue. Today’s corporate networks are quickly migrating towards ethernet technology supporting over 100 Mbits/second. However, the speed of the Serial port is only 19,200 bits/second. This will eventually lead to a bottleneck at the bridge.
There are also ethic and social consequences of developing this bridge, mostly centering on security. As of now, there is no way to block on user from viewing information on one side of the LAN. Although this could be implemented at application layer, some sort of firewall capability would be an excellent feature. Also, there is no encoding as data passes over the bridge. This could mean that if someone connect to the board through the terminal, they could view the data packets stored in memory. The bridge could also be a target for Denial of Service attacks from hackers who could flood the bridge with phony packets, or use fake source addresses that would prevent data flow to the other LAN.
However, most, if not all these issues can be worked out at the software level. Although, it can be broken down even more, the code is quite modular and easy to follow. Most of the advanced functions are broken into subroutines, and more commands can be added easily by expanding the use of the parallel port.
Like I said, I believe this was a very good project. I was able to use a variety of the modules of the Coldfire board while at the same time delivering a device with a practical application that focuses on a business need in a highly dynamic and fast growing area of computer engineering.