Solved

DHCP server and Windows NT clients

Posted on 2000-04-05
20
381 Views
Last Modified: 2013-12-16
I have recently setup a linux box, running redhat linux, as our company's DHCP server, giving out the IP addresses in the block 192.168.0.0; although this will soon change to a block of real addresses.  The server has been running fine for the clients except for one problem: they cannot see the Windows NT domain (ADTC) in our real network; thus cannot logon, see shares, etc. My /etc/dhcpd.conf looks as such: (with only pertinent information)

subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
option ip-forwarding off;
option netbios-name-servers 209.8.123.18; # our network; our NT server
option netbios-dd-server 209.8.123.18;
option netbios-node-type 8;
option netbios-scope "";
}

Our organization runs NetBIOS _over_ TCP/IP, not pure NetBIOS (I'm basing that off the fact that the only protocols we have defined in Settings under NT is TCP/IP). I have very little experience with either DHCP and the required NT protocols. Can someone please offer me some advice for solving this problem?


0
Comment
Question by:MattLesko
  • 6
  • 6
  • 4
  • +2
20 Comments
 
LVL 40

Expert Comment

by:jlevie
ID: 2688287
Do the NT clients get a correct IP/netmask? Check by looking at (from memory, I don't have an NT box handy) the output of ipconfig. If they get a valid IP & netmask, then the problem isn't in in the DHCP negoiation and lies elsewhere. And in fact the PDC is not inside the 192.168.0.0 net. Since finding a server in "Network Neighborhood" means using a netbios broadcast, the  clients aren't going to see the NT server at 209.8.123.18 unless there's a router between 192.168.0.0 and 209.8.123.0 that's "forwarding" the netbios broadcasts via a "helper address".

Somehow you've got to tell the clients what the path to 209.8.123.18 is and that gateway must route the traffic. You can probably then use an entry in lmhosts to tell the NT box about the server.
0
 

Author Comment

by:MattLesko
ID: 2691586
The clients see the network fine, they can ping hosts, internal and external (like yahoo.com). They can even connect to shares on computers, but cannot browse the network (NT) or do domain logons. How can I forward the broadcasts to the 209.8.123.* network? Do I use an option in /etc/dhcpd.conf or do I simply give every computer an lmhosts file? If the case is the later, could you please give me an example as I'm not familar with lmhosts. -- Matt
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2691728
From that I'm guessing that you have both networks "on the same wire" and they aren't separated by a real router. If that's in fact the case, then I don't believe that you can get browsing to work by anything you could do with the DHCP server. An lmhosts file will let the clients know about the PDC & domain by name and it ought to look like:

209.8.123.18      pdc-hostname      #PRE #DOM: your-NT-domain

Substitute the PDC's hostname and Domain name in the above.

I think the logon process is a broadcast for a PDC, so it's not clear to me that the lmhosts file will help for that. The only thing (other than a router that can forward the broadcast traffic) would be to multi-home the PDC and give it an interface onto the 192.168.0.0 network.
0
 

Author Comment

by:MattLesko
ID: 2694975
Your right, adding those things to lmhosts didn't help one bit. I cannot browse the network (via netwok neighborhood), but I can connect via direct shares (i.e., net use \\xxx\y). Is there some way I can relay these broadcasts around through the network? I think microsoft has a WINS relay agent for this, but that would require windows and a dual-homed computer, something which we do not have. Any idea on how to emulate this?
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2695505
How about multi-homing the PDC? That just means adding a second NIC and setting it for the 192.168.0.0 net. You can connect both NIC's to the "same wire" and the broadcast domain will lie within the client's network. That ought to also make it easier to move to the other network.

Relaying the broadcasts requires some form of a router, and that means something with two NIC's that understands the concept of forwarding the netbios broadcasts. I don't know about a WINS server, although that does seem likely. I know that you can do it with any Cisco router.

Speaking of moving to the 209.8.123.0 network... Seems to me like you are swimming against the tide there. The trend is to move away from public networks and to use private networks behind a NAT capable firewall. That's mostly driven by the need for lots of local hosts and limited access to public IP address space.

I know that I just ordered a commercial DSL line and got 32 IP's. Additional IP's can be had but they are going to cost me $1/IP/month. Naturally, I'm going to use NAT and a private network. Only those system that require external access are going to get a static NAT translation through the firewall.
0
 
LVL 1

Expert Comment

by:Sokka
ID: 2695916
You must Install SAMBA server to see the share of Linux in NT
0
 

Author Comment

by:MattLesko
ID: 2701994
Sokka: Sorry you must of misunderstood the question. I am not trying to share any files or drives on the linux box, nor am I having trouble letting linux boxen see windows clients. My problem is that I cannot get DHCP'd windows clients to do network browsing over a linux box acting as a gateway.

Jlevie: that may incur a solution to the problem, except that it requires a new network card for our server, and negates any purpose of having a linux box for a dhcp server/router (besides a likely increase in speed, efficiency, etc.).

I guess my question boils down to: Is it possible for a linux  machine to receive and relay netbios broadcasts across two networks?
0
 

Author Comment

by:MattLesko
ID: 2702031
Adjusted points from 200 to 800
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2702822
It's my understanding from the question & subsequent comments that you are running both the 192.168.0.0 & 209.8.123.0 networks on the same wire, correct? Furthermore, the Linux box is simple a DHCP server with a single NIC installed, correct?

If that's the case then, the only solution would be to multi-home the NT server to be on both networks. The problem has nothing to do with DHCP or Linux and everything to do with the way NetBios works. A Netbios client must be within the broadcast domain of a PDC/BDC for network logons to work or for servers to appear in Network Neighborhood. Well, I quess an alternative to multi-homing would be to move the clients to the NT server's net or vice versa.

If my assesment of all systems being on the same wire is correct, I guess I can't understand the reluctance to add a second NIC to the NT box. We are only talking about $20-30 for a low cost NIC, say a Netgear FA310TX or similar.

A few real routers (Cisco for one) can forward broadcast traffic on specific ports (including netbios 137/138) to "helper addresses" on another network. Broadcast forwarding is a very specialized service and requires special processing of the packets as they move from one network to another. It's not a routing function, per se. To the best of my knowledge there isn't any way to get a Linux box (or anything except a router) to do this.

I'll go so far as to say that what you've really got here is a network design problem. The network and services are being simply put in place without an overall design that considers both what the needs are and what the capabilities are. Without more information it's difficult to say what the best solution would be.
0
 
LVL 3

Expert Comment

by:apadua
ID: 2709768
How about installing WINS?

Test it this way.

Start>Run
\\serverIPaddress\sharename

instead of
\\servername\sharename

If it works, all you have a problem with is name resolution. You should then install a NBNS (NetBIOS Name Server), which in MS's implementation is called WINS. You can read RFC 1001/1002 for more information on the exact way NetBIOS name resolution works.

But you could install just one WINS server, and have your entire network function with it.


Good luck,

Andre

0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 3

Expert Comment

by:apadua
ID: 2709776
elaborating on my previous post, you mention in your config file that you configured NBNS to be 209.8.123.18

Is this machine running WINS? (IT should be).


Andre
0
 

Expert Comment

by:HarriJE
ID: 2713572
A few suggestions:

(1)  Go ahead and install NetBEUI on the NT server and one client machine (to test).  There's nothing to configure, so it'll take all of 15 minutes, including the obligatory reboots.  This will either confirm or deny any routing issues.  NetBIOS packets aren't normally routed over TCP/IP, so you'll get a general broadcast announce over the local ethernet wire.  NetBIOS does not have any knowledge of TCP/IP network addresses, so bypassing that (possible) restriction might yeild results.

(2)  Try removing the "option netbios" lines from your dhcpd.conf file (do this during off-hours so you don't disrupt anyone using the network) and restart dhcpd.  Let NetBIOS election rules work their course and establish the browse masters, domain masters, and PDC.  Unless you are trying to connect your network to another physical network, WINS support is not really necessary (though it can speed up name resolving on larger networks).  You might be inadvertently limiting the normal election process's ability to determine the natural hierarchy of your machines.

(3)  You asked whether it is possible for a Linux machine to relay NetBIOS packets.  The answer is yes; the SAMBA suite is capable of mimicking a WINS server.  However, be warned:  SAMBA cannot replicate its database with an NT WINS server, and putting any kind of NetBIOS-over-TCP/IP machine on a public network is a serious security risk.  SAMBA is an excellent application, but I wouldn't use it solely for its WINS capabilities.  There are better solutions.

(4)  Just out of curiosity (because I can't tell from your original posting):  can the NT server browse the clients?  You've mentioned that the clients can't browse the network, so I'm curious as to whether the server can.

The key to solving these kinds of problems is to simplify everything, then complicate one item at a time until you get the setup you want.  Start by putting NetBIOS support on all machines, since that is the basic, simplest mechanism by which Windows networking works.  That also means taking all NetBIOS information out of the DHCP setup and letting the machines fight it out for control....your PDC will always emerge as the victor, due to the way the election rules are set up.  You'll also avoid any potential conflicts with the split-personality TCP/IP setup you currently have.  Once you have that working (and I'm reasonably confident it will, since that's exactly how my own network is set up), try adding the single line "option netbios-name-servers ..." to your dhcpd.conf.  That's the extent of the WINS setup in my own dhcpd.conf, and everything works like a charm...the rest of the information is dynamically determined through normal election rules.

Hope this helps.
0
 

Author Comment

by:MattLesko
ID: 2714129
By enabling NetBEUI on the clients and the server, I can get the client to see the whole network. Unfortunately, I'd rather not use this, seeing as NetBEUI is network intensive (but I will most likely just do this). I will be leaving for a vacation for about a week, so don't be alarmed if you don't hear more from me.
0
 
LVL 3

Accepted Solution

by:
apadua earned 800 total points
ID: 2714405
Easier than installing NETBeui on all machines, you can just Remove the line that specifies Netbios Name Server, and change the

option netbios-node-type 8

to

option netbios-node-type 1


That should put all your machines into broadcast mode, even under TCP/IP. Should take care of it.


André
0
 

Expert Comment

by:HarriJE
ID: 2714421
Well, therein lies your problem and a solution.  For network browsing to work, you need some kind of network protocol that keeps track of the available network shares.  NetBIOS is that protocol (I believe that IPX/SPX works this way as well, which is why Novell and Microsoft networks behave so similarly in this respect).  Microsoft networking is built around the idea of NetBIOS elections, which determine which computer on the network gets to be "boss" and administer those shares.

It might surprise you to learn that NetBIOS probably doesn't cause enough extra network traffic to disrupt your data flow.  This is because the election process chooses a "domain master browser" to cache all of the network resources available.  In your case, this would always be your PDC.  The initial election is the only time that NetBIOS relies on network-wide broadcasts to announce its presence.  After that, each client reports its available resources directly to the master browser every 15 minutes, and when you request a share from the network, it is the master browser which acts as the intermediary to ensure that the least possible amount of network traffic is generated.  Elections were designed and implemented for the exact reason of reducing network traffic.

As a side note, the sole function of a WINS server is to, in essence, act as a local master browser for the purpose of forwarding NetBIOS share announcements over a router.  If you aren't planning on connecting to another physical network, you probably don't need a WINS server and, in fact, it will probably be very seldom (if ever) utilized.  WINS is generally consulted only if local NetBIOS broadcast resolution fails.

I know that's probably not the answer you were looking for, but as far as I know, that's the right answer.  If you want Network Neighborhood to function properly in an NT network, you need NetBEUI and Client for Microsoft Networks installed on each workstation.  Unless you have a dozen shares configured on each client, you won't generate enough network traffic to worry about.

Have a good vacation (the weather is beautiful today, so I wish I could go too!)  
0
 
LVL 3

Expert Comment

by:apadua
ID: 2714566
You most definitely do NOT need NetBEUI for Network Neighborhood to function. NetBIOS runs over NETBEUI (which is actually a protocol MS developed to carry netbios, hence the name NETbios Extended User Interface). But it also runs over TCP/IP and IPX. Therefore, even with just TCP/IP, network browsing works fine.

IPX/SPX work the same way as NetBEUI just because Microsoft's implementation places NetBIOS on top of them. That's why it doesn't matter what protocol you use, it works.

In regards to the WINS issue, all WINS queries are made as unicast, and not Broadcast. Since he had set Netbios Node Type 8, WINS server was attempted BEFORE a broadcast was attempted. Hence, the WINS server would be used constantly, and broadcast would be kept down to a minimum.

Changing NetBIOS node type to 1, which is Broadcast, makes NetBIOS function in Broadcast ONLY. Hence, no WINS server is needed (or will be used even if available), and no multiple network support is available (unless you have a good router, which forwards NetBIOS broadcasts). Net traffic will also increase.

Andre
0
 
LVL 3

Expert Comment

by:apadua
ID: 2714572
HarriJE,

I noted you are new to the forum. It is customary that you post all answers as comments, unless you are ABSOLUTELY sure that it will solve the person's problem. Providing an answer locks the question, and others who may have other suggestions are locked out.

When you ask a question, you'll note there's a link called "accept this comment as an answer". Therefore, if your comment solves the person's problem, he'll just use that comment as an answer.

Thanks,


Andre
0
 

Expert Comment

by:HarriJE
ID: 2714787
Apadua:

My apologies for violating your SOP, and my (embarassed) apologies for confusing NetBIOS and NetBEUI.  However, I stand by my original posting as an answer (not a comment) because I know that it produces valid results.  In fact, the original poster acknowledged such by stating that using NetBEUI does indeed solve his problem (getting network browsing to function).

The problem with using TCP/IP as the primary transport mechanism is that TCP/IP relies on proper IP address routing.  In the case where distinct IP networks exist on a single physical network, one must carefully separate routing and nonrouting protocols.  If there is not a properly configured route between the two networks, then TCP/IP transport will fail.  Consequently, any transport that uses TCP/IP as a wrapper protocol will also fail.  Hence, NetBIOS over TCP/IP will fail if TCP/IP itself fails.

In any event, our solution was the same (use broadcast resolution, at least until a large enough block of IP addresses is available, so that TCP/IP routing does not play a part), although our methods differ.

It's worth noting that multihoming a WINS server is not a good idea, just as one shouldn't use DHCP to assign the IP address of a WINS server.  WINS is a dynamic service, but it needs a firm anchor to both the physical and logical networks in order to succeed.  The least error-prone solution is to use a single, fixed IP address and a single, fixed network interface for the primary WINS server.

It's also worth noting that broadcast transmissions are not seriously detrimental to network performance as long as the number of hosts on the network remains relatively small.

Thank you for forcing me to look at this from a slightly different perspective and to do some (much needed) reading on NetBIOS.  I stand by my answer, however; switching to a broadcast transport such as NetBEUI provides the desired results.  WINS and NetBIOS over TCP/IP becomes a better option once all hosts are configured for the same logical TCP/IP network (or a route is established between them).
0
 
LVL 3

Expert Comment

by:apadua
ID: 2717971
:-)
0
 

Author Comment

by:MattLesko
ID: 2745420
Yep it works all right. Just gotta remember to keep the part with netbios-scope ""  in the file.  Thanks tremendously for all your help guys. Thanks apadua.
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Setting up Secure Ubuntu server on VMware 1.      Insert the Ubuntu Server distribution CD or attach the ISO of the CD which is in the “Datastore”. Note that it is important to install the x64 edition on servers, not the X86 editions. 2.      Power on th…
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now