0

I would like to send some raw bits over ethernet cable between two computers. The errors in data that occurred during transmission are corrected by Ethernet Frame Check Sequence(FCS) (like CRC: cycle redundancy check) and further checks by the upper layers like TCP.

But, I do not want any error correction techniques to be applied. I want to see the exact bits received with the errors occurring in transmission. I have seen some articles(example http://hacked10bits.blogspot.in/2011/12/sending-raw-ethernet-frames-in-6-easy.html) on sending raw ethernet frames but I think they also undergo FCS like CRC checks. Is it possible to send data without any such error corrections. Thanks.

Edit 1

I am connecting two computers directly end to end using an Ethernet cable (no switches or router in between). The ethernet cable is "CAT 5E", labelled as "B Network Patch Cable CAT 5E 24AWG 4PR-ETL TIA/EIA-568B"

The output of lspci -v is (nearly same for both the computers):

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
    Subsystem: Lenovo RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    Flags: bus master, fast devsel, latency 0, IRQ 28
    I/O ports at e000 [size=256]
    Memory at f7c04000 (64-bit, non-prefetchable) [size=4K]
    Memory at f7c00000 (64-bit, prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [70] Express Endpoint, MSI 01
    Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
    Capabilities: [d0] Vital Product Data
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Virtual Channel
    Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
    Capabilities: [170] Latency Tolerance Reporting
    Kernel driver in use: r8169
    Kernel modules: r8169

I used the following command to show FCS and not drop bad frames

sudo ethtool -K eth0 rx-fcs on rx-all on

Still I am not receiving any error/bad frames. I am sending 1000 bits of zeros in each frame and none of the bits received had any 1's. Do I need to keep sending a lot of such frames in order to receive a bad frame? (Because the bit error rate is probably a lot less for a CAT 5E cable) Also, can I implement my own LAN protocol with the same current NIC and ethernet cable?

Basically, I want to get as many errors as possible during the transmission and detect all of them.

user1877095
  • 75
  • 1
  • 2
  • 9
  • Considering that the FCS is part of the ethernet standard, you will need to write your own LAN protocol to do this. – Ron Maupin Oct 30 '17 at 14:47
  • @RonMaupin Thanks. I have been searching and I found this: https://stackoverflow.com/a/24175679/1877095 which configures ethtool to not drop and show bad packets. Will using this be enough? Or are there already some other checks performed before this layer too? Thanks. – user1877095 Oct 30 '17 at 17:24
  • The ethernet frames will still have the FCS. That is the only way to tell that the frames are bad. The packets may have a CRC (IPv4 has the IHL, but IPv6 does not), and TCP has a CRC for its segments. UDP has an _optional_ CRC for IPv4, but it is required for IPv6. What you see first is the frame. – Ron Maupin Oct 30 '17 at 17:30
  • I think I am not so clear. Using the above method(using ethtool to show bad frames), I can capture all the bad frames when I use wireshark or tcpdump. Right? Or will some of the bad frames be already been dropped, even before I could see them? Thanks. – user1877095 Oct 30 '17 at 17:55
  • Typically, the hardware will drop the bad frames. It really is going to depend on exactly what you have. Ethernet has gone to having most things in hardware now. For example, most switching is completely done in hardware, and bad frames are dropped by layer-1. – Ron Maupin Oct 30 '17 at 17:58

3 Answers3

2

This is not possible. FCS is mandatory for Ethernet frames (layer 2); it checks for errors but locating/correcting error bits isn't possible. FEC is used with faster PHYs (layer 1) and isn't optional either.

When switching off FCS checking on a NIC you have to keep in mind that any switch you use also checks for FCS errors and drops ingress frames with bad FCS. Ethernet is explicitly designed not to propagate error frames.

Edit 1 question comments:

  • With decent cabling, error frames on GbE should be very rare. If you actually want errors(?), use a good length of Cat3 cable or severly abuse the Cat5 cable...

  • An Ethernet NIC speaks Ethernet. If you want your own protocol you'd need to build your own hardware.

Zac67
  • 2,761
  • 1
  • 10
  • 21
  • Is FEC implemented at NIC's or is it somehow part of the cable itself. How to know if FEC is in use. Also, updated the question with more details. Thanks. – user1877095 Oct 30 '17 at 19:30
  • FEC is implemented inside the NIC (in the physical layer's PCS sublayer). – Zac67 Oct 30 '17 at 19:44
  • Is there a way to know my current NIC has FEC implemented? And, can you suggest any other means of achieving this, like using a very old NIC , or buy a custom NIC and appropriate cable or write my own LAN protocol ? – user1877095 Oct 30 '17 at 19:55
  • FEC is part of 10GbE upward. You can get all published standards on http://ieeexplore.ieee.org/document/7428776/ – Zac67 Oct 30 '17 at 19:56
  • 1
    The RTL8111 family is Gigabit Ethernet - no FEC. – Zac67 Oct 31 '17 at 08:53
2

While it's generally not possible to send Ethernet frames without appending a proper FCS, it is often possible to receive frames that don't have a correct FCS. Many network controllers support this, though it would likely require you to modify the native network device driver.

Many Intel NICs for example, have a mode setting that causes framing errors, FCS errors and other sorts of error frames to be discarded. The driver usually turns that feature on. This is generally desirable because such frames are unlikely to be useful (since they are known to be corrupted). However, for troubleshooting purposes, the NIC supports receiving all frames, including error frames. It's just that there's usually no reason to expose that feature to users. After all, who wants to receive known-corrupted frames?

It is customary to enable counters for such frames. Many NICs actually expose those via diagnostic counters. In Linux, you can often see these with ethtool -S <interface>.

For example, on my machine (note rx_crc_errors):

$ ethtool -S eth0
NIC statistics:
     rx_packets: 1629186
     tx_packets: 138121
     rx_bytes: 747886491
     tx_bytes: 12198820
     rx_broadcast: 0
     tx_broadcast: 0
     rx_multicast: 0
     tx_multicast: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 0
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 269
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 747886491
     rx_csum_offload_good: 1590047
     rx_csum_offload_errors: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus
Gil Hamilton
  • 11,973
  • 28
  • 51
  • I get less number of counters for my NIC, Realtek r8169. It does not contain rx_crc_errors and many other errors. Do you have an idea if this is because of the NIC itself or can a different driver give more statistics. – user1877095 Oct 31 '17 at 17:13
  • The selection of statistics shown is specific to the driver and NIC. – Gil Hamilton Oct 31 '17 at 17:15
  • The link here describes some way to send a corrupt FCS, though when I use the given method, a proper FCS is automatically appended. https://stackoverflow.com/a/6382971/1877095. My driver does not support the flag SO_NOFCS,(see https://stackoverflow.com/a/25922139/1877095) so may be this is the reason. – user1877095 Oct 31 '17 at 17:17
0

Sending wrong CRC/FCS is not possible with your NIC device (Realtek) . Your NIC keeps adding the FCS 4 bytes for every packet you send, even for "hand made" raw packets using AF_PACKET socket .

The only standard NICs that support sending wrong CRC/FCS, until now and as I know ,are the following INTEL NIC drivers : e1001, e1000, e100, ixgbe, i40e and igb .

Adel Belasker
  • 1
  • 1