netdev - Re: [RFC, PATCH 2.6.29.1] Ethernet V2.0 Configuration Testing Protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49F16BEE.2040902@cosmosbay.com>
Date:	Fri, 24 Apr 2009 09:36:14 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
CC:	netdev@...r.kernel.org, Jay Vosburgh <fubar@...ibm.com>
Subject: Re: [RFC, PATCH 2.6.29.1] Ethernet V2.0 Configuration Testing Protocol

Mark Smith a écrit :
> Hi,
> 
> I'm hoping my attached implementation of the Ethernet V2.0 Configuration
> Testing Protocol could be reviewed, with eventual goal of inclusion in
> the kernel.
> 
> Ethernet V2.0 Configuration Testing Protocol (ECTP) is an old Ethernet
> testing protocol, specified in section 8 of the original Ethernet V2.0
> specification. It provides request/reply "ping" style testing at
> the Ethernet layer, testing of a path via a list of devices (i.e. a
> strict source route), and identification of ECTP capable devices via
> broadcast or multicast ECTP requests.
> 
> I've had a go at implementing it for a number of reasons:
> 
> o  My day job involves running networks, and eventually you start to
> wonder what is going on inside the devices you use. I think having a go
> at implementing something is a good way to learn.
> 
> o  It's a very simple protocol (a single frame format), so it could be
> a good starting point for people who'd like to understand more about
> how networking works in the Linux kernel. I've tried to make the
> implementation easy for people to follow what it is doing.
> 
> o  It's actually quite useful - every now and then people in networking
> say, "wouldn't it be great if there was an Ethernet ping which didn't
> require IP to work". Recent Ethernet OAM standards provide that, but
> they're a lot more complicated to implement than ECTP, and I needed
> something simple to start with :-)
> 
> o  It might finally make Linux completely compliant with the Ethernet
> V2.0 specification which says that the protocol is required!
> 
> I've also put together a testing utility. I need to put a bit more
> polish on it, and find somewhere to host it, which I'll do in the next
> few days. Here are a couple of examples of it's use:
> 
> o  a unicast ECTP "ping"
> 
> [root@opy ectpping]# ./ectpping -i tap0 52:54:00:12:34:56
> ECTPPING 52:54:00:12:34:56 (qa64-eth0) using tap0
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=0 time=0.000346 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=1 time=0.000209 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=2 time=0.000203 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=3 time=0.000187 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=4 time=0.000210 sec
> ^C
> ---- 52:54:00:12:34:56 (qa64-eth0) ECTPPING Statistics ----
> 5 packets transmitted, 5 packets received, 0.000000% packet loss
> round-trip (sec)  min/avg/max/total = 0.000187/0.000231/0.000346/0.001155
> 
> 
> o  a multicast ECTP "ping"
> 
> [root@opy ectpping]# ./ectpping -i tap0
> ECTPPING cf:00:00:00:00:00 (loopback-assist) using tap0
> 106 bytes from 52:54:00:12:34:57 (qa64-eth1): ectp_seq=0 time=0.018630 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=0 time=0.056334 sec
> 106 bytes from 52:54:00:12:34:58 (qa64-eth2): ectp_seq=0 time=0.056656 sec
> 106 bytes from 52:54:00:12:34:58 (qa64-eth2): ectp_seq=1 time=0.020351 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=1 time=0.024241 sec
> 106 bytes from 52:54:00:12:34:57 (qa64-eth1): ectp_seq=1 time=0.031350 sec
> 106 bytes from 52:54:00:12:34:58 (qa64-eth2): ectp_seq=2 time=0.049382 sec
> 106 bytes from 52:54:00:12:34:57 (qa64-eth1): ectp_seq=2 time=0.067358 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=2 time=0.074230 sec
> ^C
> ---- cf:00:00:00:00:00 (loopback-assist) ECTPPING Statistics ----
> 3 packets transmitted, 9 packets received, 3.00 times packet increase
> round-trip (sec)  min/avg/max/total = 0.018630/0.044281/0.074230/0.398532
> 
> While I'm finishing off the utility, I thought I'd post the kernel
> source to get it out there for people to have a look at. I'd really
> appreciate any suggestions for improvement, or any pointers to where
> I've done the wrong thing or had any miss understandings. The patch is
> against 2.6.29.1.
> 
> Thanks very much,
> Mark.
> 
> (please CC me, as I'm not on the mailing list)
> 

Hello Mark

I am trying to find how ETCP could be useful :)

Could bonding use ETCP as a third way to validate a slave is operational ?

First way is mii-mon (link presence to next hop)
  -> Very lazy since we can be connected to a switch that lost all connectivity to other equipments.

Second way is arp_ping (list of 1 to 16 IP addresses)
  -> broadcast messages.
   If many hosts are on [V]LAN, and small arp_interval, this can generate extra trafic.

Third way : ETCP messages sent to given MAC address ?
  (Unicast messages, and no VLAN troubles...)
 I presume most routers support ETCP?

Is ectpping needing your kernel patches, or can it work with current kernel ?
If not too large, you could post its source on this list.

Thank you

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html