mersenneforum.org New ethernet sniffer program
 Register FAQ Search Today's Posts Mark Forums Read

 2018-09-13, 14:26 #1 SELROC   3·1,181 Posts 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 Code: make There is an included program called listeth that lists all network interfaces in the system. Compile it with Code: make listeth and run Code: ./listeth You will get a list of network interface names. You can then pass the interface name to etherframe with Code: ./etherframe  Without arguments the program defaults to eth0
2018-09-13, 17:13   #2
chalsall
If I May

"Chris Halsall"
Sep 2002

3·3,109 Posts

Quote:
 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?

2018-09-13, 17:26   #3
SELROC

23×11×103 Posts

Quote:
 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.

2018-09-13, 19:04   #4
chalsall
If I May

"Chris Halsall"
Sep 2002

3·3,109 Posts

Quote:
 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.

2018-09-14, 06:29   #5
SELROC

3·11·107 Posts

Quote:
 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.

Code:
./etherframe <interface name> <promiscuous mode>

where promiscuous mode = 0=disabled, 1=enabled

the arguments are both optional.

2018-09-14, 19:33   #6
chalsall
If I May

"Chris Halsall"
Sep 2002

3×3,109 Posts

Quote:
 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.

2018-09-15, 02:48   #7
SELROC

25·5·59 Posts

Quote:
 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.

2018-09-15, 22:06   #8
chalsall
If I May

"Chris Halsall"
Sep 2002

3×3,109 Posts

Quote:
 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.

Last fiddled with by chalsall on 2018-09-15 at 22:16

2018-09-16, 04:19   #9
SELROC

24·3·107 Posts

Quote:
 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".

Last fiddled with by SELROC on 2018-09-16 at 04:51

2018-09-17, 08:09   #10
SELROC

2·5·11 Posts

Quote:
 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.

2018-09-17, 17:08   #11
SELROC

10111111011002 Posts

Quote:
 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post jasong GPU Computing 19 2011-08-23 03:32 rogue Lounge 5 2009-10-02 15:02 Primeinator Information & Answers 5 2009-07-16 21:42 tribal Information & Answers 5 2009-03-19 20:54 drakkar67 Prime Sierpinski Project 14 2005-11-29 06:25

All times are UTC. The time now is 08:57.

Tue Dec 1 08:57:28 UTC 2020 up 82 days, 6:08, 1 user, load averages: 1.35, 1.62, 1.81