Greets! I was trying to stream some multimedia wirelessly (is that a word?) from my main linux box to my laptop. Both have Slack 10. The desktop is wired via ethernet to a Linksys wireless 802.11b router. The laptop connects via a built-in 802.11g (ndiswrapper driver). NFS is cooking on both systems, and the laptop can mount and browse the desktop's multimedia directory. However, streaming or even copying any of the files jams up the works. Everything just freezes with no error messages from the kernel at all!

My wifi connection is ULTIMATE, my MTU is set at 1500 on the laptop, desktop AND router. I feel this has something to do with packet size, but any web resources that reference both wifi AND NFS are virtually non-existent. Any advice out there???

--Akshun J

Your setup is very much like mine, except that I have no such problems. The worst thing that will happen is a pause or skip in music playing over the NFS mount with XMMS if I'm also copying a file via SSH, downloading something off the Internet, on the edge of coverage or some combination of those factors.

The wireless card I normally use is Prism-based using orinoco_cs driver, but I have another with an internal Broadcom/ndiswrapper card I can use for testing if you want to compare notes. Slack 10, 2,4,27 on the laptops and the file server.

In case it matters, here's how I'm mounting the NFS dir in /etc/fstab:
192.168.1.99:/home/music/ /mnt/music nfs noauto,intr,user,ro 0 0

Yeah, you're right. Our setups seem similar except for the card type...

Wonder what my issue is?

--Akshun J

Does the wireless link work if you're just pinging? Or does it only crash when you get data via NFS?

bash-2.05b$ ping 192.168.1.6
PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data.
64 bytes from 192.168.1.6: icmp_seq=1 ttl=64 time=1.49 ms
64 bytes from 192.168.1.6: icmp_seq=2 ttl=64 time=2.13 ms
64 bytes from 192.168.1.6: icmp_seq=3 ttl=64 time=1.40 ms
64 bytes from 192.168.1.6: icmp_seq=4 ttl=64 time=1.42 ms
64 bytes from 192.168.1.6: icmp_seq=5 ttl=64 time=1.37 ms
64 bytes from 192.168.1.6: icmp_seq=6 ttl=64 time=1.33 ms
64 bytes from 192.168.1.6: icmp_seq=7 ttl=64 time=1.38 ms

--- 192.168.1.6 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6005ms
rtt min/avg/max/mdev = 1.338/1.507/2.133/0.261 ms

*******I am both PING and mount capable. Only transferring data seems to be the issue.
Thanks for the reply!

--Akshun J

Well running a ping and mounting is transfering data so It'd be a problem in your NFS implementation. Try re-installing nfs-utils and if all else fails re-compile the kernel as NFS is mainly implemented there.

Well, that's the real trick. I recompiled the kernel four times. Not related to NFS, but to get ALSA just right. And NFS works great when I'm plugged in via ethernet. Why should NFS care if I'm connected via ethernet or wifi? In any case, reinstalling nfs-utils has changed nothing. I still think it's a packet size trick. Either that or a kernel bug, as I'm running 2.6.10-rc3, which is not really a final release. I'll try a live CD that's got a driver for my wifi and try troubleshooting from there. Any other suggestions are GREATLY appreciated! :-)

--Akshun J

Did I mention that I WAS able to transfer a small text file? The larger files just jam everything up, though.

Trippy, I've never had MTU problems. So what happens exactly? Do you get a total lockup kernel panic (scroll/num lock flash when it panics) or just a terminal freeze/X freeze or just a transfer stall?

VERY trippy. I use KDE's konsole to launch Midnight Commander. I can browse the mounted NFS directories going into subdirectories and so on with zero issues. But when I try to transfer a file, Midnight Commander locks up with the file transfer dialog frozen at 0%. And I can't cancel the transfer. And my connection seems to send and receive a few Kb of data every five seconds or so. While trying to watch a video with Xine, I got different error messages. Xine told me the file I was asking for did not exist. And MPlayer would freeze up like Midnight Commander. WEIRD.

--Akshun J

New wrinkle is that Samba works fine to transfer files. At least JPEGs.

Well I'm sorry I'm at the end of my suggestions sorry . If your happy using samba just use it even though it's inferior IMO....I guess if you can't get NFS to work you don't have much choice .

Think I may have found an issue. NFS on my laptop reports that mount is older than kernel version. I'm not sure if that means I'm using an old version of nfs-utils compared to by cutting edge 2.6.10-rc3 kernel nfs support. This is the angle I'm pursuing, though.

I'll post an update when I get home...

--Akshun J

Ah right, if you need to update mount you'll need to update either the mount package or util-linux, I'm not sure which....

Yeah. The FAQ I just read on the NFS site told me the same. It's quite vague about how to do this. Wait a sec...

I DO have a package called util-linux. Hmmm. Now I need to compile a package that hooks my new kernel and upgrade? Crossing my fingers...

--Akshun J