as/400 IFS and cifsclient

[Gavin Clarke]

It has to be the NetBIOS name of the server.

However if smbclient works then I would think that you've got a name that works.

[Patrick Provenzo]

Going back to Eric's post here is the info from the AS/400 side on the software that it is running:

OS=[OS/400 V5R3M0] Server=[iSeries Support for Windows Network Neighborhood]

Also, I noticed when I run smbclient to connect to the AS/400, I do get the "called name not present" error, but it continues to allow me to login. Here is what I see when I use smbclinet to connect:

oot@grtux12# ./smbclient //DEVAS01/QIBM -U E0026887
added interface ip=166.99.3.161 bcast=166.99.3.255 nmask=255.255.255.0
session request to DEVAS01 failed (Called name not present)
Password:
Domain=[S105F6HM] OS=[OS/400 V5R3M0] Server=[iSeries Support for Windows Network Neighborhood]

[Eric Raeburn]

Patrick,

I agree with Gavin. It looks very much like the NetBIOS name of the server is different than its DNS name. That is what the NetBIOS "negative session response" would indicate. You are able to establish a TCP connection because you have the DNS name--you can see this in the output of tcpdump. But it's complaining about the NetBIOS name.

I suggest the following:

1. Check with the administrator of the server to see how NetBIOS name is configured on the server.

2. Also find out from the administrator if the server's CIFS software supports NetBIOS at all. It is possible to run the CIFS (SMB) protocol directly over TCP/IP, without the NetBIOS layer. My colleague on the HP CIFS Server team informs me that this in fact is the ONLY mode in which Samba 4 runs. If this is the case for the CIFS server running on the AS/400, then we (the HP CIFS Client team) would need to implement this feature as an enhancement in order to interoperate with that server (this actually is on our list of things to do). You could test this by trying to map a drive from a Windows NT system, if you have one. Native NT (I don't know about later service packs) does not support NetBIOS over TCP, so it would be instructive to know if NT does the same as your other Windows client, or the HP CIFS Client.

If 1. and 2. don't solve it, then...

3. A tcpdump or (t)ethereal trace from the PC, when is is mapping a drive, would also be useful.

And finally...

4. Consider opening a support call with HP. The direct contact would probably be a more efficient way to zero in on the root cause.

[Patrick Provenzo]

Thaks, Eric. I'll ask the AS/400 guys for the info you suggested. I actually did enter a support case on this before ever trying the mount and the response I got was basically that If it works great if not HP does not support the use of the cifsclient software in this way. That's why I tried the forums.

[Eric Raeburn]

Patrick,

We officially support only a limited set of CIFS Servers, so the support person to whom you spoke was probably going strictly by this list. However, interoperability is a major priority for us, and we have changed our code many times to ensure that we work with other servers (working around an IBM bug was one of these!). If the information you get from the as/400 admin does not solve the case, please call HP support again and tell them the lab said to take your call and to pass it up to the next level of support.

Thanks,
Eric

[Patrick Provenzo]

Thanks, Eric. I'll do that

[Gavin Clarke]

Patrick and Eric,

Perhaps you could post the eventual resolution to this here please?

That way if anyone else searches for it they will find the answer.

[Patrick Provenzo]

Checked with my AS/400 admin. It appears the AS/400 does not support netBIOS at all.

[Eric Raeburn]

Patrick,

Not to belabor the details, but I want to ensure we have not missed anything. In particular, it is not a matter of the as/400 itself supporting NetBIOS, but the CIFS server software that is running on it. Please ensure that the administrator of the system understands this distinction.

As I mentioned previously, a good way to verify this is by using an NT client to map a drive to the share on the as/400; a 'tcpdump' trace of this would be helpful. Best would be to tell tcpdump to capture entire packets, and use tethereal (part of the ethereal software suite) to produce a fully exploded protocol tree of each packet, in ascii, and saved to a file. Then attach the file to a message in this thread.

The "SMB-over-TCP" feature will probably be available on the HP CIFS Client some time in 2006. Not what you wanted to hear. But I suggest you ensure there is no confusion on the NetBIOS support issue above.

-Eric

[Patrick Provenzo]

Here is the response that I got from my AS/400 guy after he double checked with IBM:

The Iseries "emulates" a netbios for Windows over tcpip using the net server. It is not a true native stack.
I did confirm this with IBM. They recommended Samba. A straight out mount from Unix will not work.

Also We don't have an NT server left to test with.

[Eric Raeburn]

Patrick,

I've been discussing your case with my colleagues. We now believe that this is just a case of the wrong server name used in cifsmount, rather than a NetBIOS support issue. If smbclient can connect, the HP CIFS Client should also be able to connect.

First try this:

From a Windows system, open a DOS window, and enter:

nbtstat -A ip_address_of_server

The server should give a "NetBIOS Remote Machine Name Table". The entry with the designation "<20>" will be the NetBIOS name of the fileserver service. Use the corresponding name as the server name in cifsmount.

If that doesn't work, please reply, and attach a tcpdump trace of the smbclient mounting the server.

Thanks,
Eric

[Patrick Provenzo]

