Ethernet Error Correction

Ethernet Error Correction

[Karel Kulhavy]

What about implementing an Ethernet error correction in Linux kernel?

Does exist any standard that would normalize ethernet error correction? The
situation is basically this:

Let's say I have two PC's, with ethernet NIC's. An atmospherical optical link
(full duplex) is between them, connected via AUI. The optics goes crazy when
there is a fog of course. But dropping a single bit in 1500 bytes makes a lot
of mess.  There is also unsused src and dest address (12 bytes) which is
obvious and superfluous.  What about kicking the address off and putting some
error correction codes (like Hamming) into it and putting the cards into
promisc mode?  It would make the link work on bigger distance and on thicker
mist.  We could even dynamically change the ECC/data ratio for example with
Reed Solomon Codes. Ethernet modulation is strong gainst sync dropouts so the
bits usually remain their place, just some of them happen to flip. We could
also kick the "lenght" field because end of packet is recognized by a pulse
longer than 200ns, not neither by ECC nor by the length (am I right?).

Is anybody eager to implement this into the kernel? How would it be done
at all? I have personally no idea.

Clock

Re: Ethernet Error Correction

[Richard B. Johnson]

On Tue, 25 Sep 2001, Karel Kulhavy wrote:

> What about implementing an Ethernet error correction in Linux kernel?
> 

Ethernet uses hardware error detection. Only good packets get through.
Therefore there is nothing that a driver in the kernel could do to
recover an otherwise errored packet because the packet doesn't exist.

> Does exist any standard that would normalize ethernet error correction? The
> situation is basically this:
>

As stated, there is no "error correction" on ethernet. Only detection
exists. The ethernet packet consists of a sync preamble, the destination
address, the source address, a packet length, some data, then a CRC.

If the hardware CRC doesn't match, the packet is dropped by hardware.

TCP/IP and other actual network stuff goes in the "data" area.

 
> Let's say I have two PC's, with ethernet NIC's. An atmospherical optical link
> (full duplex) is between them, connected via AUI. The optics goes crazy when
> there is a fog of course. But dropping a single bit in 1500 bytes makes a lot
> of mess.  There is also unsused src and dest address (12 bytes) which is
> obvious and superfluous.  What about kicking the address off and putting some
>
[SNIPPED...]

If ethernet is being used for the optical link, it's only because such
boards are cheap and drivers exist.

An optical link, built from scratch, uses the same transceivers used
for fiber. They don't use Ethernet. Then use TAXI and/or other
self-clocking serial protocols.

A PPP link doesn't use source and destination addresses as does
Ethernet. You could make a serial driver for your IR link and
use PPP on both ends to communicate. The PPP overhead is quite
low. Your link will be as fast as the underlying hardware.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Ethernet Error Correction

[Ben Greear]

"Richard B. Johnson" wrote:
> 
> On Tue, 25 Sep 2001, Karel Kulhavy wrote:
> 
> > What about implementing an Ethernet error correction in Linux kernel?
> >
> 
> Ethernet uses hardware error detection. Only good packets get through.
> Therefore there is nothing that a driver in the kernel could do to
> recover an otherwise errored packet because the packet doesn't exist.
> 

That's probably the default of most chipsets, but I wonder if you could
tell it to send the busted packets up the stack anyway.  Then, the driver
could make the decision in software whether or not to correct/foward, or
discard the packet...  I assume that in order to detect a CRC error,
the NIC already has the packet in it's buffers somewhere...

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Ethernet Error Correction

[Richard B. Johnson]

On Tue, 25 Sep 2001, Ben Greear wrote:

> "Richard B. Johnson" wrote:
> > 
> > On Tue, 25 Sep 2001, Karel Kulhavy wrote:
> > 
> > > What about implementing an Ethernet error correction in Linux kernel?
> > >
> > 
> > Ethernet uses hardware error detection. Only good packets get through.
> > Therefore there is nothing that a driver in the kernel could do to
> > recover an otherwise errored packet because the packet doesn't exist.
> > 
> 
> That's probably the default of most chipsets, but I wonder if you could
> tell it to send the busted packets up the stack anyway.  Then, the driver
> could make the decision in software whether or not to correct/foward, or
> discard the packet...  I assume that in order to detect a CRC error,
> the NIC already has the packet in it's buffers somewhere...
> 

The easiest thing is to not use an Ethernet SNIC. Instead use some
other serializer/deserializer for the IR link. Then you make a
serial driver with whatever error correction you want. You use PPP
with this serial driver.

FYI, you will probably find that fogged-in IR is not recoverable.
It has been my experience that you don't get "single-bit" errors,
instead, you get bursts of garbage as the PLL data-recovery circuit
goes out-of-lock.

When using a TAXI chip and Hewlett-Packard transceivers on a
fiber IR link, I don't use any error detection/correction at all.
TCP/IP has a checksum. The normal retry/retransmit mechanism works
fine.

