Ethernet Fundamentals

EthernetEthernet was developed at Xerox PARC between 1973 and 1974, and was developed as a network technology based on a bus topology. It was originally based on the idea of computers communicating over a shared coaxial cable, and the original specification enabled them to transfer data at a rate of up to 3 Mbps. It remained a largely in-house technology within Xerox until 1979, when Xerox decided to look for partners to help promote Ethernet as an industry standard. They worked with Digital Equipment Corporation (DEC) and Intel to publish what became known as the Digital-Intel-Xerox (DIX) standard. These companies then transferred control of the Ethernet standard to the IEEE, which in turn created the now famous 802.3 committee that continues to control the Ethernet standard. The 802.3 standard initially specified communications over coaxial cable at speeds up to 10 Mbps. Since then, Ethernet has evolved from a single network technology into a standard for a family of network technologies that share the same basic bus topology, frame type, and network access methods.


Ethernet Fundamentals: CSMA/CD and MAC Addresses

Developing a networking standard at the physical level and beyond requires designing a way to send data, a way to determine which computer should use the shared cable at what time, and identify the sending and receiving computers. Ethernet deals with the first two issues by using a process called Carrier Sense Multiple Access with Collision Detection (CSMA/CD), and deals with the third issue by using data frames that contain Media Access Control (MAC) addresses to identify computers on the network. Carrier sense means that each node using the network examines the cable before sending a data frame. If another machine is using the network, then the node will detect traffic on the segment, wait a few milliseconds, and then recheck. If it detects no traffic, the node will send out a frame of data.

Multiple access means that all machines have equal access to the cable. If the line is free, any Ethernet node may begin sending a frame. It does not matter what function the node is performing. Ethernet assigns access on a first-come, first-serve basis, leaving it to other networking technologies (such as pfSense) to discriminate based on what type of traffic it is.

If two computers try to use the cable simultaneously, then a collision occurs, and both of the transmissions are lost. At the same time the network interface is sending a frame, it compares the data being sent with the data received over the cable. If there is a difference, both nodes will detect a collision and immediately stop transmitting. Then each node generates a random number to determine how long it waits to begin trying again. Whichever node generates the lowest number begins retransmission first. The losing node sees traffic on the wire and waits for the wire to be free again before attempting to retransmit.

As you can imagine, any Ethernet node will waste some time dealing with collisions instead of sending data. Moreover, as more nodes are added to the network, the collisions increase. We call a collision domain a group of nodes that hear each other’s traffic. Ethernet standards dictate that within a collision domain, there should be at most 5 segments tied together with 4 repeaters, and no more than 3 populated segments.

Ethernet requires a means of identifying sending and receiving nodes, and its method is to use special 48-bit binary addresses known as MAC addresses. MAC addresses give each network interface card (NIC) a unique address. When a computer sends out a data frame, all other NICs on the collision domain listen to the wire and examine the frame to see if it contains their MAC address. If not, they ignore the frame. If a NIC sees a frame with its MAC address, it accepts the frame and begins processing the data.

One issue with this method is that any device connected to the network cable can potentially capture any data frame transmitted across the wire. Network diagnostic programs can order a NIC to run in promiscuous mode, in which case the NIC will process all frames it sees on the cable regardless of their MAC addresses. Such programs are useful diagnostic tools but also pose a security risk, as anyone with access to the network can potentially intercept every frame on the collision domain.


External Links:

Ethernet at Wikipedia

5-4-3 Rule at Wikipedia

Packet Capture in pfSense

Packet Capture Explained

Packet Capture

Enabling packet capture from the pfSense web interface.

Packet capture is useful if you need to intercept and log traffic passing over a network. As data streams flow across the network, the sniffer captures each packet and if needed, decodes the packet’s raw data showing the values of various fields in the packet, and analyzes its content.

Ethernet sniffers can take advantage of the way Ethernet frames are transmitted. When a node sends out an Ethernet data frame, it transmits it to every other node across the write in both directions. All the other computers on the network listen to the wire and examine the frame to see if it contains their MAC address. If not, they ignore the frame. If a node sees a frame with its MAC address, it opens the frame and begins processing the data. This is a simple means of sending frames (much simpler, for example, than the way a token ring network operates), but it also means Ethernet sniffers can order an NIC to run in promiscuous mode and process all the frames it sees on the cable, regardless of their MAC address. The ability to capture all packets on the local network segment would change with the advent of switched ports, but a router can still function as a packet analyzer.


Packet Capture from the pfSense Web Interface

The easiest way to capture packets in pfSense is to use the built-in packet capture feature. First, navigate to Diagnostics -> Packet Capture. At “Interface“, select either the LAN or WAN interface. If you are trying to track down IP addresses in your local network, you should specify LAN; if you are trying to track down traffic originating outside you network, select WAN. At “Address Family“, you can leave it set to “Any”, but you can also filter the traffic to capture only IPv4 or IPv6 addresses. You can leave “Host Address” blank, but if you are looking for traffic from a specific address or subnet (in CIDR notation), you can specify it here. You can also specify a “Port” if you want to filter by port, or leave it blank. At “Packet Length“, you can set a maximum number of bytes of each packet that will be captured, or leave it at zero, which will cause it to capture the entire frame. At “Count“, you can set a maximum number of packets the packet capture will grab. The default value is 100, and you can enter zero for no count limit. At “Level of Detail“, you can set how much detail is displayed in the capture window after you press the “Stop” button at the bottom of the screen. If you download the capture file, however, this setting will not affect the contents of it. You can check the “Reverse DNS Loookup” check box to cause the packet capture to perform a reverse DNS lookup associated with an IP address. It can cause delay, however, for large packet captures.

Packet Capture

Wireshark in action under Windows.

Once you have run a capture using the pfSense web interface you can use Wireshark, a free and open-source packet analyzer, for packet analysis by downloading the pcap file and loading it into the program (You can do this by navigating to File -> Open in Wireshark and loading the appropriate file). A complete overview of Wireshark and its functionality is beyond the scope of this article, but you can find the packets you are looking for by applying different filters to locate the packets for which you are looking. For example, we can limit the results to a specific IP address by navigating to Analyze -> Display Filters and clicking on the “IP address” display filter, then specifying the desired IP address.


Using tcpdump

Another possibility for packet capture analysis is to run the “tcpdump” command at the pfSense command land. Again, a complete overview of the tcpdump command is beyond the scope of this article, but suffice it to say -i denotes the interface whose packets should be captured and -w indicates that the output should be written to a file. For example:

tcpdump -i fxp1 -w output.pcap

indicates that tcpdump should capture all packets on interface fxp1 (our LAN interface) and save them to output.pcap. Omitting “-w output.pcap” would result in the output going to the screen. Specifying “host 192.168.1.1” would limit results to traffic to and from 192.168.1.1. To analyze the logs produced by tcpdump, you could use Wireshark or a program such as tcptrace.

External Links:

Packet Analyzer at Wikipedia

How to Capture Packets Using pfSense at HubPages

© 2013 David Zientara. All rights reserved. Privacy Policy