On Thu, 2008-03-06 at 01:45 +0100, Lennart Poettering wrote: > 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. Yeah, that's been my plan. DHCP on ad-hoc WLAN is by far the less common case. > 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. Right. Will look into this; though I still want to do some more poking around on both Mac OS X and Windows internet connection sharing to see what's going on. > 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. Ok; will look into it. > 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. Yeah; though the interfaces here are still somewhat in flux. I'd like it to settle down a bit more. Some cards are more easily able to do this than others too. I think it needs a bit more time before we start looking at it. Also, there's a nice, easy fallback: using a USB or cardbus card and sharing over that too. But it's something we should definitely try to take advantage of in the future. > > > 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? If we can, that might be good. How do we tell? Any idea what they look like in 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? Sort of; if you enable DHCP on an interface, DHCP will be done (and the connection will fail if DHCP times out) but you can still override many of the DHCP server returned attributes with your own, like a different DHCP server for example, or a different hostname, or whatever. > 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. Yeah; I'm thinking just "Link Local" for the moment. Shouldn't make a difference to the user (unless they really want to know) whether it's an IPv6 or IPv4 LL address. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
