Re: broken link-local multicast?
On Thu, 14 Feb 2008, Marco d'Itri wrote: Does anybody have any idea about how to debug this? [EMAIL PROTECTED]:~# ping6 -c 1 -I eth1 ff02::1 connect: Network is unreachable Maybe 'netstat -gn' could give clues, because you should be receiving a response at least from the loopback address. Maybe your loopback interface has went down, or ospf6d took it down and back up (at least some time ago, kernel's v6 got very confused after that). You may also want to check out that your link-local address on the interface you're pinging is still OK. # netstat -gn | grep ff02 lo 1 ff02::1 eth02 ff02::1:ff7b:259 eth01 ff02::1 # ping6 -c 1 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::207:e9ff:fe7b:259 eth0: 56 data bytes 64 bytes from ::1: icmp_seq=0 ttl=64 time=0.057 ms -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
radvd 1.1 released
Hi, A new version of radvd has been released. There have been a couple of new features. Interfaces must now be RUNNING, not just UP, to be considered by default radvd configuration. This is because nowadays kernels no longer generate v6 link-local addresses if the interface is just UP, in contrast to e.g., what earlier kernels did. I'd like issue special thanks to Jim Paris for all the patches he has sent :-). Get it at: http://www.litech.org/radvd/ Changes since 1.0: * Implement privilege separation on Linux: a master root process (which is able to reconfigure interfaces) and the main process. There is '-s' toggle to keep old behaviour. * Fix Linux retrans_timer on old kernels (newer ones have retrans_timer_ms) * Fix stderr+syslog (default) logging on non-i386 platforms. * Require that interface must be RUNNING instead of just UP. Note: this could break deployments with very old kernels. * Implement automatic interface address advertising with special prefix ::/64. * Relax interface naming (e.g. with VLANs) requirements. * Fix ordering of route, prefix and RDNSS options (only matters with RDNSS) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/05] ipv6: RFC4214 Support
On Tue, 6 Nov 2007, David Stevens wrote: give it away on this specific instance. I'm not sure if you should attribute to hidden agendas what you can explain by doing the right thing (granted, very few companies do this which may make it suspect, but still..). Pekka, I'm not assuming hidden agendas here; I simply don't know what they mean by no license for implementers. It doesn't say they relinquish *all* licensing, which would be clearer if that's what they mean. If implementers, distributors, and users are included, then who's left that does need licensing? If that answer really is nobody, then why bother with for implementers.? So, I don't think it's a hidden agenda, I think they said what they mean. I just don't know what they mean. :-) If you look at the page they used to file the disclosure: https://datatracker.ietf.org/ipr/new-specific/ You'll notice that they chose the most relaxed option available, and all the options only discuss implementers not distributors. Now, if you look at the background commentary of the subject: http://tools.ietf.org/html/rfc3905 .. the comment about that particular option is: a) No License Required for Implementers: The Patent Holder does not require parties to acquire any license to its Necessary Patent Claims in order to make, have made, use, import, offer to sell, sell, or distribute technology that implements such an IETF specification. Seems clear to me, though someone could argue whether RFC 3905 is normative in this context, i.e., whether the person who submitted the disclosure understood the comment quoted above and that that's the way no license required for implementers must be interpreted. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/05] ipv6: RFC4214 Support
On Tue, 6 Nov 2007, David Miller wrote: From: David Stevens [EMAIL PROTECTED] Date: Tue, 6 Nov 2007 22:07:44 -0800 I guess license is no longer required for implementers of ISATAP. Is it right, Fred? https://datatracker.ietf.org/ipr/550/ Does this also allow license-free redistribution? I'm certainly no lawyer, but I don't see the point of having a patent that doesn't restrict *something*. :-) DavidS, the history here is that first the IPR holder did not grant license-free implementation. After considerable time (and I suspect energy spent by Fred), the company was convinced that license-free implementation did not hurt their interests and they were willing to give it away on this specific instance. I'm not sure if you should attribute to hidden agendas what you can explain by doing the right thing (granted, very few companies do this which may make it suspect, but still..). That is my interpretation as well. It allows license free implementation, but not distribution of said implementation. This may be a fine point. When submitting the IPR notice, the IPR holder is asked whether it can be implemented without a license. No questions about redistribution are asked -- maybe nobody thought that asking that would be necessary if a positive answer is received on the first one. I'd guess that the owner that grants license-free implementation would also be fine with license-free (re-)distribution. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction
On Tue, 16 Oct 2007, Andrew McDonald wrote: For why you don't want to packets to be forwarded, consider a simple example that applies to something like RSVP: - packet hits router, identified as potentially interesting from router alert option - packet passed to user space, confirmed as really interesting and processed - create new packet (based on the one that came in and the RSVP processing you've done) and send it out You don't want the original packet you received to be forwarded, only your new packet. Router alert option on a hop-by-hop header means that every router on the path should process the option. You did not mention the rationale why the it would be reasonable for a packet that would otherwise be forwarded by the Linux router and expected to be processed by every router on the path to be re-created at every step, and every user-space application have to do that. In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear messages), the content of the RSVP packet is expected to be the same at every hop. Your argument might make sense in the case where the payload of the packet carrying router-alert option is expected to change at every hop. I believe that's not the intent of any router alert options that I'm aware of. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction
Took off linux-man from cc:, On Sun, 14 Oct 2007, Andrew McDonald wrote: +The tapped packets are not forwarded by the kernel, it is the +user's responsibility to send them out again. This is probably incompliant (and from users' perspective, unacceptible) behaviour that IMHO should be fixed. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zd1211rw and mac80211: multicast/v6 doesn't work in 2.6.21.5
FWIW, multicast/v6 is still broken on zd1211rw on 2.6.22.1 based Fedora 7 kernel (2.6.22.1-33.fc7). On Thu, 28 Jun 2007, Pekka Savola wrote: On Fedora 7 (kernel 2.6.21-1.3228.fc7, based on 2.6.21.5), my zd1211rw_mac80211 WLAN USB stick and multicast/v6 no longer works. On Fedora 6 (kernel 2.6.20, no mac80211) it was OK. I get wlan0: duplicate address detected! on dmesg when the kernel is trying to autoconfigure a global address. I suppose this is caused by the IPv6 stack seeing my own ICMPv6 neighbor solicitation and thinking it was originated by someone else: 08:46:21.762807 00:02:72:5b:dc:28 33:33:ff:5b:dc:28, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header: ICMPv6 (58), length: 24) :: ff02::1:ff5b:dc28: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:708:10:90:202:72ff:fe5b:dc28 Strangely, the same error isn't printed with the link-local address which uses the same EUI-64. z1211rw Wiki seems to imply that this might be an issue in generic mac80211 code: http://www.linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues It'd be nice to get this fixed. Or has it already been? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
zd1211rw and mac80211: multicast/v6 doesn't work in 2.6.21.5
Hi, On Fedora 7 (kernel 2.6.21-1.3228.fc7, based on 2.6.21.5), my zd1211rw_mac80211 WLAN USB stick and multicast/v6 no longer works. On Fedora 6 (kernel 2.6.20, no mac80211) it was OK. I get wlan0: duplicate address detected! on dmesg when the kernel is trying to autoconfigure a global address. I suppose this is caused by the IPv6 stack seeing my own ICMPv6 neighbor solicitation and thinking it was originated by someone else: 08:46:21.762807 00:02:72:5b:dc:28 33:33:ff:5b:dc:28, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header: ICMPv6 (58), length: 24) :: ff02::1:ff5b:dc28: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:708:10:90:202:72ff:fe5b:dc28 Strangely, the same error isn't printed with the link-local address which uses the same EUI-64. z1211rw Wiki seems to imply that this might be an issue in generic mac80211 code: http://www.linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues It'd be nice to get this fixed. Or has it already been? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20.3-rc1 / iproute2 hoplimit 2^32-1 vs 2^8-1
On Mon, 19 Mar 2007, David Miller wrote: From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 19 Mar 2007 16:27:29 +0100 Mhh actually this looks intentional: icmpv6_send and some other output functions do: int hlimit; ... if (hlimit 0) hlimit = dst_metric(dst, RTAX_HOPLIMIT); if (hlimit 0) hlimit = ipv6_get_hoplimit(dst-dev); Yep, negative value has a specific meaning. Which seems to indicate that the kernel-internal implementation has a need to store a negative TTL. Reporting it to the userspace as a negative doesn't seem right though? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.20.3-rc1 / iproute2 hoplimit 2^32-1 vs 2^8-1
Hi, On kernel based on 2.6.20.3-rc1 (FC6), 'ip -6 r l' shows: default via fe80::212:f0ff:fe5f:c4ec dev eth1 proto kernel metric 1024 expires 7191sec mtu 1500 advmss 1440 hoplimit 4294967295 (this is the same with iproute2-ss061214 and iproute2-ss070313.) So, it seems that the data length for hoplimit is not quite right, or it's reported as 2^32-1 instead of 2^8-1... -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARP notify option
On Tue, 6 Mar 2007, Chris Friesen wrote: Stephen Hemminger wrote: +arp_notify - BOOLEAN + Define mode for notification of address and device changes. + 0 - (default): do nothing + 1 - Generate gratuitous arp replies when device is brought up + or hardware address changes. Did you consider using gratuitous arp requests instead? I remember reading about some hardware that updated its arp cache on gratuitous requests but not gratuitous replies. You might be interested in taking a look at: http://tools.ietf.org/id/draft-cheshire-ipv4-acd There has been some follow-up discussion on this in the thread starting at: http://www1.ietf.org/mail-archive/web/int-area/current/msg00611.html In particular, you may be interested in this comment about ARP request and ARP reply for gratuitous ARP: http://www1.ietf.org/mail-archive/web/int-area/current/msg00669.html -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Arp announce (for Xen)
On Thu, 1 Mar 2007, Stephen Hemminger wrote: What about implementing the unused arp_announce flag on the inetdevice? Something like the following. Totally untested... Looks like it either was there (and got removed) or was planned but never implemented. If something like this goes in, it wouldn't hurt to do similar with IPv6 (RFC2461 section 7.2.6). There are very popular hardware-based routers which refresh their NDP caches only every 24 hours or 20 minutes (depending on the software version). Sending unsolicited NAs would eliminate traffic blackholing. diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index e10794d..cefc339 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -1089,6 +1089,16 @@ static int inetdev_event(struct notifier } } ip_mc_up(in_dev); + /* fallthru */ + + case NETDEV_CHANGEADDR: + /* Send gratuitous ARP in case of address change or new device */ + if (IN_DEV_ARP_ANNOUNCE(in_dev)) + arp_send(ARPOP_REQUEST, ETH_P_ARP, +in_dev-ifa_list-ifa_address, dev, +in_dev-ifa_list-ifa_address, NULL, +dev-dev_addr, NULL); + break; case NETDEV_DOWN: ip_mc_down(in_dev); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7817] New: commit edfe21a29b1dca9ce5a938317868066d2e21c385 breaks IPv6 address autoconfiguration
On Sat, 13 Jan 2007, Andrew Morton wrote: On Sat, 13 Jan 2007 05:44:39 -0800 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7817 Summary: commit edfe21a29b1dca9ce5a938317868066d2e21c385 breaks IPv6 address autoconfiguration Kernel Version: 2.6.19.2 Status: NEW Severity: high Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.19.1 Distribution: Debian Testing Hardware Environment: About 100 different x86 boxes Software Environment: no special software involved, just the kernel. No modules are loaded on the affected machines (everything needed is built into the kernel) I got hit by this as well. 2.6.20rc4-git4 is also affected. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ND unsolicited NAs when address is added?
Hi, RFC2461 specifies in section 7.2.6 that a host may send unsolicited NA(s) for example when its link layer address changes or IP address is added to inform the neighbors that their ND cache may need to be updated. Some current routers (probably) erroneously depend on this to reduce the downtime if an IP address is moved from one host to another (otherwise they'll continue to forward packets to the old link-layer address until their ND cache timeouts). I tested this behaviour on Linux 2.6.18 and FreeBSD 6.2 and neither sends these unsolicited NAs when an IP address is configured. Is there a reason not to add this optimization? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
radvd 1.0 released
Hi, A new version of radvd has been released. There hasn't been any very major changes, just regular maintenance and a one new experimental feature (RDNSS option). Get it at: http://www.litech.org/radvd/ Changes since 0.9.1: * Fix AdvDefaultLifetime initalization, broken in 0.9.1. * Fix STDERR+syslog logging, don't try STDERR after forking. * Implement RDNSS draft with (non-allocated) ND type code 25. * Redefined IgnoreIfMissing: failed interfaces are now reinitialized by default. IgnoreIfMissing only omits warnings about these. * Unblock SIGALRM at startup. * Implement MAX_INITIAL_RTR_ADVERT_INTERVAL handling. * Perform some dynamic/static code audit, fix some minor bugs and do cleanup as a result. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disable addrconf on ~multicast interfaces?
On Thu, 5 Oct 2006, Herbert Xu wrote: Are there any non-multicast interfaces that require addrconf? In other words, what does the following patch break :) Point-to-point (or NOARP) interfaces such as tunnels. I'm not sure what are the right flags to check.. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Advertise PPPoE MTU / avoid memory leak.
Speaking of PPPoE and MTU, does Linux support recently-published RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) On Sat, 23 Sep 2006, [EMAIL PROTECTED] wrote: PPPoE must advertise the underlying device's MTU via the ppp channel descriptor structure, as multilink functionality depends on it. __pppoe_xmit must free any skb it allocates if there is an error submitting the skb downstream. Signed-off-by: Michal Ostrowski [EMAIL PROTECTED] --- drivers/net/pppoe.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c index 475dc93..b4dc516 100644 --- a/drivers/net/pppoe.c +++ b/drivers/net/pppoe.c @@ -600,6 +600,7 @@ static int pppoe_connect(struct socket * po-chan.hdrlen = (sizeof(struct pppoe_hdr) + dev-hard_header_len); + po-chan.mtu = dev-mtu - sizeof(struct pppoe_hdr); po-chan.private = sk; po-chan.ops = pppoe_chan_ops; @@ -831,7 +832,7 @@ static int __pppoe_xmit(struct sock *sk, struct pppoe_hdr *ph; int headroom = skb_headroom(skb); int data_len = skb-len; - struct sk_buff *skb2; + struct sk_buff *skb2 = NULL; if (sock_flag(sk, SOCK_DEAD) || !(sk-sk_state PPPOX_CONNECTED)) goto abort; @@ -887,6 +888,8 @@ static int __pppoe_xmit(struct sock *sk, return 1; abort: + if (skb2) + kfree_skb(skb2); return 0; } -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Suspend/Resume: IPv6 default route gets lost
Hello, I'm using FC5 w/ 2.6.17-1.2174_FC5. When the laptop resumes from suspend, it does not re-send an IPv6 route solicitation. So, if the IPv6 default route expired while you were in suspend, you'll have to wait for the next multicast unsolicited RA. A workaround is to cycle the interface at ACPI resume scripts. Maybe triggering a RS is a missing feature in suspend/resume kernel functionality? There has also been discussion (years ago) about user-space interface to triggering a RS, but AFAIK, none exists right now. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, 29 Aug 2006, David Miller wrote: From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST) Further analysis is needed, but one idea is to skip addrconf_dev_config() if !(dev-flags IFF_MULTICAST). Yes, it is logical because without multicast IPV6 cannot work correctly. But from another perspective (I assume these bridged Xen devices use ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared IFF_MULTICAST flag seems potentially problematic. How many other things break over such a device? It's not obvious that IFF_MULTICAST is good enough. IMHO, you should be able to run addrconf on non-multicast interfaces as well (e.g., point-to-point interfaces, tunnels in particular). It seems that current code already excludes IFF_NOARP interfaces though. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
On Wed, 24 May 2006, Phil Dibowitz wrote: On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote: I disagree that we should bother about clearing statistics. It always adds more complication than necessary. Few (if any) other statistics in Linux permit easy clearing, often because adding operations other than 'increment' or 'read' requires adding expensive spinlocks or atomic operations. Every networking device in the world supports clearing interface statistics. Why should linux not be able to do the most basic operation on any cisco/juniper/enterasys/whatever managed switch or router? AFAIK, note that clearing interface statistics on such routers doesn't clear SNMP statistics, just the statistics available through CLI. So you really have two levels of statistics, and I suspect clearing slave statistics shouldn't be too difficult to implement. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
On Mon, 15 May 2006, Meelis Roos wrote: On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to 6to4 tunnel (the default route). It worked with fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel). ... vaarikas:~# ip -6 route 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 You're using the wrong prefix length. The right one is /16. Does that work? Maybe the 6to4 hack which didn't heed routing table (so either prefix length was OK) was removed or changed... -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radvd 0.9.1 released
On Sat, 14 Jan 2006, Jeff Garzik wrote: A new version of radvd has been released. There hasn't been any major changes, just regular maintenance and a one new feature (jumboframe support). If it's in maintenance mode, why not call it version 1.0? Perhaps the next version shall be :) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
radvd 0.9.1 released
Hi, A new version of radvd has been released. There hasn't been any major changes, just regular maintenance and a one new feature (jumboframe support). Get it at: http://www.litech.org/radvd/ There have been the following changes since 0.8: * Clean up signed/unsigned values, add more warnings to CFLAGS * Fix a couple of IPv6 Ready Logo Phase-2 IPv6 Core Protocols Self Test issues * Create a short FAQ in README file, other minor documentation updates * Get interface MTU automatically, so that you can use jumboframes and advertise MTU 1500 -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel's behavior with unknown SPI values in ESP/AH packets...
On Thu, 8 Dec 2005, Stjepan Gros wrote: I have a problem with kernel's behavior when receiving ESP/AH packets with unknown SPI values. As it turns out, when such a packet arrives, kernel simply discards it. The consequence is that in some tests first packet is lost. For example, trying to ping other side the 0th packet will be sent, but all the others will go alright. In other words, there is basically a race between ICMP packet coming to machine, and IKE daemon on that machine that is installing SAs. Am I right? Can anything be done about it? Page 59 of http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-06.txt says: 3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. For unicast traffic, use only the SPI (or SPI plus protocol). For multicast traffic, use the SPI plus the destination or SPI plus destination and source addresses, as specified in section 4.1. In either case (unicast or multicast), if there is no match, discard the traffic. This is an auditable event. The audit log entry for this event SHOULD include the current date/time, SPI, source and destination of the packet, IPsec protocol, and any other selector values of the packet that are available. If the packet is found in the SAD, process it accordingly (see step 4). .. so it seems to me that packets with unknown SPI values should be thrown away? So, it seems that what you're looking for is support for opportunistic encryption; see section 3.1 of draft-richardson-ipsec-opportunistic-17.txt I'm not sure if Linux kernel purports to do that. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ip / ifconfig redesign
On Fri, 2 Dec 2005, Al Boldi wrote: Consider this new approach for better address management: 1. Allow the definition of an address pool 2. Relate links to addresses 3. Implement to make things backward-compatible. The obvious benefit here, would be the transparent ability for apps to bind to addresses, regardless of the link existence. That's called 'the loopback address', right? :) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
fedora-netdev.1 IPv6 freeze [Re: [ANNOUNCE] fedora-netdev kernel repository]
On Mon, 14 Nov 2005, John W. Linville wrote: http://people.redhat.com/linville/kernels/fedora-netdev/ I guess the test can be termed a 'success' because after updating from 2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 100% reproducible kernel hang (everything just freezes as it is, no message to /var/log/messages or anywhere) after I run '/sbin/ip -6 r l' or try to use IPv6 in basically any other way on my ThinkPad laptop with external orinoco_cs WLAN card. Any thoughts for the next steps? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
