Re: [RFC] [PATCH 1/3] adds iso3166-1 support
On Mon, 23 Oct 2006 18:45:23 -0400, Luis R. Rodriguez wrote: iso3166-1 ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names of countries and dependent areas. It was first published in 1974 by the International Organization for Standardization (ISO) and defines three different codes for each area: [snip] + r |= iso3166_1_add(887, YE, YEM, + Yemen); + r |= iso3166_1_add(891, CS, SCG, + Serbia and Montenegro); + r |= iso3166_1_add(894, ZM, ZMB, + Zambia); According to the ISO, at: http://www.iso.org/iso/en/commcentre/pressreleases/2006/Ref1031.html and http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlv12-div.html Serbia and Montenegro have been allocated new codes, RS and ME respectively. Is this ISO3166 stuff supposed to track the standard? If so, what happens when a country splits or two join together? Will that require lock-step updates to user-space, or will it be insulated byt this changes? Regards, Anand - 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] [PATCH 2/3] adds ieee80211_regdomains support
On Mon, 23 Oct 2006 18:47:25 -0400, Luis R. Rodriguez wrote:
ieee80211_regdomains
Breaks down regulatory domains into data structures which allow
drivers to share channel and power contraints based on stack
regulatory domain. This driver adds in-kernel support for common
regulatory domains (such as FCC and ETSI), makes updating the
[snip]
+/* Stack regulatory domain values. Atheros seems to have started this
+ * convention and most hardware vendors followed their example.
+ * Although these are *very* common we allow for a hw-specific
+ * map between stack and device regdomain values. */
+enum stack_regdomain {
+ REGDOMAIN_WORLD = 0x00, /* World compliance, minimum set */
+ REGDOMAIN_FCC = 0x10, /* USA */
+ REGDOMAIN_IC= 0x20, /* Canada */
+ REGDOMAIN_ETSI = 0x30, /* Europe */
+ REGDOMAIN_SPAIN = 0x31, /* Spain */
+ REGDOMAIN_FRANCE= 0x32, /* France */
+ REGDOMAIN_MKK = 0x40, /* Japan */
+};
+
Why not pick either the country name or the organisation within the country
that determines the frequency guidelines?
Regards,
Anand
-
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: OLPC (One Laptop Per Child) Developer's program.
On Sat, 03 Jun 2006 12:49:05 +0100, David Woodhouse wrote: On Tue, 2006-05-30 at 17:42 -0400, Jim Gettys wrote: As you know, we've said we were going to have a developer's program. You can find more information, including how to apply for boards at: http://wiki.laptop.org/index.php/Developers_Program Note that these are bare PC prototype boards, not packaged machines. Jim Gettys ObNetdev: One thing we really need is NAT-PT or an equivalent for allowing access to the Legacy Internet from IPv6-only hosts. As soon as I finish playing with JFFS2 improvements, I plan to start looking at that. Wouldn't miredo mostly fit the bill? It won't get through Symmetric NATs (by design) but those are supposed to be uncommon. Cheers, Anand - 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: RFC3927 ARP patch status?
On Fri, Jun 02, 2006 at 09:36:54AM -0700, David Daney wrote: Anand Kumria wrote: Hi David, Do you know the status of your RFC3927 ARP patch? Is it likely to make it into a mainline kernel? That would be up to the kernel network maintainers. There were some discussions about whether it made sense for the kernel to support the behavior required by the RFC. Other comments debated the Hmm, well the behaviour at the moment is certainly suboptimal. Any compliant RFC3927 implementation has to generate an additional broadcast ARP -- the kernel will send a directed response, which isn't enough. The patch is there. I signed-off-by on it. If you need RFC3927 compliance, you are free to apply the patch. If the network maintainers are so inclined, they can do the necessary things to get it into the mainline. Okay, thanks. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- - 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: RFC3927 ARP patch status?
Herbert, On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote: David Daney [EMAIL PROTECTED] wrote: There were some discussions about whether it made sense for the kernel to support the behavior required by the RFC. Other comments debated the wisdom of using a tightly targeted patch specific to the RFC, or whether a more general but intrusive solution would be better. I think we've made it quite clear what needs to be done for it to be accepted. All that remains is for someone to implement it. If anyone really cares about this, then please write the code instead of talking about it. Okay, to confirm: you want a patch which looks at the scope value and if the scope is link-local then we broadcast rather than do a directed ARP? One I have where IPv6 encodes what address mask is link-local, I'd like to follow the same style as. Should the kernel also set the scope on IPv4 addresses like it does for IPv6 ones? Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- - 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: RFC3927 ARP patch status?
On Fri, Jun 02, 2006 at 05:58:27PM -0700, David Daney wrote: Anand Kumria wrote: Herbert, On Sat, Jun 03, 2006 at 09:12:06AM +1000, Herbert Xu wrote: David Daney [EMAIL PROTECTED] wrote: There were some discussions about whether it made sense for the kernel to support the behavior required by the RFC. Other comments debated the wisdom of using a tightly targeted patch specific to the RFC, or whether a more general but intrusive solution would be better. I think we've made it quite clear what needs to be done for it to be accepted. All that remains is for someone to implement it. If anyone really cares about this, then please write the code instead of talking about it. Okay, to confirm: you want a patch which looks at the scope value and if the scope is link-local then we broadcast rather than do a directed ARP? I don't think that was the plan. In an earlier e-mail Herbert Xu said (and I concur): -- I like the idea of allowing user-space to control what addresses cause broadcasts. However, I'm uncomfortable with overloading existing flags even though they might appear to fit the bill on the face of it. [...] Sorry, I can't find any email with any of those words in it by Herbert. Could you tell me the message-id, so I can read some of the surrounding context? The idea was to add a new flag, *not* reuse the scope value. I guess it would be something set during RTM_NEWADDR (and returned by RTM_GETADDR?). How does IFA_DIRECTEDARP sound? With a value type of int; defaulting to 1. When set to 0, generate a broadcast ARP for the address. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- - 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
link-local address via ifconfig
Hi, There are plenty of people who still use ifconfig to list the addresses assigned to their network interfaces (I know, ifconfig is broken) and who then parse the output. However the kernel puts link-local scoped address first if the address list of an interface, so an interface like: eve:[~]% ip addr show wlan0 3: wlan0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:12:f0:03:d9:e7 brd ff:ff:ff:ff:ff:ff inet 169.254.182.108/16 brd 169.254.255.255 scope link wlan0 inet 192.168.2.2/24 brd 192.168.2.255 scope global wlan0 inet6 fe80::212:f0ff:fe03:d9e7/64 scope link valid_lft forever preferred_lft forever appears as: eve:[~]% ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:12:F0:03:D9:E7 inet addr:169.254.182.108 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::212:f0ff:fe03:d9e7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 [... elided ...] Is there any reason to put the link-local address first in the list? I've had a number of bugreports (or outright panic attacks) where the problem turned out to be that ifconfig was reporting the link-local address first, rather than the global/site one. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- - 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] net: Broadcast ARP packets on link local addresses
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 most of the protocol (zcip, busybox, ...). The kernel's APR driver should function in the normal manner except that it is required to broadcast all ARP packets that it originates in the link local address space (169.254.0.0/16). RFC 3927 section 2.5 explains the requirement. The current ARP code is non-compliant because it does not broadcast some ARP packets as required by RFC 3927. I haven't seem anyone comment on this, but it would be useful to see this integrated. If you have a bunch of Linux machines and two machines have the same address allocated (not so impossible) they won't notice until they start communicating with each other. A third machine attempting to communicate with either party won't be able to do so. With this patch in place, overlapping assignments are noticed much faster due to the broadcast. Something else I've noticed while I've been implementing my zeroconf daemon is that the kernel returns link-scoped primary addresses first to 'ifconfig'. Unfortunately quite a lot of user-space programs parse its output and interpret the address it presents as the primary for the specified interface. Is that a case of user-space breakage that the kernel team would ordinarily worry about? Thanks, Anand - 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: receiving ARP packets
Hi Rick, On Mon, Mar 20, 2006 at 10:27:07AM -0800, Rick Jones wrote: Anand Kumria wrote: Hi, I'm writing a program which receives ARP packets and have noticed that broadcast ARP packets seem to come in with the destination hardware address set as all zeros. long, Long, LONG ago, all-zeros was considered broadcast. however, long, Long ago, that was switched to all-ones, but all-zeros was grandfathered in this day and age (heck even a decade ago) it is my understanding that nothing should be continuing to send broadcast as all-zeros. Natually as soon as I sent this email, I figured it out (in fact I thought I had caught the email before it was sent out. sigh.). In the ARP packet itself, when a query goes out the requested hardware address is set to all zeros -- according to the RFC this is so (old-style) equipment can just sway the source/target portions of the packet, whack in their hardware address change the type and send it on their merry way. Anyway, thanks for answering; learning is always fun. Just not so publically :-/ Cheers, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- - 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
