I am running Slackware 9.1, Samba 3.0.5. I have 3 Windows 2000 machines, an NT4 machine and a Windows ME machine along with my Linux box on the same network. (192.168.1.0)

The Windows ME machine can see all the Windows 2K and the NT machine, but it cannot see the Samba shares on Linux. It responds with "The machine you want is not on the network". I can ping, telnet and browse from Windows ME to the Linux box, so the networks okay.

I used Ethereal on the Linux box to see the packets and see the WinME machine sending NBNS packets and getting no response. When I hit the Linux box from other machines, I get different packet types.

There must be some configuration issue that I've missed here. This configuration was working for almost 3 years using Samba 2.x. Since I upgraded a week ago, I've been hosed.

Any help would be appreciated.

Thanks

Can you access the server via it's ip? - eg:
\\192.168.1.1\

No, that fails as well on the WinME machine. All other machines work fine. I'm stumped.

It does seem a bit odd.

Have you tried using "net use" or "net view" from a dos box?
net use s: \\ip.of.server.here\share

Yes, I did try that and still no joy.

I just re-ran the ethereal session to get more detail. WinME is 192.168.1.11, linux2 is 192.168.1.1 and the network is 255.255.255.0. On WinME I used the command:

net use q: \\linux2\www

In Ethereal, I see 4 NBNS UDP packets src=192.168.1.11, dest=192.168.1.255. No response is forthcoming from 'linux2'. It's almost like Samba is not configured to listen to that protocol. This is controlled via 'lanman auth', correct? lanman auth=yes in my configuration.

Do you hace any firewall running on linux:
iptables -nL

Make sure that you have netbios over tcp set in your Win ME network settings.

Thanks, David, for your responses and thoughts.

I am running iptables and block the various microsoft- services, but only on ppp0. I used 'nmblookup' just to make sure I could get port 137, then ran a couple of other tests that might shed some light. Below is my test and the results

$ nmblookup server1
Querying 192.168.1.255 for server1
name_query failed to find name server1

$ nmblookup -A 192.168.1.1
Looking up status at 192.168.1.1
server1 <00> B <ACTIVE>
server1 <03> B <ACTIVE>
server1 <20> B <ACTIVE>
winDomain <00> <GROUP> B <ACTIVE>
winDomain <1E> <GROUP> B <ACTIVE>

My host interfaces string was 192.168.1.1/24. I tried 192.168.1.255/255.255.255.0, which should also work and be the same thing, but it also failed.

I believe this shows I'm getting to port 137 successfully, but server1 is not responding to broadcast requests for the NetBIOS name.

Question: On NT, XP and Win2K I can do \\192.168.1.1\www to get to my share. I thought you could do this on Windows ME. If I watch ethereal when doing 'net use p: \\192.168.1.1\www' on my WinME machine, I see no traffic whatsoever from the WinME machine.

There are two conflicting sets of information here. The nmblookup tests seem to indicate the problem is server1 not responding to NetBIOS Name Service requests. The second seems to indicate WinME isn't attempting to make contact using an IP address.

Also, I think I "mis-posted" earlier. I said I was running Slackware 9.1, but I am actually running 9.0. I am about to upgrade, which will probably ahve some impact on this problem.

Finally, one last bit of history. This configuration worked from December 2001 until about 2-3 weeks ago. I use Dropline Gnome and one day, ran dropline-installer. It suggested lots and lots of packages, including upgrading to Samba 3.0 from Samba 2.2. I went ahead with it and that's when the fun started.

Thanks for your help.

You're right that it is quite odd and I would concur that the evidence shows there are 2 likely to be 2 problems. However, we can dismiss the nmblookup problem slightly by using the IP address of the server when connecting from ME.

If there isn't any traffic leaving ME then the problem would seem to lie there - oddly though - it can see the xp and 2k systems. Are you sure there aren't any entries in hosts or lmhosts for server1 on the ME machine?

You may get more information as to why the nmblookup fails by increasing the debug level - ie:
nmblookup -d 10 server1