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] [day] [month] [year] [list]

Message-Id: <20090425110755.30b6006e.ipng@69706e6720323030352d30312d31340a.nosense.org>
Date:	Sat, 25 Apr 2009 11:07:55 +0930
From:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	netdev@...r.kernel.org, Jay Vosburgh <fubar@...ibm.com>
Subject: Re: [RFC, PATCH 2.6.29.1] Ethernet V2.0 Configuration Testing
 Protocol

Hi Eric,

Thanks very much for your time.

On Fri, 24 Apr 2009 09:36:14 +0200
Eric Dumazet <dada1@...mosbay.com> wrote:

> 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.
> > 
<snip> 
> 
> 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...)

ECTP is designed exactly for that purpose - verifying
remote Ethernet node availability. The unicast ECTP message would
contain a forward message, specifying the originator's MAC address, and
a reply message. The receiver, if it is available, just forwards the
packet to the (unicast) MAC address provided in the current forward
message. For a liveness test, the MAC address in the forward message
would be that of the ECTP packet originator.

>  I presume most routers support ETCP?
> 

Cisco IOS routers do. They also use the protocol as their Ethernet
keepalive test, altough those packets don't comply with the
specification - the packet src and destination addresses are both the
MAC address of the interface source, and they only contain a reply
message, where as the minimum compliant packet should have a forward
message and a reply message. I haven't completely worked out how that is
supposed to work, as any upstream switches won't forward a packet back
out the interface the packet is received on.

> Is ectpping needing your kernel patches, or can it work with current kernel ?

It doesn't need the kernel patches to work. Of course, without my
patch, Linux hosts won't respond.

> If not too large, you could post its source on this list.
> 

It's not so much that it's too large, more that I've got a few minor
things left to do it e.g. put licensing info in, put a version number
in etc. It's also generally a bit thrown together, as my focus was on
the kernel module.

I'll fix those things over the next few days, and put it up on the net.

Thanks again,
Mark.
--
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