thanks for the input joel, joseph and james. ;)
here are results...
On Thu, 25 Apr 2002, Joseph Loo wrote:> This may be a stupid suggestion, but do you have your workgroup set as
> the same as the windows machine connected?
yes. i have tried other workgroup names as well, but not recently.
>From Joel@HammersHome com:
>
>I recall your saying that the WINS server is not listening to port 137
>because, as I recall you tried to telnet to port 137 and got no answer. I
>tried to telnet my samba server on 139 and got an answer but got no
>answer on port 137, so, I don't think telnet works for port 137.
correct. i understand 139 is for 'session service' and 137 is for
'name
service' but i dont know if 137 uses udp or tcp. anyway.
it is unclear to me the exact purpose of 138.
i am just starting to read:
http://members.tripod.com/~Gavin_Winston/NETBIOS.HTM
to maybe understand all that some more.
>You might get a port scanner and scan your wins server (with permission
>of your IT people, of course), or just ask the IT people if port 137
>is working. I suspect that it is.
nmap is installed.
ive considered that, the it people around here hide themselves pretty
well, (university of about 30k people total) figure i should find out as
much as i can before trying to find someone here who knows anything and
will answer a phone or email...
>I would try /etc/hosts for one client, just to see if it works. If it
>does, you might be able to set up a DNS on your linux machine, but this
>really sounds far fetched.
well, i am more interested in windoze being able to 'see' the linux box.
then vice-versa. the other issue is all the clients i would like to have
see the linux box use dchp, and i have no control of the dchp server and
not enough static addresses to go that route and not enough money to build
our own private subnet using reserved addresses (which would be ideal...)
>Can you talk at all to your wins server with nmblookup? There are a lot
>of
>options with nmblookup, many of which are not well explained in man
>nmblookup.
>For example, try talking to your wins server with:
>nmblookup WorkGroupNames#1b
>You might need to use the -B option to get the right subnet for your
>master.
okay, here is something i havent done much lately.
here is one interesting interaction:
nmblookup -U 192.168.2.138 -R '2030#1b' -d 4
which gives lots of good stuff (smb.conf processing etc repeated below),
followed by:
wins_srv_load_list(): Building WINS server list:
192.168.2.138,
1 WINS server listed.
doing parameter hosts allow = 192.168. 127.
doing parameter printing = lprng
pm_process() returned Yes
added interface ip=192.168.91.97 bcast=192.168.91.255 nmask=255.255.255.0
added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0
bind succeeded on port 0
Socket opened.
querying 2030 on 192.168.2.138
wins_srv_died(): WINS server 192.168.2.138 appears to be down.
name_query failed to find name 2030#1b
>Then, try:
>smbclient -NL winserver and see if it will show you any servers.
>If it does, then you are on your way.
smbclient -NL 192.168.2.138 -d 4 gives:
added interface ip=192.168.91.97 bcast=192.168.91.255 nmask=255.255.255.0
added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0
Client started (version 2.2.1a).
Connecting to 192.168.2.138 at port 139
session request to 192.168.2.138 failed (Called name not present)
Connecting to 192.168.2.138 at port 139
session request to 192 failed (Called name not present)
Connecting to 192.168.2.138 at port 139
session request ok
Anonymous login successful
Domain=[DOMAIN.ORG] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
session setup ok
tconx ok
Sharename Type Comment
--------- ---- -------
NetShareEnum failed
Error returning browse list: ERRDOS - ERRnoaccess (Access denied.)
Server Comment
--------- -------
Workgroup Master
--------- -------
so, again, the wins server listens on 139 not 137.
at least now know for sure it is NT... but it doesnt offer any
information here.
anyone have ideas why the first two sesion requests would fail like that?
>You can also try nmblookup -B broadcast YOURWORKGROUP<00>
>This will return ipaddresses of servers in that group on the subnet
>specified with -B.
>You can then get the server netbios names with:
>nmblookup -A ipnumberofserver
> ...
>Joel
right.
this is a point of some confusion for me, mentioned previously. dchp
clients on the same "segment" as the linux box get different (class c)
"subnet" addresses than the static ips i have. ie windoze gets
192.168.92.x with broadcast 192.168.92.255 and my static #s are
192.168.91.x ... yet we are all on the same wire. this doesnt seem right
to me but is out of my control.
trying "nmblookup -B 192.168.92.255 ..." on the linux box returns
nothing,
but likely because the ip 192.168.91.97 cant broadcast to subnet ..92.255
?
but: "nmblookup -B 192.168.91.255 2030" shows only the local machine,
not
even another linux box on ..91.x running samba as well... i hadnt noticed
that before.
>From: James W. Beauchamp <jbeauchamp7@mindspring com>
>
>can you ping hte wins server from your linux box?
yes.
>How is your machine configured? Are you the local master browser and the
>domain master browser? Do either you or the WiNS server have remote
>announce set? does browsing on a Windows machine on your local subnet
>show
>the linux box as well as the other work groups? If not, then the two are
>not communicating..
i have tried many combinations of these options. currently it is:
preferred master = No
domain master = True
i dont know the wins servers configuration, i have tried several 'remote
announce' or 'remote browse sync' settings, remote broadcast
addresses or
the wins server ip. no luck with any.
i have never been able to browse the linux box. in some configurations it
is possible to search for it, and find it and use it, but it never shows
up in the 'neighborhood' even while connected to it. (it has been so
long
and so many configs that i think this only happens for a 98se client when
it has lmhosts setup for that linux box...)
right, i know they are not communicating properly, and the 'correct'
solution will involve wins, right? so there are these wins servers out
there, working for windoze clients, but nmb wont talk to them.
>I am kind of like you. I am having limited success with this on my
>networks. However, I suspect that you probably don't have control over
>the WINS server. Right? Or is it a Windoze box?
>
>James
right. i have no control of dchp or dns or wins servers.
>P.S. - I suppose you have already looked at the browsing.txt file?
yes, many a time. as well as a good portion of the rest of the
documentation. and i am continuing to do so as time permits...
thanks again for all the ideas.
big thanks for your attention if youve gotten this far in the message! ;)
-neil
previous info for completeness:
> neil wrote:
> i am on a campus with an existing wins server.
> this server is working for windows clients, since they can browse across
>
> subnets. (or is there another way?)
> i am using samba 2.2.1a on redhat linux intel 7.2 kernel 2.4.9-31
> my smb.conf includes:
> wins server = 192.168.2.138
> hosts allow 192.168. 127.
>
> my machine has ports 137, 138, 139 (tcp and udp on all three) unblocked
>
> looking for a known, up, sharing machine with:
> smbclient -d 8 -W GROUP -L KNOWN
> gives:
>
> added interface ip=192.168.91.97 bcast=192.168.91.255
> nmask=255.255.255.0
> added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0
> Client started (version 2.2.1a).
> resolve_lmhosts: Attempting lmhosts lookup for name KNOWN<0x20>
> getlmhostsent: lmhost entry: 127.0.0.1 localhost
> resolve_hosts: Attempting host lookup for nam
>
> e KNOWN<0x20>
> resolve_wins: Attempting wins lookup for name KNOWN<0x20>
> wins_srv_count: WINS status: 1 servers.
> 192.168.2.138 <192.168.2.138>: alive
> resolve_wins: WINS server == <192.168.2.138>
> bind succeeded on port 0
> Sending a packet of len 50 to (192.168.2.138) on port 137
> Sending a packet of len 50 to (192.168.2.138) on port 137
> Sending a packet of len 50 to (192.168.2.138) on port 137
> wins_srv_died(): WINS server 192.168.2.138 appears to be down.
> name_resolve_bcast: Attempting broadcast lookup for name KNOWN<0x20>
> bind succeeded on port 0
> socket option SO_KEEPALIVE = 0
> socket option SO_REUSEADDR = 1
> socket option SO_BROADCAST = 1
> Could not test socket option TCP_NODELAY.
> socket option IPTOS_LOWDELAY = 0
> socket option IPTOS_THROUGHPUT = 0
> socket option SO_SNDBUF = 65535
> socket option SO_RCVBUF = 65535
> socket option SO_SNDLOWAT = 1
> socket option SO_RCVLOWAT = 1
> socket option SO_SNDTIMEO = 0
> socket option SO_RCVTIMEO = 0
> Sending a packet of len 50 to (192.168.91.255) on port 137
> Sending a packet of len 50 to (192.168.91.255) on port 137
> Sending a packet of len 50 to (192.168.91.255) on port 137
> Sending a packet of len 50 to (127.255.255.255) on port 137
> Sending a packet of len 50 to (127.255.255.255) on port 137
> Sending a packet of len 50 to (127.255.255.255) on port 137
> Connection to KNOWN failed
>
> i do not want to resort to lmhosts on all clients.
> the wins server is up, but only answers telnet on port 139 not 137
> broadcast fails because KNOWN is on a different subnet, 192.168.92.x
>
> i have played with this now and then for a few years, and never have any
> success. i believe i understand samba fairly well, a
> nd have used it
> successfully on other (private, isolated) subnets, but never got it
> working on this campus...
>
> any ideas?
>
> On Tue, 23 Apr 2002, neil wrote:
>
> samba 2.2.1a on redhat linux 7.2 intel
> questions about WINS:
> i am on a campus with preexisting WINS servers, and so i should like to
> utilize them as their addresses are supplied to DHCP clients. when i
> tell
> nmbd about this WINS server the log shows nmbd trying to contact it but
> there is no response. using telnet i can only get a connection to
> these wins servers on port 139. shouldnt 137 be open? so my nmbd is
> constantly trying to contact the server and gets no response. can
> someone
> help me understand the full story here?
>
> errors are like:
>
> [2002/04/23 12:59:25, 4]
> nmbd/nmbd_packets.c:retransmit_or_expire_response_records(1664)
> retransmit_or_expire_response_records: timeout for packet id 3252 to
> IP
> 192.168.2.138 on subnet UNICAST_SUBNET
>
> [2002/04/23 12:59:25, 2]
> nmbd/nmbd_nameregister.c:register_name_timeout_response(200)
> register_name_timeout_response: WINS server at address 192.
>
> 168.2.138 is
> not responding.
>
> [2002/04/23 12:59:26, 4]
> nmbd/nmbd_packets.c:retransmit_or_expire_response_records(1664)
> retransmit_or_expire_response_records: timeout for packet id 3254 to
> IP
> 192.168.2.138 on subnet UNICAST_SUBNET
>
> [2002/04/23 12:59:26, 0]
> nmbd/nmbd_become_dmb.c:become_domain_master_query_fail(259)
> become_domain_master_query_fail: Error 0 returned when querying WINS
> server for name 2030<1b>.
>
> i dont think there is a real problem with the WINS server, since windows
>
> clients are able to browse across subnet boundaires...
>
> more detail:
> my issue is this- i have machines with static ips in address range say
> 192.168.91.x and dhcp clients on the same segment get ips of
> 192.168.92.x
> i have no control of the dhcp server or wins server. i would like to use
>
> samba services on the .91.x machines from .92.x machines, and have found
>
> one configuration with which the .92.x machines may 'find' a s
>
> amba server
> on .91.x but not by 'browsing'. that is by telling a .91.x samba
server
> to
> be domain master, preferred master, os level 65, local master. then
> windows 'find .. computer' can find it and things work, but it does
not
> appear in the 'neighborhood'