Highlighted
JohnPals Absent Member.
Absent Member.
4803 views

Windows Client doesn't see tree (SLP problem)

Dear community,

A long time ago we used Novell Netware and moved to Microsoft Active Directory, but since playing with Novell OES recently I decided to move back and drop MS AD. Our network has changed over the years and we are now using a segmented network.

In my test scenario I had the server (Linux OES 11) in the same vlan as the client. So when I browsed the tree I could easily find the tree name, context and server. But now, in a live scenario, the server is in vlan 10 (10.0.10.x) and the rest of the network is segmented in other vlan's. For example we have vlan 500 (10.50.0.x) where clients reside and they are able to ping the server, but we cannot browse the tree. Obviously this is because of multicasting not being able to reach outside of vlan 10.

I tried this: https://www.novell.com/support/kb/doc.php?id=7012387 (Can't login with Novell Client due to SLP problems), but this didn't help. When I enable DA and SA on the server and configure the Novell Client's Service Location tab, I still cannot see the tree. slpinfo /a doesn't see the tree either.

What am I missing? Could you point me in the right direction please?

Kind regards, John
Labels (2)
Tags (3)
0 Likes
12 Replies
JohnPals Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

I can't seem to edit my post, so I'll reply with extra info:

This is what I see when I do "slpinfo /a" on a Windows 7 client:

Novell Client Service Location Diagnostic Utility
SLPInfo 5.0.63.5695


============ Directory Agents ============
DA IP Address Host Name

=============== Scope List ===============
DEFAULT

================= Trees ==================
Tree Name IP Address

================ Servers =================
Server Name IP Address


Scenario:

Server: vlan 10 (IP: 10.0.10.60, MASK: 255.255.255.0, GW: 10.0.10.1)
Client: vlan 50 (IP: 10.50.0.123, MASK: 255.255.255.0, GW: 10.50.0.1)

Client can ping to server
DA and SA are configured in /etc/slp.conf on the server
Client has been configured via Service Location tab (DA is set to 10.0.10.60)
If I put a client on the same vlan as the server, the client does see the tree.
"slptool findsrvs service:ndap.novell" on the server gives proper feedback, so SLP looks good.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Windows Client doesn't see tree (SLP problem)

I'd probably start by running tcpdump or something on the server side to
see if the SLP requests are being received and answered by the server.
Here's an example:

Code:
--------------------
sudo /usr/sbin/tcpdump -n -s 0 -i any -vv port 427
--------------------

If you see something coming in from your client, then hopefully you also
see something going back out. If you either see both directions, or you
see nothing, your network is probably blocking things . If you see data
coming in but not going out, well that's a bit odd and we'll need more
information about the server's networking configuration. For example:

Code:
--------------------
ip addr
ip route
ip -s link
grep -v '^#' /etc/resolv.conf
sudo /usr/sbin/iptables-save
--------------------

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
JohnPals Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

Thank you for replying. This is what I see when I enter "slpinfo /a" on the client:


tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
09:22:48.346298 IP (tos 0x0, ttl 125, id 1430, offset 0, flags [DF], proto TCP (6), length 52) 10.50.0.23.60492 > 10.0.10.60.427: S, cksum 0x4c9c (correct), 1963426032:1963426032(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
09:22:48.346330 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 10.0.10.60.427 > 10.50.0.23.60492: S, cksum 0x16d7 (correct), 1730140103:1730140103(0) ack 1963426033 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 5>
09:22:48.347359 IP (tos 0x0, ttl 125, id 1431, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.60492 > 10.0.10.60.427: ., cksum 0x6d77 (correct), 1:1(0) ack 1 win 256
09:22:48.347470 IP (tos 0x0, ttl 125, id 1432, offset 0, flags [DF], proto TCP (6), length 89) 10.50.0.23.60492 > 10.0.10.60.427: P, cksum 0x6f0c (correct), 1:50(49) ack 1 win 256
09:22:48.347476 IP (tos 0x0, ttl 64, id 44390, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.60492: ., cksum 0x6d8f (correct), 1:1(0) ack 50 win 183
09:22:48.347493 IP (tos 0x0, ttl 64, id 44391, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.60492: F, cksum 0x6d8e (correct), 1:1(0) ack 50 win 183
09:22:48.348341 IP (tos 0x0, ttl 125, id 1433, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.60492 > 10.0.10.60.427: ., cksum 0x6d45 (correct), 50:50(0) ack 2 win 256
09:22:48.348464 IP (tos 0x0, ttl 125, id 1434, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.60492 > 10.0.10.60.427: F, cksum 0x6d44 (correct), 50:50(0) ack 2 win 256
09:22:48.348467 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.60492: ., cksum 0x6d8d (correct), 2:2(0) ack 51 win 183
09:22:51.364705 IP (tos 0x0, ttl 125, id 1495, offset 0, flags [DF], proto TCP (6), length 52) 10.50.0.23.51388 > 10.0.10.60.427: S, cksum 0x5713 (correct), 3558161147:3558161147(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
09:22:51.364733 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 10.0.10.60.427 > 10.50.0.23.51388: S, cksum 0x61d9 (correct), 4163044920:4163044920(0) ack 3558161148 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 5>
09:22:51.366033 IP (tos 0x0, ttl 125, id 1496, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.51388 > 10.0.10.60.427: ., cksum 0xb879 (correct), 1:1(0) ack 1 win 256
09:22:51.366041 IP (tos 0x0, ttl 125, id 1497, offset 0, flags [DF], proto TCP (6), length 89) 10.50.0.23.51388 > 10.0.10.60.427: P, cksum 0xba0c (correct), 1:50(49) ack 1 win 256
09:22:51.366043 IP (tos 0x0, ttl 64, id 31640, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.51388: ., cksum 0xb891 (correct), 1:1(0) ack 50 win 183
09:22:51.366071 IP (tos 0x0, ttl 64, id 31641, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.51388: F, cksum 0xb890 (correct), 1:1(0) ack 50 win 183
09:22:51.367024 IP (tos 0x0, ttl 125, id 1498, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.51388 > 10.0.10.60.427: ., cksum 0xb847 (correct), 50:50(0) ack 2 win 256
09:22:51.367132 IP (tos 0x0, ttl 125, id 1499, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.51388 > 10.0.10.60.427: F, cksum 0xb846 (correct), 50:50(0) ack 2 win 256
09:22:51.367136 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.51388: ., cksum 0xb88f (correct), 2:2(0) ack 51 win 183
09:22:54.547015 IP (tos 0x0, ttl 125, id 1542, offset 0, flags [DF], proto TCP (6), length 52) 10.50.0.23.53114 > 10.0.10.60.427: S, cksum 0x6c7a (correct), 1144237752:1144237752(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
09:22:54.547041 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 10.0.10.60.427 > 10.50.0.23.53114: S, cksum 0xdf70 (correct), 3822170713:3822170713(0) ack 1144237753 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 5>
09:22:54.548219 IP (tos 0x0, ttl 125, id 1543, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.53114 > 10.0.10.60.427: ., cksum 0x3611 (correct), 1:1(0) ack 1 win 256
09:22:54.548343 IP (tos 0x0, ttl 125, id 1544, offset 0, flags [DF], proto TCP (6), length 89) 10.50.0.23.53114 > 10.0.10.60.427: P, cksum 0x5171 (correct), 1:50(49) ack 1 win 256
09:22:54.548348 IP (tos 0x0, ttl 64, id 13030, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.53114: ., cksum 0x3629 (correct), 1:1(0) ack 50 win 183
09:22:54.548366 IP (tos 0x0, ttl 64, id 13031, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.53114: F, cksum 0x3628 (correct), 1:1(0) ack 50 win 183
09:22:54.549342 IP (tos 0x0, ttl 125, id 1545, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.53114 > 10.0.10.60.427: ., cksum 0x35df (correct), 50:50(0) ack 2 win 256
09:22:54.549465 IP (tos 0x0, ttl 125, id 1546, offset 0, flags [DF], proto TCP (6), length 40) 10.50.0.23.53114 > 10.0.10.60.427: F, cksum 0x35de (correct), 50:50(0) ack 2 win 256
09:22:54.549468 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 10.0.10.60.427 > 10.50.0.23.53114: ., cksum 0x3627 (correct), 2:2(0) ack 51 win 183
^C
27 packets captured
27 packets received by filter
0 packets dropped by kernel


Does this make sense? Seems like stuff is being sent back to the client, right?
By the way, I don't see anything happening when slpinfo is doing something with tree and servers... You would expect data then also, right?
0 Likes
Knowledge Partner
Knowledge Partner

Re: Windows Client doesn't see tree (SLP problem)

> Does this make sense? Seems like stuff is being sent back to the client,
> right?


Yes, exactly. The client connects via TCP, some data is requested and a
response is sent back, disconnected. Three seconds later, do something
that looks the same. Three seconds later, do something similar again.

> By the way, I don't see anything happening when slpinfo is doing
> something with tree and servers... You would expect data then also,
> right?


I'm not sure what you mean; wasn't the traffic above captured while using
slpinfo?

If you put in the tree, server and context manually into the Novell Client
login fields, can you login even though you think SLP is not working?
Have you tried doing any network tests from your client network to your
server network for NCP on TCP 524?

The next step may be to do the same tcpdump as before but add '-w
/tmp/slp.cap' so you can post the capture file fro somebody to check out.
Here's an example that may be useful:

Code:
--------------------
sudo /usr/sbin/tcpdump -n -s 0 -i any -w /tmp/slp.cap port 427 or port 524
--------------------

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
JohnPals Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

ab;2320452 wrote:

I'm not sure what you mean; wasn't the traffic above captured while using
slpinfo?


My bad, I thought nothing was happening while a tree discovery was active, but I was wrong.

ab;2320452 wrote:

If you put in the tree, server and context manually into the Novell Client
login fields, can you login even though you think SLP is not working?


That doesn't work, I cannot login. When I use the IP address of the server in the tree name field though, I can login.

ab;2320452 wrote:

Have you tried doing any network tests from your client network to your
server network for NCP on TCP 524?


Not sure what you mean, but I'll dig into this.
0 Likes
JohnPals Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

Isn't it strange that when you fill in the IP address of a DA server in the Novell Client, it doesn't appear in slpinfo?

Novell Client Service Location Diagnostic Utility
SLPInfo 5.0.63.5695


============ Directory Agents ============
DA IP Address Host Name

=============== Scope List ===============
DEFAULT

================= Trees ==================
Tree Name IP Address

================ Servers =================
Server Name IP Address
0 Likes
JohnPals Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

We have been working on this issue the whole day. We've reinstalled the linux server, we've even installed a Windows server with eDirectory on it. But no luck, there seems to be no way to get the tree info. Needless to say that this is very frustrating. If somebody could point us to a direction where too look it would be most helpful, because currently I'm out of ideas... 😞
0 Likes
Knowledge Partner
Knowledge Partner

Re: Windows Client doesn't see tree (SLP problem)

Can you post the captured LAN trace file? There may be a clue to be found
if looking at the actual data sent after the client and server start
communicating.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

On Mon, 26 May 2014 17:56:01 +0000, JohnPals wrote:

> I tried this: https://www.novell.com/support/kb/doc.php?id=7012387
> (Can't login with Novell Client due to SLP problems), but this didn't
> help. When I enable DA and SA on the server and configure the Novell
> Client's Service Location tab, I still cannot see the tree. slpinfo /a
> doesn't see the tree either.


After configuring SLP, did you start the OpenSLP DA, then restart
eDirectory? I think that's the order you need to do it in, so that the
services get registered with the DA.


> What am I missing? Could you point me in the right direction please?


These are pretty good documents to read:

http://www.novell.com/support/kb/doc.php?id=7002120

http://www.novell.com/support/kb/doc.php?id=7002142

They're a bit dated, but if you ignore the references to "NetWare",
they're still basically true. This one:

https://www.netiq.com/support/kb/doc.php?id=3618930

is also pretty good.



--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows Client doesn't see tree (SLP problem)

On Mon, 26 May 2014 18:16:01 +0000, JohnPals wrote:

> I can't seem to edit my post, so I'll reply with extra info:
>
> This is what I see when I do "slpinfo /a" on a Windows 7 client:
>
>> Novell Client Service Location Diagnostic Utility SLPInfo 5.0.63.5695
>>
>>
>> ============ Directory Agents ============
>> DA IP Address Host Name


That seems wrong to me. If your client doesn't think it has a DA, then
nothing based on using the DA is going to work.


> "slptool findsrvs service:ndap.novell" on the server gives proper
> feedback, so SLP looks good.


Interesting. In that case, I'm going to guess this is a client
configuration problem. There's a clients support forum which might be a
better place to ask this, if the server side is working, which it seems
to be, and the client side isn't.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
JohnPals Absent Member.
Absent Member.

SOLVED: Windows Client doesn't see tree (SLP problem)

David Gersic;2320548 wrote:

Interesting. In that case, I'm going to guess this is a client
configuration problem. There's a clients support forum which might be a
better place to ask this, if the server side is working, which it seems
to be, and the client side isn't.


Wauw, I tried *everything* for the last couple of days and I didn't succeed. I reinstalled the server (Suse Linux), I even installed Microsoft Windows to test eDirectory on it. But one thing I didn't try: a reinstallation of the client. Thank you David for pointing me in the right direction, because after a fresh installation everything works! I'm so happy now!

THANK YOU!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.