Re: system-config-network & Zeroconf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux