New ethernet sniffer program

Originally Posted by chalsall

If I may, just drilling down on the premise of your code (being able to detect noise on a link), I'm not sure that your code can accomplish this.

When I try to do this kind of thing from one end, I do flood pinging (ICMP). If I have control of both ends of the connection I use UDP packets. But this only tells me packet loss, it doesn't give me any data with regards to noise nor attenuation, etc. Usually I get this kind of thing via SNMP messages from the devices (but, obviously, only if I have control of them).

Not trying to discourage you, but I'd be very interested if you have figured out a way to collect such data using only "sniffing the wire" at Layer 2.

You might be interested in this probably:


https://github.com/valeriob01/fcs-control

[Nick]

Originally Posted by SELROC

Even worse, the crc checking is sometimes off-loaded to hardware (NIC), in this case the only possible thing to do is modify the NIC bios.

You would have to decide precisely how you define a "bad frame".
Which frames are so bad that they no longer count as frames (for you), and does your definition agree with what the hardware & driver do?

Originally Posted by Nick

You would have to decide precisely how you define a "bad frame".
Which frames are so bad that they no longer count as frames (for you), and does your definition agree with what the hardware & driver do?

hello, usually a bad frame is one which has a wrong CRC at the end. If you know other parameters to identify a bad frame please let me know.

[Nick]

Originally Posted by SELROC

hello, usually a bad frame is one which has a wrong CRC at the end. If you know other parameters to identify a bad frame please let me know.

Runts (i.e. frames shorter than the minimum length), jabbers (frames longer than the maximum length), misaligned frames (number of bits is not a multiple of 8), ....

Originally Posted by Nick

Runts (i.e. frames shorter than the minimum length), jabbers (frames longer than the maximum length), misaligned frames (number of bits is not a multiple of 8), ....

I'm not sure and I should read some documentation. Generally it should be like this: short frames are padded up to minimum length. There is the notion of jumbo frame so it is not so evident what is a jabber.


misaligned frames should be dropped in theory.

[LaurV]

If you ask me, I would drop all frames which are not "perfect". No padding, no cutting, no passing over to somebody else, like "I_don't_know_what_to_make_of_it,_but_I_give_it_to_you_maybe_you_can_sort_it_out"-frame. These are bad, just discard/scrap them. No trying fixing it, either. You may have issues talking with, or understanding some other entities in your universe, but on the other hand, any message jumping from one component to another inside of your box consumes time and resources, and it helps my DoS attach. I can serve you a bunch of bad frames on purpose and you will lose few centuries trying to decode them, or passing them around hoping (or hopping?) that "some guy in your organization" can decode them.

Real life: years ago we developed some parts for an ATM machine for a French customer. The "development" was more like copying the functionality of an existent product, due to non-availability of the components - the original design was done in the nineties, and most parts were end-of-life and difficult to get. The device contained a bridge between two protocols, i.e. beside of sending stuff to both ends it was connected to, it could also take strings from one side and pass them to the other side, converted to right format, if the strings were not addressed to the device itself, in which case they would be parsed, executed, whatever. The design being so old and EOL, the customer had not many specs and gave us real devices to "hack". I did part of the hacking, and all the software. I did the communication my own way. Keeping the compatibility, but still my own way. The product was a success (we are still producing it), but for a while they used both suppliers (us, and the original supplier). Then, they extended to US market, and with this, some more rigorous testing. Guess what, the original design didn't pass the tests - the whole machine could be easily locked with some radio beams. We are now the only supplier.

On the other hand, if you make a sniffer... (i.e. you may want to keep everything, for analysis...)

Originally Posted by LaurV

