linux-kernel - Re: [bisect] kernel 2.6.38 regression with root nfs mounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Mar 2011 10:54:39 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Belisko Marek <marek.belisko@...il.com>
Cc:	Trond.Myklebust@...app.com, broonie@...nsource.wolfsonmicro.com,
	bdowning@...os.net, linux-nfs@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [bisect] kernel 2.6.38 regression with root nfs mounting


On Mar 23, 2011, at 10:30 AM, Belisko Marek wrote:

> On Wed, Mar 23, 2011 at 3:06 PM, Chuck Lever <chuck.lever@...cle.com> wrote:
>> 
>> On Mar 23, 2011, at 9:46 AM, Belisko Marek wrote:
>> 
>>> On Wed, Mar 23, 2011 at 2:44 PM, Chuck Lever <chuck.lever@...cle.com> wrote:
>>>> 
>>>> What does "rpcinfo -p 10.146.1.21" output look like?  Is NFS over UDP enabled on your server?
>>> program vers proto   port
>>>    100000    2   tcp    111  portmapper
>>>    100000    2   udp    111  portmapper
>>>    100024    1   udp  40517  status
>>>    100024    1   tcp  51397  status
>>>    100021    1   udp  44516  nlockmgr
>>>    100021    3   udp  44516  nlockmgr
>>>    100021    4   udp  44516  nlockmgr
>>>    100021    1   tcp  55152  nlockmgr
>>>    100021    3   tcp  55152  nlockmgr
>>>    100021    4   tcp  55152  nlockmgr
>>>    100003    2   tcp   2049  nfs
>>>    100003    3   tcp   2049  nfs
>>>    100003    4   tcp   2049  nfs
>>>    100227    2   tcp   2049
>>>    100227    3   tcp   2049
>>>    100003    2   udp   2049  nfs
>>>    100003    3   udp   2049  nfs
>>>    100003    4   udp   2049  nfs

The server is advertising NFS over UDP.  Why can't a client access your server via UDP?  What happens if you perform a normal post-boot mount of this file system via UDP?

>>>    100227    2   udp   2049
>>>    100227    3   udp   2049
>>>    100005    1   udp  58278  mountd
>>>    100005    1   tcp  37178  mountd
>>>    100005    2   udp  58278  mountd
>>>    100005    2   tcp  37178  mountd
>>>    100005    3   udp  58278  mountd
>>>    100005    3   tcp  37178  mountd
>> 
>> Can you boot if you specify either the "tcp" or "proto=tcp" NFSROOT mount options?
> When add proto=tcp to bootargs it boot fine
> (....nfsroot=10.146.1.21:/home/open-nandra/rootfs,proto=tcp....).
>> Perhaps a network trace would be probative.  Capture on the server with "tcpdump -s0 -w /tmp/foo ip 10.146.1.199" (untested, but I think you get the idea) while the client is attempting to boot, and post.
> Log is attached in attachment (too big 4.8M). Correct form is: tcpdump
> -s0 -w /tmp/foo host 10.146.1.199

Received.  I should have been clear: Please capture a non-working client boot attempt.  To reduce the size of the attachment, strip the TFTP packets before sending, and please gzip the file.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/