Slowly pulling the fiber connector out of the socket, thus increasing
the attenuation (just like fog), produces no errors until a threshold
is reached. Then, all I get is errors --just junk, as the PLL loses
lock.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Ethernet Error Correction

[Matti Aarnio]

On Tue, Sep 25, 2001 at 10:34:37PM +0200, Karel Kulhavy wrote:
> What about implementing an Ethernet error correction in Linux kernel?

	Wrong layer.

	Ok, IF you run it at physical interfaces, then yes, maybe.

> Does exist any standard that would normalize ethernet error correction?
> The situation is basically this:

	No, It is very hardware specific.
 
> Let's say I have two PC's, with ethernet NIC's. An atmospherical optical
> link (full duplex) is between them, connected via AUI. The optics goes
> crazy when there is a fog of course. But dropping a single bit in 1500
> bytes makes a lot of mess.  There is also unsused src and dest address
> (12 bytes) which is obvious and superfluous.

	MAC-level addresses ?  Right.

> What about kicking the address off and putting some error correction codes
> (like Hamming) into it and putting the cards into promisc mode?

	You will need a lot more than 12 octet of hamming code
	in that link for a 1500 octet frame.  The 12 octets might
        barely be enough to tell that a bit has flipped.

	Also, generic PROMISC mode still drops off received frames
	with CRC error.

	Being able to send larger frames, say 2000 - 3000 octets,
	might help more.  That enables doing heavy duty FEC.
	Essentially Reed-Solomon.

	Being able to receive those frames is a requirement, as
	well as being able to receive damaged frames.

	Loosing frame start might not be recoverable at this
	level, though.

> It would make the link work on bigger distance and on thicker mist.
> We could even dynamically change the ECC/data ratio for example with
> Reed Solomon Codes. Ethernet modulation is strong gainst sync dropouts
> so the bits usually remain their place, just some of them happen to flip.
> We could also kick the "lenght" field because end of packet is recognized
> by a pulse longer than 200ns, not neither by ECC nor by the length
> (am I right?).

	You mean the  length/type  field ?

	Better would be to use FEC hardware plugged into the AUI
	port.  Buffering/rate adaptation are also an issue.
	That is, Ethernet card sends the data at nominal rate of
	10 Mbps, but FEC processing adds another set of data on
	the link essentially doubling the data to be sent.
	Now there is a problem of sending generated 20 Mbps
	datastream thru final 10 Mbps optical link.

	Not a trivial thing at all.

	Perhaps modifying the interface card to use halved
	frequency chrystal at the interface cards, and then
	full speed at FEC output.

> Is anybody eager to implement this into the kernel? How would it be done
> at all? I have personally no idea.

	No.  Silicon is cheap and available.
	Furthermore, I see no real advantage at this when compared
	with e.g. 2 Mbps 802.11 radiolink at 2.4 GHz.  Use there
	the nominal 20-100 mW power, and good directional antennas.

	That hardware is half-duplex, but you can have a pair working
	at different frequencies.

	Instead of using standard spreading sequences, use something
	else -- the art of finding those is quite demanding.  Those
	sequences must be such that they have maximum code-distance
	from standard codes, and simultaneously fulfill the primarility
	condition of the sequence -- it must have long period.

	The IEEE 802.11 standard covers this quite well.


	The radio approach is equally complicated as is making
	special interface cards speaking with silicon FEC out
	from an AUI port.


> Clock

/Matti Aarnio

Re: Ethernet Error Correction

[Pavel Machek]

Hi!

> 	Also, generic PROMISC mode still drops off received frames
> 	with CRC error.

Hmm, sounds good. Someone should create tool for communication over
ethernet with broken crc's. Such communication would be stealth from
normal tcpdump. Do it on your provider's network to escape accounting ;^)

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Ethernet Error Correction

[Vojtech Pavlik]

On Thu, Sep 27, 2001 at 02:22:51PM +0000, Pavel Machek wrote:
> Hi!
> 
> > 	Also, generic PROMISC mode still drops off received frames
> > 	with CRC error.
> 
> Hmm, sounds good. Someone should create tool for communication over
> ethernet with broken crc's. Such communication would be stealth from
> normal tcpdump. Do it on your provider's network to escape accounting ;^)

But still you'll see the number of errors on your eth card
skyrocketing, so you'd grow quite suspicious. 

> 
> -- 
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

Re: Ethernet Error Correction

[Pavel Machek]

Hi!

> > > 	Also, generic PROMISC mode still drops off received frames
> > > 	with CRC error.
> > 
> > Hmm, sounds good. Someone should create tool for communication over
> > ethernet with broken crc's. Such communication would be stealth from
> > normal tcpdump. Do it on your provider's network to escape accounting ;^)
> 
> But still you'll see the number of errors on your eth card
> skyrocketing, so you'd grow quite suspicious. 

Yep, but it would be _very_ hard for you to find the cause. You'd
probably chase ghosts trying to replace cables, etc, never finding
what happens.


							Pavel
-- 
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Ethernet Error Correction

[Vojtech Pavlik]

On Tue, Oct 02, 2001 at 11:48:01AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > 	Also, generic PROMISC mode still drops off received frames
> > > > 	with CRC error.
> > > 
> > > Hmm, sounds good. Someone should create tool for communication over
> > > ethernet with broken crc's. Such communication would be stealth from
> > > normal tcpdump. Do it on your provider's network to escape accounting ;^)
> > 
> > But still you'll see the number of errors on your eth card
> > skyrocketing, so you'd grow quite suspicious. 
> 
> Yep, but it would be _very_ hard for you to find the cause. You'd
> probably chase ghosts trying to replace cables, etc, never finding
> what happens.

Well, if you checked all the cables, you'd most likely find the device
capable of sending the bad CRC frames. Also, if you use a switch (not ha
hub or coax), it won't work at all.

-- 
Vojtech Pavlik
SuSE Labs

Re: Ethernet Error Correction

[Rob Landley]

On Tuesday 02 October 2001 05:55, Vojtech Pavlik wrote:
> On Tue, Oct 02, 2001 at 11:48:01AM +0200, Pavel Machek wrote:
>
> Well, if you checked all the cables, you'd most likely find the device
> capable of sending the bad CRC frames. Also, if you use a switch (not ha
> hub or coax), it won't work at all.

You can cause a lot of switches to degrate to HUB mode by overloading their 
arp cache mac address table thingy.  (Fun for packet sniffing when you've got 
a card that can change its mac address in software.  Send packets originating 
from a few thousand different mac IDs and watch the switch throw up its hands 
and go "AAAAAH!".  Sniffing the right init sequence for a pppoe connection 
with nonstandard authentication can be a bit difficult otherwise, with modern 
hardware... :)

I haven't tried it on a very wide variety of manufacturer's switches, though. 
 And I dunno how that relates to CRC behavior...

Rob

Re: Ethernet Error Correction

[Matti Aarnio]

On Tue, Oct 02, 2001 at 11:48:01AM +0200, Pavel Machek wrote:
> > > > 	Also, generic PROMISC mode still drops off received frames
> > > > 	with CRC error.
> > > 
> > > Hmm, sounds good. Someone should create tool for communication over
> > > ethernet with broken crc's. Such communication would be stealth from
> > > normal tcpdump. Do it on your provider's network to escape accounting ;^)
> > 
> > But still you'll see the number of errors on your eth card
> > skyrocketing, so you'd grow quite suspicious. 
> 
> Yep, but it would be _very_ hard for you to find the cause. You'd
> probably chase ghosts trying to replace cables, etc, never finding
> what happens.

	This kind of use will need its own network driver, which
	will count errors differently, of course.

> 							Pavel

/Matti Aarnio

Re: Ethernet Error Correction

[Alan Cox]

> there is a fog of course. But dropping a single bit in 1500 bytes makes a lot
> of mess.  There is also unsused src and dest address (12 bytes) which is
> obvious and superfluous.  What about kicking the address off and putting some
> error correction codes (like Hamming) into it and putting the cards into
> promisc mode?  It would make the link work on bigger distance and on thicker
> mist.  We could even dynamically change the ECC/data ratio for example with
> Reed Solomon Codes. Ethernet modulation is strong gainst sync dropouts so the
> bits usually remain their place, just some of them happen to flip. We could
> also kick the "lenght" field because end of packet is recognized by a pulse
> longer than 200ns, not neither by ECC nor by the length (am I right?).

You could do this by picking the right cards turning off CRC filtering and
doing a lot of work in software yes

Re: Ethernet Error Correction

[Albert D. Cahalan]

Karel Kulhavy writes:

> Let's say I have two PC's, with ethernet NIC's. An atmospherical optical link
> (full duplex) is between them, connected via AUI. The optics goes crazy when
> there is a fog of course. But dropping a single bit in 1500 bytes makes a lot
> of mess.  There is also unsused src and dest address (12 bytes) which is
> obvious and superfluous.  What about kicking the address off and putting some
> error correction codes (like Hamming) into it and putting the cards into
> promisc mode?  It would make the link work on bigger distance and on thicker
> mist.  We could even dynamically change the ECC/data ratio for example with
> Reed Solomon Codes. Ethernet modulation is strong gainst sync dropouts so the
> bits usually remain their place, just some of them happen to flip. We could
> also kick the "lenght" field because end of packet is recognized by a pulse
> longer than 200ns, not neither by ECC nor by the length (am I right?).

Do something like RAID 5 over multiple packets. Then you can
handle cards that just drop corrupt packets.