Re: AW: Re: dnsmasq-base does work for connection sharing

[Dan Williams <dcbw redhat com>]

On Wed, 2009-03-11 at 13:36 +0000, netztier bluewin ch wrote:
> Hi all
> 
> >> On Tue, 2009-03-10 at 09:30 +0900, Jacobs Shannon wrote:
> >> > I now realize that I 
> >> > didn't do quite enough testing to pin it to the DNS, but 
> >> > I'll check with an external IP address the
> >> > next time I see it...
> 
> I ran into a DNS-related problem with dnsmasq (once i had discovered in syslog that NM complained about not finding 
> the dnsmasq binary, so I installed dnsmasq-base). It returned a REFUSED status code upon a client's query. Via Google I 
> found a post in the dnsmasq-discuss list that said:
> 
> | The only circumstance in which dnsmasq will generate a REFUSED reply is 
> | when it has no upstream server available to forward a query to, but it's 
> | worth bearing in mind that if dnsmasq _does_ forward the a query, then 
> | the upstream nameserver could also return a REFUSED reply, and dnsmasq 
> | would send that back to the original requester.
> 
> And then I realised what had happened: The client had obtained an IP address and issued a DNS request before my 
> mobile broadband connection was up and the sharing computer had learnt about the ISPs DNSs via PPP. So making sure that 
> the to-be-shared link is "up and running" before bringing up the sharing Ethernet or WLAN profile should help.
> 
> >Right now I'm mostly impressed with it, but I'm thinking about
> >experimenting with the wireless side of it for ad hoc wireless
> >networking to two of my machines instead of going through the hub.
> 
> Works. Define a new ad-hoc WLAN profile, set WEP parameters as needed.  Bring up the "upstream" link first, then 
> "Create new wireless network" from nm-applets menu and select your previously created ad-hoc profile. AFAIK, NM 
> currently has no built-in way to run a WLAN NIC in "master" mode to create an AccessPoint/Infrastructure network, so 
> we're stuck with ad-hoc for the time being.

That's because (a) drivers universally suck for master mode, and (b)
there's a hell of a lot more setup required for master mode than adhoc.
At the moment, I don't see a compelling reason to use master mode over
adhoc until drivers get better.  We certainly can't flip the switch
until most of the mac80211-based drivers get good AP mode support.
While some drivers do have OK AP-mode support, there question is, what
advantages does master mode bring, and if those are significant, how do
we let the user know what impact master vs. adhoc will have on their
day-to-day workflow?

Dan