Description of problem:
Mounting a RedHat EL5 server share via nfs makes Fedora 7 hang accessing
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Redhat EL5, update to the latest packet versions,
create an exports file:
2. Install Fedora 7, update to the latest packet versions,
create an auto.master:
create an auto.direct:
/mountpoint -fstype=nfs,rw,rsize=8192,wsize=8192 server:/somepath
3. "ls -la /mountpoint" may work, but
"cp /mountpoint/largefile /tmp" will suddenly hang.
The last entered command on the mounted share will hang.
The last entered command on the mounted share finishing without error.
The mounts worked for months without any problem since two weeks (patches
installed Oct. 5, 2007) they do not work any more!
would it be possible to post a bzip2 tshark network trace?
Something similar to:
tshark -w /tmp/bz335371.pcap host <server>
I was able to find out what made it hang meanwhile:
nfs hangs only if the connection to the nfs server was via a vlan. I had to set
the MTU four bytes less than the MTU for the adapter to make it work again:
I had to add "MTU=1496" to ifcfg-eth0.2:
It seems this had been done automaticly with the not updated installations. I
am not sure if this is a kernel or a script problem. But in my opinion this is
bad, since some devices allow for a larger MTU and some want it lower and I
have to look at what the MTU actualy is for eth0 to set it four bytes less for
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This problem exists for Fedora 8/9 too. The VLAN MTU is set to the same size
than the MTU for the real adapter. But this is wrong, since the tag needs four
bytes! The MTU must be decremented by four for every VLAN created!
I'm not sure why this is an nfs-utils bug. nfs-utils had nothing to do
with setting MTUs...
This is not an nfs or nfs-utils bug, but it looked at the first glance as if it
where. It should be redirected to Network-Manager bugs or net-utils bugs.
I think that default setting of MTU is module stuff. It seems, that if a module
of your card don't count with vlan tagging (4 bytes) in MTU, then you have to
change MTU by yourself. I tried to reproduce this bug, but I wasn't successful,
everything worked out of the box. In your case it is strange, that it worked.
What ethernet card do you use?
Anyway, definitely it isn't a bug in net-tools.
As I thought first: a kernel/module problem. Seems this is related to Broadcom
some Broadcom devices. But since I do not have access to the Dell workstation
any more I can't test and try out if it is gone changing network cards. AFAIK I
could see this with some Intel Centrino Duo/Centrino devices to. But since I do
not use Linux on my laptop at the moment --- to many drivers (Camera, SD-Slot,
WLAN, Bluetooth) missing. It is impossible to test in near future.
Ok, I'm reassigning this to kernel, so they can add their comments.
So is this problem a client or server issue? If a client issue then it should
probably get moved to the fedora kernel queue...
I'm not 100% sure which component sets MTU. But in my opinion, the kernel module
does it. So that is why I want to have comments from kernel side.
In this particular case, the bug is on server side, because there vlan is set.
But I thing that the problem is on both side. I mean, if we use fedora pc as a
server and if we set vlan here, then the bug will be on fedora side.
I'm afraid I'm still confused...
In comment #2, you mentioned that you had to reduce the MTU by 4 bytes to
account for the VLAN. What's not clear is whether you had to do this on the
client or server side, or both...
comment #2 isn't my comment, but anyway I'll try to answer :-). I think that you
have to do it no both sides. Unfortunately, I don't have hardware to reproduce
it, so this is only my guess.
You mentioned that an upgrade caused this problem. Was it an upgrade to the EL5
system that now prevents any Fedora system with VLANs and no MTU=1496 statement
in ifcfg-eth0.2? If so, can you tell me what kernel version worked before? Can
you also tell me exactly which type of Broadcom NIC you are using (lspci output
will be fine).
I first noticed the problem on Fedora 6, sort after on CentOS 5, then on RedHat
Enterprize Linux 5. If you are working with VLAN Linux ./. Linux it was
necessary to set MTU for the VLAN to be four bytes less than the MTU for the
corresponding none VLAN adapter. This was for the client and server.
The problem started with one of the first kernel updates for Fedora 6 and
CantOS/RHEL 5. Going back to the old kernel made the whole thing work again.
Meanwhile I found this very same problem on Ubuntu 8.04, but not on SuSE 10.3,
11.0. Since all of them use distribution specific patched kernels I tried a
vanilla kernel from kernel.org: same problem. Looks like SuSE applies a working
patch for this problem. Maybe this patch is already on its way into the kernel
This bug seems gone. I could mount a RedHat Enterprize Linux 5 share from all Fedora systems I could try:
Fedora 6 --- realy old now upgraded to 10
Fedora 7 --- realy old now upgraded to 10
Fedora 8 --- old now upgraded to 10
Fedora 9 --- now upgraded to upcoming 11
Thus there is no test system available any more! Maybe we could close this bug?!
Ok, closing this.