Bug 3822 - connection to OS400 (IBM iSeries)
connection to OS400 (IBM iSeries)
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P3 major
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-02 02:21 UTC by Andreas Bichler
Modified: 2009-05-14 15:21 UTC (History)
3 users (show)

See Also:


Attachments
binary file about the connection - request (117 bytes, application/octet-stream)
2006-06-02 02:23 UTC, Andreas Bichler
no flags Details
binary file about the connection - response (154 bytes, application/octet-stream)
2006-06-02 02:24 UTC, Andreas Bichler
no flags Details
new try request binary (117 bytes, application/octet-stream)
2006-06-06 02:36 UTC, Andreas Bichler
no flags Details
new try response binary (154 bytes, application/octet-stream)
2006-06-06 02:37 UTC, Andreas Bichler
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Bichler 2006-06-02 02:21:31 UTC
the mount command:
mount.cifs //iSeries/share /mountpoint response a errormessages.
mount error 112 = Host is down.

the old mount command 
mount -t smbfs //iSeries/share /mountpoint works properly
Comment 1 Andreas Bichler 2006-06-02 02:23:49 UTC
Created attachment 1940 [details]
binary file about the connection - request
Comment 2 Andreas Bichler 2006-06-02 02:24:20 UTC
Created attachment 1941 [details]
binary file about the connection - response
Comment 3 Steve French 2006-06-02 13:38:22 UTC
I did not notice this problem in mounting to OS/400 server but did notice that share names typically have to be uppercased (due to a return code mapping problem, the return code sent back by the OS/400 server was mapped to the same error as "cifs filesystem not supported" so the cifs mount helper does not automatically retry with uppercase share name as the server expects)

I have fixed the return code mapping problem (will be in 2.6.18 Linux kernel and cifs version 1.44)

I was not able to read your ethereal trace it appears corrupted(you should be able to save the file once - which includes request and response directly from the ethereal menus). On your error "host is down" - please check two things:
1) that you can ping the name "iSeries"
and if that works can you try mounting to its ip address directly
e.g.
2) mount -t cifs //10.20.30.40/SHARE /mnt -o user=your_user,pass=your_password
Comment 4 Steve French 2006-06-02 14:11:50 UTC
Also note that to mount port 445 (preferred) or port 139 needs to be open on both server and client sides (unless you override the ports on mount - which is quite rare).
Comment 5 Andreas Bichler 2006-06-06 02:36:46 UTC
Created attachment 1949 [details]
new try request binary
Comment 6 Andreas Bichler 2006-06-06 02:37:29 UTC
Created attachment 1950 [details]
new try response binary
Comment 7 Andreas Bichler 2006-06-06 02:48:12 UTC
Dear Steve,
i tried to mount like you said. ..here is the konsole output:
[root@laptop ~]# ping as400
PING as400.rolandberger.net (172.20.23.10) 56(84) bytes of data.
64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=1 ttl=61 time=16.8 ms
64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=2 ttl=61 time=1.18 ms
64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=3 ttl=61 time=1.20 ms
^C64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=4 ttl=61 time=1.25 ms

--- as400.rolandberger.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 1.180/5.126/16.858/6.773 ms
[root@laptop ~]# mount.cifs //172.20.23.10/BICHLER /mnt/Bichler/ -o username=bichlera,password=PASSWORD
mount error 112 = Host is down
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
[root@laptop ~]#
[root@laptop ~]# tail -n 5 /var/log/messages
Jun  6 09:38:57 laptop kernel:  CIFS VFS: Calculated size 0x5a vs actual length 0x58
Jun  6 09:38:57 laptop kernel:  CIFS VFS: bad smb size detected for Mid=1
Jun  6 09:38:57 laptop kernel:
Jun  6 09:39:15 laptop kernel:  CIFS VFS: No response for cmd 114 mid 1
Jun  6 09:39:15 laptop kernel:  CIFS VFS: cifs_mount failed w/return code = -112


Thanks
Andi







Comment 8 Steve French 2006-11-10 09:48:08 UTC
Just tried mount to OS/400 Netserve and do not see this a problem with their negotiate protocol response - I wonder if it has been fixed in netserve os/400 code.
Comment 9 Peter Fröhlich 2006-11-14 05:44:05 UTC
We are running in the same problem as descriped. Here is a trace: 
(I xxxed the IP)

