On Wed, 05.03.08 18:06, Dan Williams (dcbw@xxxxxxxxxx) wrote: > > be very useful for speeding up configuration in networks where most > > likely no dhcp is around, such as wlan ad-hoc, bluetooth pan, ethernet > > The problem is that some people want DHCP on their WLAN adhoc > networks... I still need to figure out how the Apple connection sharing > works; they use IPv4 LL addresses in the created Ad-Hoc network but I > don't know how other machines get the default route to the one sharing > its connection. Possibly the router announces itself with Avahi or > something. DHCP on Ad-Hoc is crazy. For those people needing it it is fine to allow them enable dhcp manually (as I proposed below). But the default should be no DHCP on ad-hoc. I don't have access to an Apple machine right now. But my (well educated) guess is that they just spit out their packets on the eth interfaces without directing them to a specific gateway. Translated to Linux that means they have a route like this: route add default dev eth0 instead of the usual: route add default gw 47.11.8.15 That basically causes those packets to be broadcasted to all people on the network. Then, every host that believes it can make use of those packets will route them on. More about those routes you can find out on: http://avahi.org/wiki/AvahiAutoipd#Routes http://developer.apple.com/qa/qa2004/qa1357.html It's a nice and simple solution I would say - trivial to set up on both the client and the gateway side. Not really scalable because it makes all packets broadcast packets, but that shouldn't matter much in small networks. And on larger networks people should have set up dhcp anyway - since ipv4ll isn't for big networks anyway. DNS is then probably configured via something similar to avahi-dnsconfd. It might be a good idea to implement what avahi-dnsconfd does directly in nm, and the server for it should be done in nm as well. If you are adding this network sharing thing to nm, will you also allow users to access multiple networks from a single wlan card? (afaik the devicescape wlan stack can do that?) i.e. it would be really great if just buy clicking a few buttons I could create an ad-hoc network for sharing the pay wlan I am using with my collegues without paying twice? That would kick ass. > > cross cable, usb-to-usb, ... Those ad-hoc networks are usually created > > The problem with some of these, especially cable-to-cable, is that you > can't distinguish it from a situation where you do want DHCP. Ie, you > cannot really distinguish between a crossover cable and a standard plug > into a switch. Same with WLAN ad-hoc. Yepp. I see the problem. For the cases where we don't know we should default to dhcp+ipv4ll. For those cases where we do know (bt pan, wlan ad-hoc) we should default to ipv4ll. And then, people should be able to switch to the other option manually, if they feel like it. BTW, maybe those usb-to-usb cables should be flagged as such via HAL? > > _ad hoc_ i.e. temporarily, and thus configuration should be quick. So > > it'd be best if nm wouldn't do dhcp in these situations to avoid the > > long timeout. i.e. what I am thinking is: besides "dhcp" and "static" > > configuration for network interfaces, allow a special "zeroconf" > > configuration option. For the aforementioned ad-hoc network types > > default to "zeroconf", for the others to "dhcp" -- and then, allow > > people to switch to the other mode if they are so crazy to have a wlan > > ad-hoc network with dhcp, or a wlan infrastracture network without. > > There does need to be more thought here; but I'm leaning towards > defaulting connections created when the user explicitly shares an > existing connection (ie, you pick "Share this mobile broadband card over > wireless") to zeroconf. In the end there will still be booleans in the > config to mark DHCP yes/no and zeroconf yes/no. I'm wondering if the > zeroconf option should be mutually exclusive with any of the others; ie > would you ever want to have a secondary IPv4 LL address at the same time > as you have a non-LL address. The only reason for having both ipv4ll and something other around is when you started a TCP connection when you only had ipv4ll but later gained a real address but don't want drop the TCP connection. hosts with only an ipv4ll address and hosts with no ipv4ll should be able to interact fine as long as they have the aforementioned routes set up properly. (hmm, some systems don't set these routes up, so maybe for these having both addresses around actually may make sense, dunno) Please note that avahi-autoipd refuses to assign an address to an interface that already has a valid address assigned, unless you pass --force-bind to it. So as I understood you will allow parallel configuration of one dhcp address and one or more static ones on a single interface? Interesting. I hope you label them they way I do with the avahi-autoipd address? One last thing: please don't use the word "zeroconf" in an UI element. It's too blurry. Most people if they say "zeroconf" mean Apple style zeroconf, but there also is MS style zeroconf. And then, some people say "zeroconf" when they mean only "ipv4ll" and others use it to refer to "mdns+dnssd". It's confusing. Use "IPv4LL Link-Local Addressing" or similar for your stuff. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
