Send bits over physical ethernet cable without any error correction like FCS or CRC

Question

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.

Answer 1

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.

Answer 2

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 .

Answer 3

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