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.


[URL]https://github.com/valeriob01/etherframe[/URL]


To compile the program just issue [CODE]make[/CODE] There is an included program called [B]listeth[/B] that lists all network interfaces in the system. Compile it with [CODE]make listeth[/CODE] and run [CODE]./listeth[/CODE]You will get a list of network interface names. You can then pass the interface name to etherframe with [CODE]./etherframe <interface name>[/CODE]Without arguments the program defaults to eth0

[QUOTE=SELROC;496004]I wrote a prototype packet sniffer for ethernet.[/QUOTE]

How is this any better than tcpdump?

Can the output be fed into Wireshark?

[QUOTE=chalsall;496011]How is this any better than tcpdump?

Can the output be fed into Wireshark?[/QUOTE]




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.

[QUOTE=SELROC;496014]I am not going to compete with tcpdump. I wrote this for exercise.[/QUOTE]

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

[QUOTE=chalsall;496022]That's fair. And drilling down on your code, I find it quite clean.[/QUOTE]


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


[CODE]./etherframe <interface name> <promiscuous mode>[/CODE]


where promiscuous mode = 0=disabled, 1=enabled


the arguments are both optional.

[QUOTE=SELROC;496050]the arguments are both optional.[/QUOTE]

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.

[QUOTE=chalsall;496090]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.[/QUOTE]


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.

[QUOTE=SELROC;496113]I am aware of the thing.[/QUOTE]

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.

[QUOTE=chalsall;496153]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.[/QUOTE]


The thing comes from outer space :-)


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

[QUOTE=SELROC;496113]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).[/QUOTE]


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.

[QUOTE=SELROC;496227]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.[/QUOTE]


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.