If you ask me, I would drop all frames which are not "perfect". No padding, no cutting, no passing over to somebody else, like "I_don't_know_what_to_make_of_it,_but_I_give_it_to_you_maybe_you_can_sort_it_out"-frame. These are bad, just discard/scrap them. No trying fixing it, either. You may have issues talking with, or understanding some other entities in your universe, but on the other hand, any message jumping from one component to another inside of your box consumes time and resources, and it helps my DoS attach. I can serve you a bunch of bad frames on purpose and you will lose few centuries trying to decode them, or passing them around hoping (or hopping?) that "some guy in your organization" can decode them.

Real life: years ago we developed some parts for an ATM machine for a French customer. The "development" was more like copying the functionality of an existent product, due to non-availability of the components - the original design was done in the nineties, and most parts were end-of-life and difficult to get. The device contained a bridge between two protocols, i.e. beside of sending stuff to both ends it was connected to, it could also take strings from one side and pass them to the other side, converted to right format, if the strings were not addressed to the device itself, in which case they would be parsed, executed, whatever. The design being so old and EOL, the customer had not many specs and gave us real devices to "hack". I did part of the hacking, and all the software. I did the communication my own way. Keeping the compatibility, but still my own way. The product was a success (we are still producing it), but for a while they used both suppliers (us, and the original supplier). Then, they extended to US market, and with this, some more rigorous testing. Guess what, the original design didn't pass the tests - the whole machine could be easily locked with some radio beams. We are now the only supplier.

On the other hand, if you make a sniffer... (i.e. you may want to keep everything, for analysis...)

I got a sense on how to do NIC options manipulation with the "ethtool" program. If ethtool does its job well, it is possible to use an option to manipulate NIC flags, with it I can set the various off-loads to off, and with the rx-fcs option I can switch off crc checking (in theory).


On the other hand I am still searching a C library that lets me read unconditioned ethernet frames.

Originally Posted by SELROC

I got a sense on how to do NIC options manipulation with the "ethtool" program. If ethtool does its job well, it is possible to use an option to manipulate NIC flags, with it I can set the various off-loads to off, and with the rx-fcs option I can switch off crc checking (in theory).


On the other hand I am still searching a C library that lets me read unconditioned ethernet frames.

There are two ethtool options to achieve each of these:

ethtool -K eth0 rx-fcs on  #1 give us the FCS field

ethtool -K eth0 rx-all on  #2 even receive bad packets

not all NICs can do that, it is quite driver-dependent.

Originally Posted by SELROC

There are two ethtool options to achieve each of these:

ethtool -K eth0 rx-fcs on  #1 give us the FCS field

ethtool -K eth0 rx-all on  #2 even receive bad packets

not all NICs can do that, it is quite driver-dependent.

I forgot to say that the network cable to be used in this experiment has to be dissected and each twisted pair or single wire treated differently via an ad-hoc lab. setup. Currently I am acquiring the necessary material.

[chalsall]

Originally Posted by SELROC

I forgot to say that the network cable to be used in this experiment has to be dissected and each twisted pair or single wire treated differently via an ad-hoc lab. setup. Currently I am acquiring the necessary material.

Keep at it. This could be a very useful tool!

[kriesel]

Originally Posted by Nick

Runts (i.e. frames shorter than the minimum length), jabbers (frames longer than the maximum length), misaligned frames (number of bits is not a multiple of 8), ....

If you want a runt generator, try what an amateur network admin did on our shared uplink network some years ago; put too many hubs in series between switches or routers, and ordinary equipment at the far end. A media converter counts as half a hub. It helps to have speed mismatches to overload the low speed end.

Late collisions in ordinary traffic in this situation generate runts. (Low budget university networking done by a student not knowledgable about networking or coordinating with people who know what they're doing creates such things. AUI to RJ45 to thin coax to AUI to fiber to stand off lightning potentials between buildings to RJ45 to chained hubs to media converter to old NIC... I think there was a hub or two in there somewhere used as a media converter.)

This was in the bad old days before we had switches with per-port diagnostics. I forget the name of the network monitor used to localize the issue to the smallest network connected to the common uplink, by looking at the content of the abandoned runt packets.