New ethernet sniffer program

I wrote a prototype packet sniffer for ethernet. It runs on Debian 9 as-is.
The program has a packet counter. Warning! it displays packet data in clear ascii.


https://github.com/valeriob01/etherframe


To compile the program just issue

make

There is an included program called listeth that lists all network interfaces in the system. Compile it with

make listeth

and run

./listeth

You will get a list of network interface names. You can then pass the interface name to etherframe with

./etherframe <interface name>

Without arguments the program defaults to eth0

[chalsall]

Originally Posted by SELROC

I wrote a prototype packet sniffer for ethernet.

How is this any better than tcpdump?

Can the output be fed into Wireshark?

Originally Posted by chalsall

How is this any better than tcpdump?

Can the output be fed into Wireshark?

I am not going to compete with tcpdump. I wrote this for exercise.


The output is a simple printf() so it should go to the standard output.

[chalsall]

Originally Posted by SELROC

I am not going to compete with tcpdump. I wrote this for exercise.

That's fair. And drilling down on your code, I find it quite clean.

Originally Posted by chalsall

That's fair. And drilling down on your code, I find it quite clean.

Thanks. Today I added the possibility to select the promiscuous mode enable/disable.

./etherframe <interface name> <promiscuous mode>

where promiscuous mode = 0=disabled, 1=enabled


the arguments are both optional.

[chalsall]

Originally Posted by SELROC

the arguments are both optional.

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.

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.

A true test would need a specific lab setup which I don't have. The current program reads packets and if there are incomplete packets, it increments some counter (COP and ROP).


I am aware of the thing.

[chalsall]

Originally Posted by SELROC

I am aware of the thing.

Please define "thing", in this context.

Edit: Not trying to be an *, but the word "thing" can mean many different things in and out of context. Some use it to cover the fact they can't communicate well. I believe you can, so please clarify.

Originally Posted by chalsall

Please define "thing", in this context.

Edit: Not trying to be an *, but the word "thing" can mean many different things in and out of context. Some use it to cover the fact they can't communicate well. I believe you can, so please clarify.

The thing comes from outer space :-)


More seriously, the thing is "what you said".

Originally Posted by SELROC

A true test would need a specific lab setup which I don't have. The current program reads packets and if there are incomplete packets, it increments some counter (COP and ROP).

I studied the problem a bit more. The specific problem is that bad frames are dropped in driver and do not make it to layer 2. This method would require modifying the network driver to make it ignore bad frames and pass them to upper layers.


So I will have to adopt another method, probably based on some data acquisition device.

Originally Posted by SELROC

I studied the problem a bit more. The specific problem is that bad frames are dropped in driver and do not make it to layer 2. This method would require modifying the network driver to make it ignore bad frames and pass them to upper layers.

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.