Nov 14 12:35:20 ids2 kernel:  fs/cifs/cifsfs.c: Devname: //xxx.xxx.xxx.xxx/ROOT flags: 64
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 12 with uid: 0
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: Username: FEP
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: UNC: \\xxx.xxx.xxx.xxx\ROOT ip: xxx.xxx.xxx.xxx
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: Socket created
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffff
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: Demultiplex PID: 17782
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: Existing smb sess not found
Nov 14 12:35:20 ids2 kernel:  fs/cifs/transport.c: For smb_command 114
Nov 14 12:35:20 ids2 kernel:  fs/cifs/transport.c: Sending smb of length 47
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x2f 0xff 0x53 0x4d 0x42  |  _ _ _ / 377 S M B
Nov 14 12:35:20 ids2 kernel: | 0x72 0x00 0x00 0x00 0x00 0x00 0x01 0x80  |  r _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00  |  _ _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x75 0x45  |  _ _ _ _ _ _ u E
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x01 0x00 0x00 0x0c 0x00 0x02  |  _ _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x4e 0x54 0x20 0x4c 0x4d 0x20 0x30 0x2e  |  N T   L M   0 .
Nov 14 12:35:20 ids2 kernel: | 0x31 0x32 0x00                           |  1 2 _
Nov 14 12:35:20 ids2 kernel:  fs/cifs/connect.c: rfc1002 length 0x58)
Nov 14 12:35:20 ids2 kernel: | 0x54 0x00 0x00 0x00 0xff 0x53 0x4d 0x42  |  T _ _ _ 377 S M B
Nov 14 12:35:20 ids2 kernel: | 0x72 0x00 0x00 0x00 0x00 0x80 0x01 0x80  |  r _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00  |  _ _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x75 0x45  |  _ _ _ _ _ _ u E
Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x01 0x00 0x11 0x00 0x00 0x03  |  _ _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x05 0x00 0x01 0x00 0x00 0x10 0x00 0x00  |  _ _ _ _ _ _ _ _
Nov 14 12:35:20 ids2 kernel: | 0x00 0x10 0x00 0x00 0x2d 0xae 0x00 0x00  |  _ _ _ _ - 256 _ _
Nov 14 12:35:20 ids2 kernel: | 0x1d 0xc2 0x00 0x00 0x80 0xe6 0x5a 0x0f  |  _ 302 _ _ _ 346 Z _
Nov 14 12:35:20 ids2 kernel: | 0xe1 0x07 0xc7 0x01 0x88 0xff 0x08 0x11  |  341 _ 307 _ _ 377 _ _
Nov 14 12:35:20 ids2 kernel: | 0x00 0x32 0x5c 0x91 0xfa 0x98 0x49 0x8e  |  _ 2 \ _ 372 _ I _
Nov 14 12:35:20 ids2 kernel: | 0x1f 0x00 0x00 0x00 0xd8 0xc7 0x81 0x00  |  _ _ _ _ 330 307 _ _
Nov 14 12:35:20 ids2 kernel:  |  _ _ _ _ 330 307 _ _
Nov 14 12:35:20 ids2 kernel:  CIFS VFS: Calculated size 0x5a vs actual length 0x58
Nov 14 12:35:20 ids2 kernel:  CIFS VFS: bad smb size detected for Mid=1
Nov 14 12:35:20 ids2 kernel: Bad SMB: : dump of 48 bytes of data at 0xe50b1100
Nov 14 12:35:20 ids2 kernel:
Nov 14 12:35:20 ids2 kernel:  00000054 424d53ff 00000072 80018000 T . . . 377 S M B r . . . . . . .
Nov 14 12:35:20 ids2 kernel:  00000000 00000000 00000000 45750000 . . . . . . . . . . . . . . u E
Nov 14 12:35:20 ids2 kernel:  00010000 03000011 00010005 00001000 . . . . . . . . . . . . . . . .
Nov 14 12:35:38 ids2 kernel:  CIFS VFS: No response for cmd 114 mid 1
Nov 14 12:35:38 ids2 kernel:  fs/cifs/transport.c: marking request for retry
Nov 14 12:35:38 ids2 kernel:  fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
Nov 14 12:35:38 ids2 kernel:  fs/cifs/transport.c: tcp session dead - return to caller to retry
Nov 14 12:35:38 ids2 kernel:  fs/cifs/connect.c: No session or bad tcon
Nov 14 12:35:38 ids2 kernel:  fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 12) rc = -112
Nov 14 12:35:38 ids2 kernel:  CIFS VFS: cifs_mount failed w/return code = -112
Comment 10 Steve French 2006-11-16 15:04:23 UTC
The server I tried claimed a verison of OS400 V5R4M0

