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 [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
