Hi,
On Dec 4, 2007 4:52 PM, YOSHIFUJI Hideaki / 吉藤英明
<[EMAIL PROTECTED]> wrote:
> What do you mean by "ipv6 header"?
If IPPROTO_RAW is set, we supply the ipv6 header, extensions and payload.
> I think hdrincl is broken (and even, say, deprecated) on IPv6.
By IPv6 you mean the protocol, or L
Hi,
I've ran into an issue which i'm not sure that is known. I'm able to
provide a patch if people feel this is something that should be fixed.
Anyway, the source address of packets is not taken into account when
matching for xfrm policies when socket(AF_INET6, SOCK_RAW,
IPPROTO_RAW) sockets
Thank you all for these changes.
Hugo
On 2/14/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> [IPV4] devinet: Register inetdev earlier.
I needed to move the panic call as well.
[IPV4] devinet: Register inetdev earlier.
This patch allocates inetdev at reg
On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote:
1) Kernel network driver X detects that it has hardware to drive, and
consequently calls register_netdev. This creates the network interface and
registers all the appropriate proc and sysfs files, which are now accessible in
user space.
The pr
Yes, I understand that, but until the IFF_UP flag is set on the interface, it
doesn't really have any effect on the system as a whole. You should be able to
undo any default setting that you want before you call ifup on the interface, or
am I missing something?
If i understand what you are pro
Neil,
On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote:
Can't this simply be fixed by adding a custom udev rule? Correct me if I'm
wrong, but the only reason that interfaces come up automatically after their
appropriate module is inserted is because most distos udev rules issue an ifup
$DEVICE
Hi,
On 2/13/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> reenable it on the interfaces that you actually want.
Is there any technical reason to not have the sysconf entries
available at interface creation? It seems to
Hi Ville,
On Wed, Aug 02, 2006 at 10:58:49AM +0300, Ville Nuorvala wrote:
> To name just one issue: the chicken and egg problem of source address
> selection and source address based routing. I solved this problem by
> letting policy rules (with a source prefix) add additional constraints
> to the
Hi,
Thanks for the reply, however:
On Wed, Aug 02, 2006 at 12:24:30PM +0900, Masahide NAKAMURA wrote:
> Our patch is similar as you said. Our design is that kernel does nothing
> as possible about validation which can be done by user-space.
> As you mentioned ICMPv6 error is hard to be sent b
David,
On Tue, Aug 01, 2006 at 05:35:35PM -0700, David Miller wrote:
> This is partly why the multiple routing table code is being
> added as the initial infrastrucutre, so that source based
> things are possible.
There have been other approaches for partial source-based stuff. For
instance,
Jamal,
> nice to know ;-> At least you can protect some apps if you need to.
> Only racoon and quagga are important for me.
> But what happens then if you have a beast that just chews memory
> forever? I suppose other poor apps will just get shot.
You should push QoS and differentiation into t
David,
> To drive this home even more, I do not believe that the people who
> advocate pushing NDISC and ARP policy into userspace would be very
> happy if something like the RAID transformations were moved into
> userspace and they were not able to access their disks if the RAID
> transformer pro
David,
> So all of you userland control-plane fanatics, how will you handle
> things like NFS root with these daemon-required variants of NDISC and
> ARP?
Do it in the initial ramdisk, we only need the daemon to setup the
NDISC entries to talk to the NFS server. :-)
There is obviously a c
Hi,
> On the other hand, if a ND daemon loose the synchronization, it is
> unpredicable, I guess.
What do you mean by synchronization in this context? My idea was to
keep the ND state machine inside the kernel, and instead have the
daemon be reactive. That means it would send messages on beh
Hi,
First of all and to be fair let me introduce my bias -- i'm also
developing a mobility framework, which although not MIPv6-specific,
does support it (we'll be running a large set of tests during the
following month, hopefully culminating in an initial public release in
september). In ge
Hi Jamal,
Through this discussion i've identified three points: one is that
some believe control and data should be kept synchronized; the other is
how some (including all of the first :-) think control should remain
inside the kernel; and finally you and me so far who believe they
should b
> A couple of basic questions:
> 1. Can we just proceed assuming it is non-secure until a later time when
>the certificate path is established?
This is not something which is described in the standard. In fact,
processing the RA without a certificate path to the router already
assumes the
On Thu, Jul 27, 2006 at 08:20:44PM -0700, David Miller wrote:
>
> Now, if you're saying that, in response to a NDISC packet, we might
> have to go out and obtain the certificate, before we can process
> the NDISC packet. This is a different issue. Is that how this
> secure NDISC works? Or does
Hi,
On Thu, Jul 27, 2006 at 07:27:43PM -0700, David Miller wrote:
>
> Just like a TCP connection, packets cause state transitions.
> And it is reasonable to expect that after a state transition,
> the effects can be visible by subsequent packets.
Certainly, control packets cause state transit
Hi David,
> If we process these in sequence in software interrupt, everything
> is fine. Processing of "A" will add the address, and the test
> ping packet "B" will respond properly.
>
> If you defer "A", everything breaks and the test packet "B" will
> get processed first and not work.
Is i
Hi,
> I'm interested in the approach. And I have a couple of comments.
> I think DAD and ND are time critical operations.
> Can the daemons process with confirming to the specs.
My tests indicate that yes, even when considering mobility scenarios
where expected times are reduced. There is alw
Hi all,
In the same line as some of the recent IPv6 patches being submited
for comments, and taking into consideration RFCs such as 'SEcure
Neighbor Discovery (SEND)' (RFC 3971) and 'Cryptographically Generated
Addresses (CGA)' (RFC 3972) where the complexity associated with
maintaining add
Hi,
> static int
> +inet6_addr_modify(int ifindex, struct in6_addr *pfx,
> + __u32 prefered_lft, __u32 valid_lft)
> +{
...
> + ifp = ipv6_get_ifaddr(pfx, dev, 1);
> + if (ifp == NULL)
> + return -ENOENT;
> +
> + if (!valid_lft || (prefered_lft > valid_lf
Hi Herbert,
I have a couple of comments, please see below.
> The reason for this is that the problem that Hugo uncovered is only
> the tip of the iceberg. The real problem is that when we removed the
> dependency of ipip on xfrm4_tunnel we didn't really consider the module
> case at all.
>
>
> host in the internet is able to hang any such machine by sending an
The ipv6-enabled internet of course :-)
Hugo
signature.asc
Description: Digital signature
> I'd rather the suggested cleanup occur to solve this, and I think
> the fix is not so urgent that we can wait for the correct version
> to get coded up.
I would be glad to code a better version like i specified in an
earlier mail. I just didn't do it yet because Herbert said he would do
it.
> It would have been even worse, IMHO, to have two copies of
> nearly identical code sitting around which is basically what
> the alternative is.
We don't need two copies. We just need a function that does the real
work if there is a tunnel to be used (what xfrm6_tunnel needs), and
another on
> OK this is a bit ugly but will do for now. Could you please do it for
> the ICMP packet and IPv4 as well?
I find it ugly that the same function, in this case ip6ip6_rcv(), is
used in two contexts where the expected behaviour differs. Also, using
the current #ifdefs, ip6_tunnel is only load
Hi,
When ip6_tunnel discards a packet because there is no tunnel
associated with it, it sends a ICMPV6_DEST_UNREACH error to the packet
source. However, when using ip6_tunnel and xfrm6_tunnel, if there is a
a tunnel spi allocated for it, it may be processed dispite ip6_tunnel
having already
-submit the packet for processing. As no skb parameters
have been changed, ip6ip6_rcv() will continue to be called with the
exact same context. Also, ip6ip6_rcv() should free the skb when
discarding it.
Signed-off-by: Hugo Santos <[EMAIL PROTECTED]>
--- linux-2.6.16/net/ipv6/ip6_tunnel.
> When xfrm6_tunnel is in use you've just made it use a freed skb. Also
> IPv4 has the same problem so we shold fix them both.
I didn't hit this since i'm not currently using xfrm6_tunnel (which
is also why i got the soft lockup). I'll consider the case when
xfrm6_tunnel is being used, and s
() will continue to be called on the exact same
context. Also, ip6ip6_rcv() should free the skb when discarding it.
Signed-off-by: Hugo Santos <[EMAIL PROTECTED]>
--- linux-2.6.16/net/ipv6/ip6_tunnel.c.orig 2006-03-23 16:19:19.0
+
+++ linux-2.6.16/net/ipv6/ip6_tunnel.c 2006-03
Hi,
The included patch fixes ip6_tunnel to release the cached dst entry
when the tunnel parameters (such as tunnel endpoints) are changed so
they are used immediatly for the next encapsulated packets.
Signed-off-by: Hugo Santos <[EMAIL PROTECTED]>
--- linux-2.6.16-rc4/ne
Hi,
ip6_tunnel keeps a cached dst (dst_cache in ip6_tnl) per tunnel
instance. This cached dst is re-used while it's not marked obsolete. A
change of the tunnel's parameters (via SIOCCHGTUNNEL) does not
invalidate the dst_cache directly, which results on it being used by
ip6ip6_tnl_xmit afte
34 matches
Mail list logo
