lkml.org 
[lkml]   [1999]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Fw: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries??
From
Date
[only cc'ed to linux-kernel because all other CCs got dropped before I see
it - in case this mail is interesting for other mailinglists that were on
the original cc list too please forward]

In article <19990208170504.29205@execpc.com>,
mitch@execpc.com (Mitchell Blank Jr) writes:

> 1. Allowing an interface address of 0.0.0.0. I think we can both
> agree this is non-optimal since it conflicts with the use of
> INADDR_ANY in bind(). Obviously we disagree on the severity
> of this problem.
> 2. lpf. This is non-optimal because it requires the application
> to know the link-layer encapsulation in use (which it doesn't)

Linux 2.2 provides a link layer independent interface to packet sockets
(using PF_PACKET, SOCK_DGRAM - see packet.4 in ftp.muc.de:/people/ak/netman*)

It is probably better to not use LPF currently, because the version in
2.2.1 is buggy. For DHCP's need user space filtering should be fast
enough anyways (remember that you can bind on a link layer protocol for
packet sockets)

> It seems to me that the linux folks who opinions matter (which doesn't
> include me, BTW, so don't put this all on my shoulders just because I
> answered Mike's question) aren't too keen supporting the
> less-than-perfect 0.0.0.0 system. I think the only solution that can
> possibly make everybody happy is that if we had a way to get an packet
> socket that allowed sending arbitrary L3 frames allowing the kernel to
> do the L2 encaps as usual.

AF_PACKET, SOCK_DGRAM should allow that.

-Andi

--
This is like TV. I don't like TV.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.044 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site