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
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
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
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 me
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
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
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
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 by
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
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
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 process
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 the
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, in
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
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
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
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
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_lft))
+
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
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
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 it reasonable
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
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 the
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.
For
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.
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
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
-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.c.orig
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
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
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 one
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
32 matches
Mail list logo
