On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
jamal wrote:
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in
Mark Butler wrote:
jamal wrote:
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the
On Fri, 2006-07-04 at 08:06 -0600, Mark Butler wrote:
In IPv4, how is this information supposed to be communicated? The
possibilities I can see are:
1. Assuming link local based on SO_BINDTODEVICE.
2. Adding a new field to sockaddr_in in a backward compatible manner
3. Defining a new
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927.
From: David Daney
Here is a new version of the patch I sent March 31. For background,
this is my description from the first patch:
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several
jamal [EMAIL PROTECTED] writes:
Ok, its a little more than grat arp (which i assumed it was). However,
the cause-fatale given in section 4 for why you wanna broadcast does
sound very lame. To quote: You do this in case two disjoint network
links are joined.
It isn't quite a gratuitous arp,
Am Samstag 01 April 2006 06:25 schrieb Herbert Xu:
BTW, I like your idea of moving STP to user-space. In fact I think we
can extend it to move ARP to user-space as well.
Neighbor address resolution is such a basic networking feature that it should
not depend on a running userspace daemon to
From: Stefan Rompf [EMAIL PROTECTED]
Date: Sat, 1 Apr 2006 12:17:01 +0200
Neighbor address resolution is such a basic networking feature that
it should not depend on a running userspace daemon to function
properly.
Routing is a pretty basic network feature, yet userspace manages it
and the
On Sat, Apr 01, 2006 at 02:27:15AM -0800, David S. Miller wrote:
Routing is a pretty basic network feature, yet userspace manages it
and the kernel just does the switching.
It's a control plane issue.
Exactly.
I'm not talking about moving everything into user-space either. Just the
bits
On Sat, Apr 01, 2006 at 09:33:40PM +1100, herbert wrote:
In fact most of the bits for that is already there since user-space can
already manipulate the ARP cache. The only missing bit is the notification
when there is a cache miss.
Oh and I totally agree that ARP resolution is such a
Am Samstag 01 April 2006 12:27 schrieb David S. Miller:
Neighbor address resolution is such a basic networking feature that
it should not depend on a running userspace daemon to function
properly.
Routing is a pretty basic network feature, yet userspace manages it
and the kernel just
On Sat, 2006-01-04 at 14:29 +0200, Stefan Rompf wrote:
Am Samstag 01 April 2006 12:27 schrieb David S. Miller:
Routing is a pretty basic network feature, yet userspace manages it
and the kernel just does the switching.
That's comparing apples with pies. For the average machine,
hi --
i'm not subscribed to netdev, so this probably won't make it to
the list. that's probably okay.
All ARP packets (*replies* as well as requests) that contain a Link-
Local 'sender IP address' MUST be sent using link-layer broadcast
instead of link-layer unicast. This
On Sat, 2006-01-04 at 08:24 -0500, Paul Fox wrote:
hi --
i'm not subscribed to netdev, so this probably won't make it to
the list. that's probably okay.
It made it.
Hopefully, the original poster
can explain what kind of problems they saw that prompted the patch.
i can't give an
Am Samstag 01 April 2006 14:50 schrieb jamal:
No stefan - check arpd. Infact if you really want to scale ARP to many
many entries, you do it in user space. This has been proven more than
once in the past: Thats the main reason the current daemons exist. It is
AFAIK the primary purpose of arpd
On Sat, 2006-01-04 at 17:11 +0200, Stefan Rompf wrote:
Am Samstag 01 April 2006 14:50 schrieb jamal:
No stefan - check arpd. Infact if you really want to scale ARP to many
many entries, you do it in user space. This has been proven more than
once in the past: Thats the main reason the
Herbert Xu wrote:
On Fri, Mar 31, 2006 at 09:49:31PM -0500, jamal wrote:
The RFC seems to talk about sender IP address instead though...
my understanding: the sender is trying to claim that IP and is setting
the destination to the IP it is trying to claim and see if someone
responds.
Are
jamal wrote:
On Sat, 2006-01-04 at 15:25 +1100, Herbert Xu wrote:
On Fri, Mar 31, 2006 at 09:49:31PM -0500, jamal wrote:
[..]
my understanding: the sender is trying to claim that IP and is setting
the destination to the IP it is trying to claim and see if someone
responds.
Are you sure?
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
most of the protocol (zcip, busybox, ...). The kernel's APR
On Fri, 2006-31-03 at 15:26 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
David Daney [EMAIL PROTECTED] wrote:
--- net/ipv4/arp.c.orig 2006-03-31 13:44:50.0 -0800
+++ net/ipv4/arp.c 2006-03-31 13:48:26.0 -0800
@@ -690,8 +691,13 @@ void arp_send(int type, int ptype, u32 d
if (dev-flagsIFF_NOARP)
return;
+ /* If
David Daney [EMAIL PROTECTED] wrote:
In any event, yes we should be testing the dest_ip. If the ARP packet
is destined for the link local network, it should be broadcast.
The RFC seems to talk about sender IP address instead though...
--
Visit Openswan at http://www.openswan.org/
Email:
On Sat, 2006-01-04 at 13:01 +1100, Herbert Xu wrote:
David Daney [EMAIL PROTECTED] wrote:
In any event, yes we should be testing the dest_ip. If the ARP packet
is destined for the link local network, it should be broadcast.
The RFC seems to talk about sender IP address instead
24 matches
Mail list logo
