netbios routing issue

[groovin]

theres a server across the town (server1 @192.168.1.101) on subnet 192.168.1.x. Its linux, running samba as a file server. all the computers on that subnet can access it without any problems. they can see it in network 'hood and access the shares. they are connected to another network via VPN. this other network is on subnet 192.168.2.x. Computers on 2.x can see server1 in 'hood but cannot browse its share. They get the error "\\server1 is not accessible. Network path is not found". Comps on 2.x can go run > \\192.168.1.101 and access the shares that way.

2.x comps can access other computers on 1.x via 'hood but not this server. so basically, its not resolving to a name.

Heres a tcpdump:
-------------------------------------
10:38:15.720000 192.168.2.175.1360 > server1.ourdomain.com.microsoft-ds: S 2244697666:2244692366(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
10:38:15.720000 server1.ourdomain.com.microsoft-ds > 192.168.2.175.1360: R 0:0(0) ack 2244692367 win 0 (DF)
10:38:15.720000 192.168.2.175.1361 > server1.ourdomain.com.netbios-ssn: S 2344732415:2344732415(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
10:38:15.720000 server1.ourdomain.com.netbios-ssn > 192.168.2.175.1361: S 3651970433:3651970433(0) ack 2244732416 win 5840 <mss 1460,nop,nop,sackOK> (DF)
-------------------------------------

There is no IP from server1 sent back. I dont think there should be a problem with them being on 2 different subnets since netbios sits on tcpip and tcpip seems to be working.

Some other random pieces of info...

I can ping server1's IP and unix hostname, but not by the samba netbios name. There are no firewalls running on this server. it is running samba 2.07.

Any ideas? thanks

 

[cleverhandle]

Cross-subnet browsing is a horrible, fugly mess due to the way browse lists are synced between subnets. Do you have a WINS server (either a real Windows one, or a Samba one), and clients configured to use it? You should, if you're crossing subnets. Also, what kind of networks are dealing with - one domain, two domains, or workgroups?

 

[groovin]

Yes, there is a WINS server running. Can the browse list be manually updated?

Its a single domain network, mostly 2k and xp clients with NT and Linux servers. On paper, its not very complex.

 

[cleverhandle]

I originally wrote the stuff below, but I need to clarify something first. Is the only problem that clients in Subnet B cannot access the Samba machine in Subnet A via browsing? All other network browsing and sharing works fine on all other machines? If so, that points to a more limited name resolution issue than what I originally assumed below. Probably that the Samba machine isn't configured to register with the WINS server. Bump up the debug level and check the nmbd logs to find out. If the problems are more than that, read on...

Originally posted by: groovin
Yes, there is a WINS server running. Can the browse list be manually updated?

nbtstat -R (maybe -RR?) will reregister a (Windows) client's name with the WINS server. I don't think there's any way to manually sync one machine's browse list with another, but I'm far from an expert in this area. Is that WINS server specified in smb.conf on the Samba server? Could you post the browsing section of smb.conf? My first guess would be that either the samba box isn't set to use the WINS server, or that it's Master level (Local/Domain) is conflicting with another box on the network.

Its a single domain network, mostly 2k and xp clients with NT and Linux servers. On paper, its not very complex.

Yeah, sadly it doesn't need to look very complex for this to be a PITA. Could you post more details about the locations of the machines with regard to the subnets? Where's the PDC and what OS? Where is the WINS server? The Samba server? I know that sounds like it should be trivial, but it isn't. If you haven't already, you might check out this page from the Samba docs. That version is for Samba 3, but the concepts haven't changed much since then. This page from MS may also be helpful.

 

[groovin]

as i sift through my log files... here a part of the conf.

[global]
workgroup = ourdomain
netbios name = server1
server string = server1
security = DOMAIN
encrypt passwords = Yes
password server = NTserver, anotherNTserver
log level = 3
log file = /var/log/samba/%m.log
name resolve order = wins bcast
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
preferred master = False
domain master = False
dns proxy = No
wins server = 192.168.2.82
remote announce = 192.168.2.255/OURDOMAIN 192.168.3.255/OURDOMAIN
printer admin = +admins
printing = lprng

the PDC is winNT4 i believe, the wins server is samba at 2.82. all the servers are at 2.x, only server1 is at 1.x.

 

[cleverhandle]

Again, could you clarify that bit about the extent of the problem? Name resolution is related to, but distinct from, browsing. If all the machines show up in the browse lists, but just that one machine gives the error, that means you're almost there. If the browse lists are wrong or incomplete, then it's a whole different can of worms.

Originally posted by: groovin
wins server = 192.168.2.82
remote announce = 192.168.2.255/OURDOMAIN 192.168.3.255/OURDOMAIN

You shouldn't need remote announce. Just the wins server line should be enough, even cross-subnet. The remote stuff is for very unusual situations.

the PDC is winNT4 i believe, the wins server is samba at 2.82. all the servers are at 2.x, only server1 is at 1.x.

I don't know much about the differences between 1.x and 2.x Samba. That may be an issue. But the fact that the WINS server is Samba is a good thing - that means you get good error messages. Bump the debug level on the WINS server and restart nmbd on server1 - you should see the name registration for server1 in the WINS server's logs.

 

[groovin]

sorry forgot to answer the first part of your post to clarify it a bit...

from the 'hood, i am able to connect to all machines on that subnet except server1. That seems to be the only problem. communication between server1 and the machines on the same subnet seem to work fine too. server1 has name problems with the 2.x subnet.

what debug level should i set the WINS server to? i think its set to 3 right now. the logs i looked at didnt tell me very much so your idea of a more verbose log sounds great.

by the way, thanks for all your help!

 

[cleverhandle]

Originally posted by: groovin
from the 'hood, i am able to connect to all machines on that subnet except server1. That seems to be the only problem. communication between server1 and the machines on the same subnet seem to work fine too. server1 has name problems with the 2.x subnet.

I'm going to guess that server1 and the WINS server are on different subnets? Correct? And server1 sees the clients in the 2.x subnet in the NN, but can't connect to them in the same way they can't connect to it?

what debug level should i set the WINS server to? i think its set to 3 right now. the logs i looked at didnt tell me very much so your idea of a more verbose log sounds great.

Probably 5 to 7 should work, but I haven't had to debug a Samba setup in a while. I do remember that trying to find anything in the logs at that level is extremely tedious, due to the reams of information you get. It's also irritating that you get so many different log files - I think what you're looking for will be in one of the nmbd logs. Be sure to HUP or restart Samba on the WINS server to make sure the new log level takes effect. To give yourself an idea of what you're looking for, you may want to run that nbtstat command on a Windows client, since you should definitely see evidence of that in the WINS server. Then restart server1 and see if you get the same thing.

edit: typo

 

[groovin]

>>I'm going to guess that server1 and the WINS server are on different subnets? Correct? And server1 sees the clients in the 2.x subnet in the NN, but can't connect to them in the same way they can't connect to it?<<

correct.

 

[cleverhandle]

OK, here's a bit of background on what's happening. You can find this info scattered sporadically around the Net, but as usual the best way to understand Windows file sharing/browsing is to read the Samba docs. You've got two distinct subsystems - name resolution and browse lists.

Name resolution (via WINS) is pretty simple, at least for our purposes. Think of WINS as a dumb, insecure dynamic DNS service. You specify its IP address to clients, and they register their NetBIOS name with it when they boot up. So, even though it keeps track of NetBIOS names, it operates directly over IP like DNS. That's pretty much it, though the precise details of how names are handled gets very ugly. It doesn't really know anything about Network Neighborhood and browsing.

Browsing is a lot more convoluted due to backward compatibility hacks. In a cross-subnet setup, the idea is to create browse lists of NetBIOS names and sync them at a central location. Those browse lists don't contain TCP/IP info - just NetBIOS names. The browsing subsystem doesn't know about WINS (this is a small untruth, but close) - it takes no responsibility at all for name resolution. So how does the syncing work? Well, each subnet has a Local Browse Master that collects the NetBIOS names from broadcasts and creates a browse list with them. When a client wants to browse, it asks the Local Master for the browse list and resolves the NetBIOS names according to whatever name resolution has been configured. But Local Masters only operate on a single subnet, so there is also a Domain Master, which is usually but not necessarily the domain's PDC. Local Masters communicate with the Domain Master to get all their lists in sync. Clients, however, do not use the Domain Master directly.

What does this have to do with you? Well, you've got Subnet 1.x with the Samba server (server1) and Subnet 2.x with the WINS server. You start up all the machines in 2.x - they all register name-->address mappings with the WINS server and add their names to the 2.x Local Master's browse list. Then you start up the 1.x machines - all of them except server1 (I'm fairly sure at this point) register their name-->address mapping with the WINS server (in 2.x) and all of them, including server1, add their names to the 1.x Local Master's browse list (not using WINS, just via broadcasts). Shortly thereafter, one of the Local Masters (likely the PDC, wherever it is) becomes Domain Master and syncs the two lists.

So a client on 2.x goes to browse. It finds server1 in the Local Master's browse list and tries to connect, but there's no name-->address mapping in WINS, so it fails with the "path not found" error. What about a 1.x client? It also sees server1 in the browse list, tries to find a WINS entry, and fails. BUT, it falls back to resolving the name via broadcast and finds server1 that way. So 1.x clients work even though WINS resolution is not complete.

So I'm 99% sure that server1 is not registering with the WINS server - that makes all the symptoms fit together. Why isn't it? Dunno for sure. But I suspect it's a version problem. Cross-subnet browsing was added late in 1.x - implementing it requires some of the messy naming details I alluded to above. Apart from upgrading server1 to 2.x/3.x, I think you might have one other option - move the WINS server to the 1.x subnet. Even if server1 doesn't have the right WINS registration code for direct registration via unicast UDP, a WINS server is smart enough to listen for NetBIOS broadcasts and should update its list from that. This is only plausible because you have a single version 1.x server. If you had more than one on different subnets, you'd be screwed. Even so, I'm not absolutely certain a WINS server on the subnet will pick up the broadcast from the old Samba version - but it's worth a shot if you don't want to upgrade the machine.

 

[martind1]

ok i only skimmed these posts but, you knwo netbios is nonroutable right?

 

[cleverhandle]

Originally posted by: martind1
ok i only skimmed these posts but, you knwo netbios is nonroutable right?

You're thinking of NetBeui. NetBeui is non-routable transport protocol. NetBIOS is a naming protocol. It is neither routable nor non-routable in itself - it works above the transport protocol, which can TCP/IP or NetBeui.

 

[martind1]

Originally posted by: cleverhandle

Originally posted by: martind1
ok i only skimmed these posts but, you knwo netbios is nonroutable right?

You're thinking of NetBeui. NetBeui is non-routable transport protocol. NetBIOS is a naming protocol. It is neither routable nor non-routable in itself - it works above the transport protocol, which can TCP/IP or NetBeui.

damn it i was thinking netbeui, my bad. I still think its the subnetting that is keeping this from working, but ill let you two work it out as there is too much iinfo for me to read and catchc up on.