Domain controller not seen, other systems visible
m...@privacy.net
and am at a loss to determine where the problem is. The unit has an
RTL8168 on the motherboard which is working fine as far as I can tell with
the latest RTL driver, rtgnda.os2, as TCP/IP works and I can do a locally
verified logon and use resources on other systems on the LAN. The problem
is that I cannot do a domain verified logon and a net view of the domain
controller fails as well as any attempt to net use domain controller
resources. I can ping the controller, which is no surprise as all the
systems are connected to the same Netgear FVS338 router. Resources on
systems other than the domain controller are usable.
How do I determine where the problem is that this new system cannot see
the domain controller? Both Netbios and Netbios over TCP/IP are on the
new system and the other systems as well. I did't find any debugging
suggestions in the documentation I have, so I am posting to see what
suggestions you might have for me.
-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------
Peter
> I am encountering something strange on a new machine I am adding to my LAN
> and am at a loss to determine where the problem is.
,,, <Snip> ...
You dont say what type of system the Domain controller is (IE OS/2,
Windows, SAMBA,etc...). Without that about all I can suggest is to
confirm that you are using the MINIMUM words, etc, such as NAMES,etc
are in UPPER CASE and are 8 chars or less. Also check things like the
default DOMAIN is the same, "ServerHidden=no" is set in IBMLAN.INI,
etc.
Cheers...............pk.
--
Peter from Auckland.
Ilya Zakharevich
> I am encountering something strange on a new machine I am adding to my LAN
> and am at a loss to determine where the problem is. The unit has an
> RTL8168 on the motherboard which is working fine as far as I can tell with
> the latest RTL driver, rtgnda.os2, as TCP/IP works and I can do a locally
> verified logon and use resources on other systems on the LAN. The problem
> is that I cannot do a domain verified logon and a net view of the domain
> controller fails as well as any attempt to net use domain controller
> resources. I can ping the controller, which is no surprise as all the
> systems are connected to the same Netgear FVS338 router. Resources on
> systems other than the domain controller are usable.
>
> How do I determine where the problem is that this new system cannot see
> the domain controller? Both Netbios and Netbios over TCP/IP are on the
> new system and the other systems as well. I did't find any debugging
> suggestions in the documentation I have, so I am posting to see what
> suggestions you might have for me.
I know very little about what is "domain controller" etc., but I
SUSPECT I have a very similar situation. I have a network connected
via 2Wire router. TCP/IP works fine. NETBIOS does not, with very
funny symptoms:
a) Computer A can see computer B, and access its resources.
b) Computer B cannot see computer A, and cannot access its resources.
c) Nobody can see computer C, and C cannot see anybody.
As I said, I have no clue how NETBIOS connections works; but my hunch
is that the router somehow does not correctly pass broadcast events,
and these are part of NETBIOS protocol... And not passing the events
may be related to OS/2 DDNS not working with 2wire implementation...
If I had a stronger need to investigate, I would try to connect 2
computers by a crossover wire, and check in this configuration (with
DHCP off).
Hope this helps,
Ilya
m...@privacy.net
>Hi Dave,
> ,,, <Snip> ...
Opps! Domain controller is OS/2 Warp Server Advanced. Above noted
DOMAIN, ServerHidden settings proper. I can net view the domain and it
shows the new machine if I start peer services. I can view and use
resources from the two other systems on the LAN, just not the domain
controller. I get an OS/2 error 54 from the new system if I try to view
the domain controller. I gen an OS/2 error 54 from the domain controller
if I try to view the new system. the other two can view the new system
fine.
Rodney Pont
>Opps! Domain controller is OS/2 Warp Server Advanced. Above noted
>DOMAIN, ServerHidden settings proper. I can net view the domain and it
>shows the new machine if I start peer services. I can view and use
>resources from the two other systems on the LAN, just not the domain
>controller. I get an OS/2 error 54 from the new system if I try to view
>the domain controller. I gen an OS/2 error 54 from the domain controller
>if I try to view the new system. the other two can view the new system
>fine.
Error 54 is:
[C:\]help 54
SYS0054: The network is busy or is out of resources.
EXPLANATION: The network is currently busy processing other requests
or is out of resources.
ACTION: Retry the command at a later time or verify your network
configuration to be sure enough network resources are specified.
I suggest you compare the protocol.ini and ibmlan.in of the system that
does work and the one that doesn't.
--
Regards - Rodney Pont
The from address exists but is mostly dumped,
please send any emails to the address below
e-mail ngpsm4 (at) infohitsystems (dot) ltd (dot) uk
m...@privacy.net
on 05/26/2009
at 07:23 AM, "Rodney Pont" <pmmsp...@infohitsystems.ltd.uk> said:
...snipped...
>I suggest you compare the protocol.ini and ibmlan.in of the system that
>does work and the one that doesn't.
I have done a bit of comparing and tweaking the protocol.ini and the
ibmlan.ini files on the new system with another working one and I now get
a SYS0055 error at the new system attempting to view the domain
controller. Attempting to logon with domain validation still fails.
In protocol.ini the only differences reflect the nic. Here is a
comparison (differences only):
[IBMLXCFG]
RTGNDA_nif = RTGNDA.nif <vs> E100BEO2_NIF = E100BEO2.NIF
[netbeui_nif]
Bindings = ,RTGNDA_nif <vs> BINDINGS = ,E100BEO2_NIF,,
[tcpbeui_nif]
Bindings = RTGNDA_nif <vs> BINDINGS = E100BEO2_NIF,,,
[tcpip_nif]
Bindings = RTGNDA_nif <vs> BINDINGS = E100BEO2_NIF,,,
Other than the trailing commas, which I don't know the meaning of, it
seems to be a reasonable match. IBMLAN.INI differences are services
started, name and boot drive, as you can see (differences only):
[requester]
wrkservices = MESSENGER <vs> wrkservices = MESSENGER, peer
Computername = DDD-PC2 <vs> Computername = ETG-PC
[replicator]
importpath = P:\ibmlan\repl\import <vs> importpath =
I:\ibmlan\repl\import
As I noted earlier, I can logon locally and work with resources other than
those on the domain controller. All systems are connected to a single
Netgear FVS338 router and I can ping the domain controller, so I am still
puzzled.
Lars Erdmann
in protocol.ini have you specified the domain controller's (and
potentially the domain controller backup's) name ?
You normally do so via MPTS.EXE, selecting "NETBIOS VIA TCP/IP" and then
modify driver parameters.
You should list your protocol.ini.
Lars
m...@privacy.net schrieb:
m...@privacy.net
>Dumb question:
>in protocol.ini have you specified the domain controller's (and
>potentially the domain controller backup's) name ?
>You normally do so via MPTS.EXE, selecting "NETBIOS VIA TCP/IP" and then
>modify driver parameters.
>
>You should list your protocol.ini.
In order to spare those who are not interested, I have zipped up my
PROTOCOL.INI and IBMLAN.INI files from the new system (DDD-PC2) and
another system (ETG-PC) and placed them in a zip here:
http://members.verizon.net/~ariesgrp/netconf.zip
I should note that the domain controller is not noted in any system on my
LAN in the PROTOCOL.INI or IBMLAN.INI files. My domain is in all of the
IBMLAN.INI files, but not the domain controller. There is no backup
domain controller. There are only four machines on the LAN except for any
visitors I might have plugged in.
Lars Erdmann
"NETBIOS via TCP/IP" (and TCP/IP of course which you do have). In fact
the different parameter sets for these 2 protocols might conflict with
each other. The NETBIOS protocol driver WILL load if you only specify
"NETBIOS via TCP/IP".
2.) Make sure you specify "0" for the adapter number for BOTH "NETBIOS
via TCP/IP" and "TCP/IP" protocols (you only have 1 network adapter in
your box). There was at least one version of MPTS.EXE that would give
WRONG adapter numbers to the protocols listed.
3.) in MPTS, select "NETBIOS via TCP/IP" protocol. Select "Edit". A
dialog box will open that will allow to edit the protocol parameters,
the IP addresses and the broadcast addresses. Select "protocol
parameters", hit "Configure" and in the dialog box that opens specify
the IP Address of your NETBIOS Nameserver which I suspect to be the same
as the Domain controller. This is not the NETBIOS domain controller but
I suspect that it is the same box that resolves NETBIOS names to NETBIOS
addresses.
Are you saying that everything works fine for ETG-PC but not for DDD-PC2
? In that case, please also look in IBMCOM\LANTRAN.LOG on both of those
boxes in order to check if something goes wrong on NETBIOS protocol
initialization on either system.
Lars
Rodney Pont
>I have done a bit of comparing and tweaking the protocol.ini and the
>ibmlan.ini files on the new system with another working one and I now get
>a SYS0055 error at the new system attempting to view the domain
>controller. Attempting to logon with domain validation still fails.
>
>In protocol.ini the only differences reflect the nic. Here is a
>comparison (differences only):
>
>[IBMLXCFG]
> RTGNDA_nif = RTGNDA.nif <vs> E100BEO2_NIF = E100BEO2.NIF
>
>[netbeui_nif]
> Bindings = ,RTGNDA_nif <vs> BINDINGS = ,E100BEO2_NIF,,
>
>[tcpbeui_nif]
> Bindings = RTGNDA_nif <vs> BINDINGS = E100BEO2_NIF,,,
>
>[tcpip_nif]
> Bindings = RTGNDA_nif <vs> BINDINGS = E100BEO2_NIF,,,
>
>Other than the trailing commas, which I don't know the meaning of, it
>seems to be a reasonable match. IBMLAN.INI differences are services
>started, name and boot drive, as you can see (differences only):
The commas are separators for when you have multiple cards using the
same protocol, you can get rid of them (I think).
>[requester]
> wrkservices = MESSENGER <vs> wrkservices = MESSENGER, peer
> Computername = DDD-PC2 <vs> Computername = ETG-PC
Are you really using the domain controller as a domain controller? Have
you set up logins, login scripts and resource shares for it?
I assume the one on the right is the domain controller since it's
running the E100* nif. That would leave the one on the left as the new
one. The reason I ask about domain controller is that the one on the
right is running peer, that allows the share of resources to a
workgroup. The one on the left isn't running peer so won't be able to
see resources.
I'm a little bit rusty over a domain controller but if you are simply
expecting to see shares you might be really wanting peer.
Actually it looks as though I'm rusty on peer as well. I'm not running
peer in IBMLAN.INI on this machine either but I can share and connect
to resources. I'm afraid I'm out of my depth now, sorry.
m...@privacy.net
>1.) remove NETBIOS protocol. It's absolutely sufficient to only have
>"NETBIOS via TCP/IP" (and TCP/IP of course which you do have). In fact
>the different parameter sets for these 2 protocols might conflict with
>each other. The NETBIOS protocol driver WILL load if you only specify
>"NETBIOS via TCP/IP".
>2.) Make sure you specify "0" for the adapter number for BOTH "NETBIOS
>via TCP/IP" and "TCP/IP" protocols (you only have 1 network adapter in
>your box). There was at least one version of MPTS.EXE that would give
>WRONG adapter numbers to the protocols listed.
>3.) in MPTS, select "NETBIOS via TCP/IP" protocol. Select "Edit". A
>dialog box will open that will allow to edit the protocol parameters,
>the IP addresses and the broadcast addresses. Select "protocol
>parameters", hit "Configure" and in the dialog box that opens specify
>the IP Address of your NETBIOS Nameserver which I suspect to be the same
>as the Domain controller. This is not the NETBIOS domain controller but
>I suspect that it is the same box that resolves NETBIOS names to NETBIOS
>addresses.
>Are you saying that everything works fine for ETG-PC but not for DDD-PC2
>? In that case, please also look in IBMCOM\LANTRAN.LOG on both of those
>boxes in order to check if something goes wrong on NETBIOS protocol
>initialization on either system.
Yes, I am saying things appear to work fine on ETG-PC while I cannot logon
to the domain or view shares from the domain controller from my DDD-PC2
system. I have added the LANTRAN.LOG files to the zip so you can inspect
them as well.
I do see a difference between them, as DDD-PC2 notes both trying to bind
logical adapter 0 to TCP/IP lan 0 and that it is bound while the other
system only notes it is bound. I guess this might be a timing issue of
some sort.
The node address on DDD-PC2 does not look right to me, as it is all zeros
for adapter 1, while the node address looks good on ETG-PC in the log. Is
this supposed to be coming from the driver? Isn't this supposed to be a
hardware value in the adapter? There appears to be a NETADDRESS tag in
the RTGNDA.nif file and that it allows you to override the one fixed in
the hardware.
If you think this could be the problem, is there a way I can pull the
address from the adapter so that I can enter the tag properly? Would it
appear anywhere I can retrieve it?
m...@privacy.net
Nope, both of these are for workstations on the LAN. I am still in the
process of setting up the one on the left, a new motherboard in an older
system. The older system worked fine, but of course the new motherboard
has a new nic on it.
>I'm a little bit rusty over a domain controller but if you are simply
>expecting to see shares you might be really wanting peer.
>Actually it looks as though I'm rusty on peer as well. I'm not running
>peer in IBMLAN.INI on this machine either but I can share and connect to
>resources. I'm afraid I'm out of my depth now, sorry.
Thanks for your feedback. Hopefully I will get this resolved soon.
Trevor Hemsley
<pmmsp...@infohitsystems.ltd.uk> wrote:
> >[requester]
> > wrkservices = MESSENGER <vs> wrkservices = MESSENGER, peer
> > Computername = DDD-PC2 <vs> Computername = ETG-PC
Why no peer on DDD-PC2?
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
m...@privacy.net
at 03:10 PM, "Trevor Hemsley" <Trevor....@mytrousers.ntlworld.com>
said:
>On Tue, 26 May 2009 19:32:04 UTC in comp.os.os2.networking.tcp-ip,
>"Rodney Pont" <pmmsp...@infohitsystems.ltd.uk> wrote:
>> >[requester]
>> > wrkservices = MESSENGER <vs> wrkservices = MESSENGER, peer
>> > Computername = DDD-PC2 <vs> Computername = ETG-PC
>Why no peer on DDD-PC2?
I went ahead and added it, I had left it out as I have not setup any
shares on DDD-PC2 yet and believed it wasn't needed until I did so. I see
no difference in behavior with peer added.
Rodney Pont
>I went ahead and added it, I had left it out as I have not setup any
>shares on DDD-PC2 yet and believed it wasn't needed until I did so. I see
>no difference in behavior with peer added.
What happens if you do a:
net start req
followed by a:
logon username /p:password
Dave Yeo
> Nope, both of these are for workstations on the LAN. I am still in the
> process of setting up the one on the left, a new motherboard in an older
> system. The older system worked fine, but of course the new motherboard
> has a new nic on it.
Have you considered an IRQ conflict. When I updated my motherboard here,
using the same NIC as before, tcpip would fade away. It was sharing an
IRQ with the sound card, moving it to a different PCI slot fixed the issue.
Dave
m...@privacy.net
>On Tue, 26 May 2009 16:47:33 -0300, m...@privacy.net wrote:
>>I went ahead and added it, I had left it out as I have not setup any
>>shares on DDD-PC2 yet and believed it wasn't needed until I did so. I see
>>no difference in behavior with peer added.
>What happens if you do a:
>net start req
>followed by a:
>logon username /p:password
That works with the username/password I assigned. But if I add the
/V:DOMAIN to have it validated by the domain controller it fails.
m...@privacy.net
I am running this on an eCS 2.0 RC6a system with /SMP /APIC, which I
understand maps a separate IRQ for each device. This is not the same nic
I was running before, both are motherboard based and different. It appears
the driver I am using is not passing information to RMVIEW and /IRQ there
does not show the IRQ the nic is shown by PCI.EXE as being used, but there
is no conflicting use shown.
As I noted earlier, TCP/IP is working fine on the nic. In fact peer
networking is working with other systems on the LAN. The problem is I
can't do a domain logon to the WSA domain controller or see any of the
shares it offers from the upgraded system.
m...@privacy.net
at 12:25 AM, Dave Yeo <dave....@gmail.com> said:
Problem is now solved. I used IPTRACE to capture traffic on both of the
systems while things were quiet and found a routing problem that I was
able to correct.
This still leaves me with one puzzle, but of lesser importance. The new
unit is definitely using NETBIOS over TCP/IP for its connection, but I
also have NETBIOS installed on it and that is what the other systems are
using for their connections as the routing problem would have prevented
them from connection using that protocol as well. So why is NETBIOS not
working on the new unit? Is there a problem with NETBIOS on SMP systems?
Is there something about the new nic that is problemic for NETBIOS?
It might be interesting to track this down, but I don't know offhand how
to do so. I only tracked down the routing issue when I thought of the
IPTRACE tool and I am unaware of a similar tool for NETBIOS on my system.
Thanks to all who offered ideas in getting this solved. I hope this will
be of help to others with similar issues.
Lars Erdmann
> unit is definitely using NETBIOS over TCP/IP for its connection, but I
> also have NETBIOS installed on it and that is what the other systems are
> using for their connections as the routing problem would have prevented
> them from connection using that protocol as well. So why is NETBIOS not
> working on the new unit? Is there a problem with NETBIOS on SMP systems?
> Is there something about the new nic that is problemic for NETBIOS?
>
> It might be interesting to track this down, but I don't know offhand how
> to do so. I only tracked down the routing issue when I thought of the
> IPTRACE tool and I am unaware of a similar tool for NETBIOS on my system.
1.) It's really enought to ONLY install "Netbios via TCP/IP". This will
implicitely install and use the Netbios protcol driver.
2.) Do this: in protocol.ini, under [tcpbeui_nif], specify:
OS2TRACEMASK = 0x07FF. If you now enable trace (TRACEBUF in config.sys
and the assicated tracefmt.exe viewer) you can see Netbios calls in the
trace.
Additionally, in package IPx8414 you will find a tool called
SMBTOOL.EXE. That's a Netbios tracing tool that'll show you all traffic
(SMB packets and Netbios packets, whatever that means).
Lars
Alex Taylor
> 1.) It's really enought to ONLY install "Netbios via TCP/IP". This will
> implicitely install and use the Netbios protcol driver.
This may be literally true, but I think you risk confusion here. I suspect
when the OP refers to 'NETBIOS' he actually means NETBEUI (i.e. the
protocol known as 'IBM OS/2 NETBIOS', not the actual NETBIOS.OS2 driver),
which certainly isn't included in TCPBEUI.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
m...@privacy.net
>On Mon, 1 Jun 2009 14:31:26 UTC, Lars Erdmann <lars.e...@arcor.de>
>wrote:
>> 1.) It's really enought to ONLY install "Netbios via TCP/IP". This will
>> implicitely install and use the Netbios protcol driver.
>This may be literally true, but I think you risk confusion here. I
>suspect when the OP refers to 'NETBIOS' he actually means NETBEUI (i.e.
>the protocol known as 'IBM OS/2 NETBIOS', not the actual NETBIOS.OS2
>driver), which certainly isn't included in TCPBEUI.
You are correct, I should have referred to the other systems as using
NETBEUI for their connections. Given this I assume that the tracing
options Lars referred to would not enable me to determine why the new
system does not work with that protocol and must use TCPBEUI for its
connection to the domain controller.
As I also noted in my previous posting, determining why NETBEUI isn't
working with the new system is of secondary importance at this point as
TCPBEUI is now doing the job. Thanks to all on the group who gave me
pointers that lead to me determining where the problem was.
Lars Erdmann
> On Mon, 1 Jun 2009 14:31:26 UTC, Lars Erdmann <lars.e...@arcor.de> wrote:
>
>> 1.) It's really enought to ONLY install "Netbios via TCP/IP". This will
>> implicitely install and use the Netbios protcol driver.
>
> This may be literally true, but I think you risk confusion here. I suspect
> when the OP refers to 'NETBIOS' he actually means NETBEUI (i.e. the
> protocol known as 'IBM OS/2 NETBIOS', not the actual NETBIOS.OS2 driver),
> which certainly isn't included in TCPBEUI.
>
>
use TCP/IP. If you DO also use TCP/IP, adding "IBM OS/2 NETBIOS over
TCP/IP" will add all NETBIOS functionality with TCP/IP being the lower
level transport protocol. The latter protocol loads TCPBEUI.OS2 while
the former loads NETBEUI.OS2 but BOTH load NETBIOS.OS2.
At least it works here (but I am using PEER only). I think the best way
to go is to ONLY use "IBM OS/2 NETBIOS over TCP/IP" on ALL boxes (and
WinXP also supports that).
If I am wrong please correct me.
Lars