For what it's worth, I believe I've figured out the issue. The issue is/was not with WINS at all - it's with the NetBIOS Datagram Server (NBDS) on port 138. Seems that WINS requests are being handled just fine, but logon requests are not. I was looking at a traffic dump and noticed that NBDS requests have the Source IP and Port embedded in the payload of the packet. So, I'm guessing my Windows NT domain controllers, instead of using the IP header information to return a response, are attempting to use the data embedded in the packet to return the response. This explains why I've never seen any reply packets to the port 138 traffic being generated by my realservers. I'm not sure there's really much I can do about this - I suppose I can take a look at the Samba source code and see if there's some way to tear open the NBDS packet, modify the contents, put it back together, and then listen for the response. Not sure if I can write a module that will do this, or if some sort of external helper application will be required.
-Nick >>> On 2009/09/07 at 07:44, Joseph Mack NA3T <[email protected]> wrote: On Sun, 6 Sep 2009, Nick Couchman wrote: > Thanks for the suggestions, Joe! On the first count, yes, > the network where the virtual IP sits has several windows > machines (a couple dozen). On the second count, I > actually gave this a shot, set up Samba and turned on WINS > Proxy, then pointed the real servers at the IP of the LVS > machine for WINS. Unfortunately I got errors in the Samba > logs saying that the clients need to contact the WINS > Server. Samba is not the easiest thing to debug I'll admit. You have two networks of windows machines joined by a machine that happens to be an linux LVS director, but which isn't doing anything to packets to ports 137,138. Getting the two networks of windows machines to be on the same NT domain (or whatever its called) has got to be a solved problem (although I don't know the solution). Do the two lots of windows machines have to be on the same IP network? In this case you'll have to NAT out 137,138 on the realservers (I think both udp and tcp are involved). If not, then you'll need to setup the director to do the routing (turn off lvs first to simplify things). I expect Samba has got to be able to do it as well. For the ip2route method of getting realservers to talk to the outside world have a look at http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.non-lvs_clients_on_realservers.html#3-tier_routes Joe -- Joseph Mack NA3T EME(B,D), FM05lw North Carolina jmack (at) wm7d (dot) net - azimuthal equidistant map generator at http://www.wm7d.net/azproj.shtml Homepage http://www.austintek.com/ It's GNU/Linux! -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
