From owner-freebsd-hackers Thu Apr 30 11:55:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27487 for freebsd-hackers-outgoing; Thu, 30 Apr 1998 11:55:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA27478 for ; Thu, 30 Apr 1998 11:55:18 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Thu Apr 30 13:55 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id NAA03698 for ; Thu, 30 Apr 1998 13:55:10 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 30 Apr 1998 14:55:03 -0400 Message-ID: To: klmac@baldcom.net Cc: hackers@FreeBSD.ORG Subject: RE: Ethernet address takeover implementation proposal Date: Thu, 30 Apr 1998 14:54:59 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---------- > From: Ken McKittrick[SMTP:klmac@baldcom.net] > > The link-level protocol would go a ways towards the High Availability > project. I more intested in that area. > This is a short description of my implementation (as I remember it, I don't have it handy now to look up): The protocol implementation is send-only. BPF can be used for receiving. I think it's a lot simpler and more elegant way than inventing the second BPF-like interface. BPF already has enough power to filter out any subset of packets received through an interface. The protocol itself does not make any assumptions about the packet contents. It is just transferring the contents to the link level. Of course, the implementation has some link-level-specific parts to extract the link-level address from a packet and pass it to the lower level. Now only the Ethernet support if present. So, essentially it's almost a NOP. :-) Any suggestions/objections are welcome ! :-) Especially from the core team members :-) Besides sending out a broadcast ARP response, other possible usages of this thing include, for example, a slow and inefficient user-level Ethernet bridge with arbitrary firewall. -Serge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message