What is the version number of your OS400 Netserver?

Is there an OS/400 bug number (APAR or PMR number) I could correlate
this with?

It looks like a malformed response, but it would be good to know
if it is alread fixed on the server.
Comment 11 Peter Fröhlich 2006-11-17 07:10:33 UTC
(In reply to comment #10)
> The server I tried claimed a verison of OS400 V5R4M0
> What is the version number of your OS400 Netserver?
> Is there an OS/400 bug number (APAR or PMR number) I could correlate
> this with?
> It looks like a malformed response, but it would be good to know
> if it is alread fixed on the server.

We use V5R2. 
I don´t know about a bug number, but maybe it is fixed with V5R4. Sadly, updating is out of the question at this time... 
Comment 12 Phil_krebs 2007-04-06 15:56:49 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > The server I tried claimed a verison of OS400 V5R4M0
> > What is the version number of your OS400 Netserver?
> > Is there an OS/400 bug number (APAR or PMR number) I could correlate
> > this with?
> > It looks like a malformed response, but it would be good to know
> > if it is alread fixed on the server.
> We use V5R2. 
> I don´t know about a bug number, but maybe it is fixed with V5R4. Sadly,
> updating is out of the question at this time... 

There is a PTF in V5R3 of OS/400 (MF40347), but I had applied the V5R2 patch related to this prior to my release upgrade.  Don't know if it will solve your problem........
Comment 13 Steve French 2007-07-21 21:04:52 UTC
I was trying to cleanup old bugs, and in looking at this was trying to examine the  trace files - none of them are readable by standard tools.  Can you simply capture these with wireshark or tcpdump from the client so we can make 100% sure that this is a server bug (presumably long since fixed).

http://wiki.samba.org/index.php/Capture_Packets
Comment 14 Bill Marshall 2009-02-24 11:19:54 UTC
Still seeing the uppercase problem testing against v6r1 w/ 
#   /sbin/mount.cifs -V -h
mount.cifs version: 1.10

[root@rchs3bld ~]# mount.cifs //9.1.2.3/books /mnt -o username=x, password=pass
mount error 6 = No such device or address
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
[root@rchs3bld ~]# mount.cifs //9.1.2.3/BOOKS /mnt -o username=x, password=x

will test w/ newer cifs code
Comment 15 Bill Marshall 2009-02-24 14:42:37 UTC
Still seeing the upper/lowercase thing w/ a test kernel from jlayton

# uname -a
Linux xxx 2.6.18-132.el5.jtltest.64 #1 SMP Sun Feb 22 
17:38:13 EST 2009 i686 i686 i386 GNU/Linux

# mount.cifs //9.1.2.3/books /mnt -o username=x,password=y
mount error 6 = No such device or address
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

# mount.cifs //9.1.2.3/BOOKS /mnt -o username=x,password=y


Comment 16 Jeff Layton 2009-02-24 14:53:02 UTC
The auto-uppercasing thing is done by mount.cifs. You may want to try that on a more recent mount.cifs version. In particular, you may need:

commit dd9002cf498e177b769eabd2fed40213069cd239
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Oct 9 09:58:39 2008 -0400

    mount.cifs: have uppercase_string return success on NULL pointer
    
    We currently don't attempt to uppercase the device portion of the mount
    string if there isn't a prefixpath. Fix that by making uppercase_string
    return success without doing anything on a NULL pointer.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>

Comment 17 Steve French 2009-05-14 15:21:49 UTC
uppercasing of sharename is now autoretried by mount.cifs and can be entered on mount (in all uppercase) to workaround for older mount.cifs