Package: samba-common Version: 2:3.4.8~dfsg-2 Severity: wishlist Dear samba-maintainers,
I'd like to give some background information before I explain my actual request: My wife has a computer running Windows XP and mine is running Debian, obviously (but it is not the computer I am writing this actual bug report from). Both computers are connected via LAN to a router which in turn acts as DHCP server and internet gateway. Both computers receive dynamic IP addresses via the router's DHCP service. For quite some time now, nautilus on my computer is not able to show shares on my wife's coputer anymore. It complains with the "Failed to retrieve share list from server" gvfs error message. The error only occurs if I try to connect to the computer via its name, if I try to explicitely connect to its IP address, it works. The reason for this behaviour is quite simple, but hard to find: Samba on my computer uses the standard name resolv order, which is: "lmhosts host wins bcast". Since I do not have a lmhosts file, it tries the next best method which is "hosts". This in turn is configured via /etc/nsswitch.conf to first look into the /etc/hosts file (where it does not find my wife's computer, since it is configured via DHCP and thus has a dynamic IP address) and then do a DNS query. Our router forwards this DNS query to our ISP's DNS server, which - now comes the important part - instead of returning a failure notice, because it does not know how to resolv my wife's computer's name, leads us to some dubious webpage which contains advertisments and "suggestions" to use some notorious internet search engines on the requested name. Of course, when our ISP's DNS server resolvs this request and returns the IP address of this dubious webpage, nautilus will not find any shares on this computer. Since for samba, the "host" method obviously succeeded, it does not try further attempts with the "wins" or "bcast" methods and my request for the computer's share list is doomed to fail. Please don't get me wrong, I know this is absolutely not samba's but our ISP's fault. But by internet research I found quite a lot of people with similar problems and would thus like to propose a general resolution for this problem. This solution would be to put "bcast" before "host" in the name resolv order list and only have the latter as a fallback, i.e. "lmhost bcast host wins". I believe this is safe, because "lmhost" should always be the first method. "bcast" is error prone, because it depends on the target host being on a locally connected subnet. On the other hand, if the target host is *not* in the locally connected subnet, AFAICT it would need an entry in one of the lmhost or host files anyway. I am not quite sure about "wins", though, i.e. if it should be queried before or after "host". But, to sum up, "bcast" should come before "host". I do not know upstream's opinion on this, i.e. if this would be considered a Debian-specific deviation, but at least in the smb.conf(5) manpage I found my proposed name resolv order among the examples. However, please consider changing this setting for the sake of users with heterogenous networks and stupid ISPs. ;) Cheers, - Fabian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (501, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages samba-common depends on: ii cdebconf [debconf-2.0] 0.150 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.33 Debian configuration management sy ii ucf 3.0025 Update Configuration File: preserv Versions of packages samba-common recommends: ii samba-common-bin 2:3.4.8~dfsg-2 common files used by both the Samb samba-common suggests no packages. -- debconf information: * samba-common/encrypt_passwords: true * samba-common/dhcp: true * samba-common/workgroup: WORKGROUP samba-common/do_debconf: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
