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

2009-03-11 Thread netzt...@bluewin.ch
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.

regards

Marc

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


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

2009-03-11 Thread Dan Williams
On Wed, 2009-03-11 at 13:36 +, netzt...@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


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list