Bug 462151 - CIFS over IPv6
Summary: CIFS over IPv6
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-13 01:07 UTC by Jeff Layton
Modified: 2014-06-18 07:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-05 23:10:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch -- use the right value when checking the length of IP address string during mount (2.46 KB, patch)
2009-06-01 19:04 UTC, Jeff Layton
no flags Details | Diff

Description Jeff Layton 2008-09-13 01:07:21 UTC
Placeholder ticket to make sure that we get CIFS over IPv6 working for RHEL6. There's a fair bit of IPv6 code in CIFS already, but I've never tested it. Make sure to do so and make sure that it works. Consider updating the documentation with information about how to force usage of IPv6 with CIFS.

Comment 1 Jeff Layton 2008-09-29 19:18:22 UTC
Did a quick test of this last night and IPv6 seems to work OK in CIFS. We might need to do some work to make it easier to specify that you want to use ipv6 with the userspace helper, but that shouldn't be too tough. We probably also need to make sure that krb5 over ipv6 also works (I haven't tested that).

Comment 2 Bug Zapper 2008-11-26 03:03:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Charles R. Anderson 2009-04-10 16:26:09 UTC
Fedora 10 CIFS client, kernel 2.6.27.21-170.2.56.fc10.i686
Fedora 9 Samba server, kernel 2.6.27.21-78.2.41.fc9.i686

Fedora 10 CIFS client fails to connect to Fedora 9 samba server.  My server's hostname has both A and AAAA records, and it fails to connect if I specify a hostname.  If I use the IPv4 address directly, the mount succeeds.

F10-client# host bar.host.name
bar.host.name has address 10.11.12.13
bar.host.name has IPv6 address 2001:DB8::10

F10-client# mount -o username=foo -t cifs //bar.host.name/foo /home/foo/mnt
Password: 
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

F10-client# mount -o username=foo -t cifs //2001:DB8::10/foo /home/foo/mnt
Password: 
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

F10-client# mount -o username=foo -t cifs //10.11.12.13/foo /home/foo/mnt
Password: 

success...

The Fedora 9 server is listening on an IPv6 socket:

F9-server# netstat -nlp | grep smb
tcp        0      0 :::139                      :::*                        LISTEN      2382/smbd           
tcp        0      0 :::445                      :::*                        LISTEN      2382/smbd           

From the Fedora 10 client, I can successfully telnet to the server's IPv6 address on ports 139 and 445:

F10-client# telnet 2001:DB8::10 139
Trying 2001:DB8::10...
Connected to 2001:DB8::10.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

F10-client# telnet 2001:DB8::10 445
Trying 2001:DB8::10...
Connected to 2001:DB8::10.
Escape character is '^]'.
^]
telnet> quit

When the hostname-based mount fails, the smbd server doesn't log anything (log level = 9 in /etc/samba/smb.conf).

A wireshark capture confirms that the client never initiates any network traffic when attempting the IPv6 mount.

A strace on "mount.cifs" shows the failure of the mount system call:

mount("//2001:DB8::10/foo", "/home/foo/mnt", "cifs", MS_MANDLOCK, "unc=//2001:DB8::10"...) = -1 EINVAL (Invalid argument)

Comment 4 Charles R. Anderson 2009-04-13 15:06:01 UTC
dmesg shows these errors from my mount attempts:

CIFS: ip address too long
 CIFS VFS: cifs_mount failed w/return code = -22
CIFS: ip address too long
 CIFS VFS: cifs_mount failed w/return code = -22
mount.cifs[14564]: segfault at 0 ip 00593564 sp bfe6daf0 error 4 in mount.cifs[590000+7000]
CIFS: ip address too long
 CIFS VFS: cifs_mount failed w/return code = -22

Comment 5 Jeff Layton 2009-04-13 15:14:23 UTC
Can you strace mount.cifs again, this time with a longer "-s" value (maybe "-s 256" or so)? I need to see the entire options string that's being passed in.

Comment 6 Jeff Layton 2009-06-01 11:00:26 UTC
Ping, any more word on this?

Comment 7 Charles R. Anderson 2009-06-01 12:35:16 UTC
I know it still fails on F11 client.  I'll try the strace -s 256 today.

Comment 8 Charles R. Anderson 2009-06-01 15:19:49 UTC
client:
kernel-2.6.29.3-142.fc11.x86_64

mount("//bar.host.name/cra", "/home/cra/mnt", "cifs", MS_MANDLOCK, "unc=//bar.host.name\\cra,user=cra,pass=foobar,ver=1,ip=2001:db8:abc:def:012:3456:789a:bcde") = -1 EINVAL (Invalid argument)

dmesg:

CIFS: ip address too long
 CIFS VFS: cifs_mount failed w/return code = -22

Comment 9 Jeff Layton 2009-06-01 19:04:43 UTC
Created attachment 346123 [details]
patch -- use the right value when checking the length of IP address string during mount

I think this patch will fix the problem. If you're able to test it, please do and report back with the results. Thanks!

Comment 10 Charles R. Anderson 2009-06-06 16:26:20 UTC
The patch fixes the problem for me.  Thanks!

Comment 11 Jeff Layton 2009-06-09 16:55:35 UTC
Good to hear, thanks for testing it. It should make it into 2.6.31.

I think the only remaining piece is to make this work for link-local addresses. Simo Sorce has rolled up a nss module that parses the ipv6-literal.net syntax.

I'm thinking that we can probably just send a numerical scope-id after a '%' in the IPv6 address. Alternately we could declare a new "ipv6scope=" option. That's a little more ugly but may be better for backward compatibility.

Comment 12 Jeff Layton 2009-07-05 23:10:10 UTC
Upstream support for link-local addresses is now in place. That should be the last fix to make IPv6 support work. Closing with resolution of UPSTREAM.


Note You need to log in before you can comment on or make changes to this bug.