Here are the results of the tcpdump when using smbclient to connect to the AS/400:
tcpdump: listening on lan0, link-type EN10MB (Ethernet), capture size 68 bytes
IP (tos 0x0, ttl 64, id 38506, offset 0, flags [DF], length: 48) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: S [tcp sum ok] 429457827
0:4294578270(0) win 32768
arp who-has grtux12.ch.etn.com tell devas01.ch.etn.com
arp reply grtux12.ch.etn.com is-at 00:60:b0:c1:7d:6c
IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], length: 48) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: S [bad tcp cksum 440 (->d440
)!] 3009542321:3009542349(28) ack 4294578271 win 8192
IP (tos 0x0, ttl 64, id 38507, offset 0, flags [DF], length: 40) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: . [tcp sum ok] 1:1(0) ac
k 1 win 32768
IP (tos 0x0, ttl 64, id 38508, offset 0, flags [DF], length: 112) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: P 1:73(72) ack 1 win 32
768
IP (tos 0x0, ttl 64, id 2, offset 0, flags [DF], length: 44) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P [tcp sum ok] 1:5(4) ack 73
win 32768
IP (tos 0x0, ttl 64, id 38509, offset 0, flags [DF], length: 208) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: P 73:241(168) ack 5 win
32768
IP (tos 0x0, ttl 64, id 3, offset 0, flags [DF], length: 130) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P 5:95(90) ack 241 win 3276
8
IP (tos 0x0, ttl 64, id 38510, offset 0, flags [DF], length: 40) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: . [tcp sum ok] 241:241(0
) ack 95 win 32768
IP (tos 0x0, ttl 64, id 38511, offset 0, flags [DF], length: 214) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: P 241:415(174) ack 95 w
in 32768
IP (tos 0x0, ttl 64, id 4, offset 0, flags [DF], length: 230) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P 95:285(190) ack 415 win 3
2768
IP (tos 0x0, ttl 64, id 38512, offset 0, flags [DF], length: 124) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: P 415:499(84) ack 285 w
in 32768
IP (tos 0x0, ttl 64, id 5, offset 0, flags [DF], length: 40) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P [tcp sum ok] 285:285(0) ac
k 499 win 32768
IP (tos 0x0, ttl 64, id 6, offset 0, flags [DF], length: 93) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P 285:338(53) ack 499 win 32
768
IP (tos 0x0, ttl 64, id 38513, offset 0, flags [DF], length: 40) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: . [tcp sum ok] 499:499(0
) ack 338 win 32768
IP (tos 0x0, ttl 64, id 38514, offset 0, flags [DF], length: 84) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: P 499:543(44) ack 338 wi
n 32768
IP (tos 0x0, ttl 64, id 7, offset 0, flags [DF], length: 40) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P [tcp sum ok] 338:338(0) ac
k 543 win 32768
IP (tos 0x0, ttl 64, id 8, offset 0, flags [DF], length: 79) devas01.ch.etn.com.netbios_ssn > grtux12.ch.etn.com.61374: P 338:377(39) ack 543 win 32
768
IP (tos 0x0, ttl 64, id 38515, offset 0, flags [DF], length: 40) grtux12.ch.etn.com.61374 > devas01.ch.etn.com.netbios_ssn: . [tcp sum ok] 543:543(0
) ack 377 win 32768

20 packets captured
1777 packets received by filter
0 packets dropped by kernel

Also when I run the nbstat command as suggested above I get two records with the <20> designation. One for DEVAS01 nad one for QS105F6HM.

[Patrick Provenzo]

Weird. I tried this from an HP-UX 11.0 server running v 1.09 of cifsclient and was able to get the filesystem to mount. I know I tried this previously on the same 11.0 server and it did not work. It still does not work on 11i.

[Patrick Provenzo]

Well, for those still interested the problem must have been on the AS/400 side. The AS/400 admins moved this server to different hardware and suddenly the cifsmount works. However, they swear they didn't change anything software related during the move. SO it now works for one server, but no guarantee it will work on another AS/400.

[Eric Raeburn]

Patrick,

Congratulations. Even if you are not confident about it working on other AS/400s, this still proves it is a problem with a solution. Further, the solution is configuration, not code change--that is also good news.

When you got it to work, which NetBIOS name did you specify in cifsmount, DEVAS01 or QS105F6HM? And did you need the "-I ip_address" option?

-Eric

[Patrick Provenzo]

I used the DEVAS01 name. It works with and without the -I option.

[Eric Raeburn]

Thanks. If you encounter any other problems don't hesitate to post, or to start a support call. As I mentioned previously, if the support representative tells you it's not a supported server, tell that person that you've been in contact with the lab and we said they should take the call. -E.R.

[Gavin Clarke]

Patrick,

I'm pleased to see that it works, at least in one instance.

Seems like a tricky one, do you have alot of AS/400s to monitor?

[Patrick Provenzo]

Yes. I am going to end up with over a dozen. We are looking into purchasing HP's AS/400 agent for OVO, but one particular app doesn't report errors in a way that agent can pick up. That's why we need to be able to mount the output logs for that app.