The NSLU2 drops connections all the time, even the web interface times out
Sorry to put this last response at the top of the page, but it solved the problem, whereas many of these others don't seem fully applicable.
My NSLU2 shipped with a small magnet to fit around the ethernet cable, and instructions on it's use. The instructions, paraphrased, were to attach the magnet around the cable on the end towards the NSLU2. I've pulled my hair out all day over continual random disconnects, and this small change has made it rock solid.
I upgraded my router to a D-Link DGL 4300, just swapping in over a Linksys router. Everything else worked fine, except for my NSLU2. This web page was the most promising place with hints but nothing here fixed it.
Found the way to fix it was to change it to get its IP address via DHCP. The Linksys seems to give out addresses 192.168.1.XXX and the D-Link prefers 192.168.0.XXX Changing to DHCP made it work fine - you can retain UPNP on both if you want too. It still works. After you've used DHCP to get an address once, you can then make that address permanent if you want. The NSLU2 interface makes that easy - it's two clicks!
Try disabling UPnP support on the NSLU2 and possibly on the router as well. A user reports that their NSLU2 was basically unusable until they switched off UPnP support through the web admin interface. Since disabling UPnP support in the NSLU2, there have not been any problems. There may be issues with certain D-Link routers (in this case a D-Link 624) and UPnP support as well so it is recommended that you disable UPnP support in the router. Please leave a note in the wiki if disabling UPnP support helps.
I had to disable UPnP to get my NSLU2 to work properly. I have a D-Link DI-524 router.
Disabling UPnP helped for me. I have a D-Link DI-624 router.
I first tried disabling UPnP on my D-Link DI-624. That didn't work so I disabled it on the NSLU2. That did the trick.
Disabled UPnP on both NSLU2 and DI-624+ router. Things work better, but the slug never seems to works properly if connected directly to the router. I use a 3com switch between main computer and slug - works ok although I still get samba issues when copying several large files ("network name is no longer available").
For three months I debugged the problem "network name is no longer available". I searched all the forums and did everything. bought a switch, UPNP disabled, Network settings, Samba update to 3.x, original firmware, several HDD enclosures, HDD jumpering, etc. etc. Finally nothing really helped. The only way to solve this is buy a new NSLU2. With the new one everything works fine now for over 4 weeks and 200GB of data. So try a new NSLU2 and save time. ( for everybody who speaks german see also http://www.nslu2-info.de/forum/showthread.php?t=3210 )
The same problem may occour when connecting the NSLU2 to a 10MBit hub or network. Simply never do this with elder NSLU2 devices as the network interfaces will not work correctly with package splits. This results in 'network name is no longer valid' and other errors with any files >=32kB. => Use only 100MBit connections.
In my case, this problem appeared out of the blue on a nslu2 and PC that had worked perfectly sometime earlier. I troubleshooted the problem for about a week straight. I finally discovered that the following WU caused this particular problem for me:
I removed the update, and now everything works fine, even uploading and downloading very large files. FYI: I am using Windows XP x64. (Troglodyte)
Don't use the ethernet cable that comes in the box with the NSLU2. Replacing them with "real" cables solves many problems.
This issue has been quite vexing for me. I have bought a replacement NSLU2, changed the cable, placed disk on port 2 (for some reason none of my two slugs are stable if I use port 1 - at least with unslung, using 6.8beta now), disabled upnp (on router and on slug), tried to fix network speed to 100Mbps, tried half or full duplex on pc etc etc. What finally did the trick was to enable "Gaming Mode" on the D-link DI-624+ router. Now, this is only a workaround as it turns off the stateful packet inspection of the router (thus lessening the load it has to handle) so I'īm considering a more powerful router that can handle SPI and network traffic simultaneously... Turning on gaming mode made a 1.4GB file take 5-6 minutes instead of about 4 hours, if it succeeded at all...
My NSLU2 running LinksysR63? software is exhibiting the "network name is no longer available" error on both my XP and W2k machines. It only occurs during DOWNLOADS from the slug (uploads to the slug work perfectly). Disabling upnp didn't work. I was able to find a crappy work-around: I forcing my computer NICs? to 10Mbps AND Half-Duplex mode. (Network Properties => Configure... => Advanced tab=> ).
Later I reformatted the drive to EXT3? using the NSLU2(R63). Since then uploads and downloads have been bulletproof. (The only problem now is that I can't connect my drive directly to the USB port on my PC.)
It's known bug in the open source IXP NPE ethernet driver. The following command may help a little bit: sysctl net.ipv4.tcp_wmem="4096 8092 8092".
Hint: It may also help to install
if you are running debian etch. The current kernel for etch is 2.6.18-3 and has a bug in the ethernet driver. The -4 from unstable branch appears to be stable.
Another possible reason (I did not check it - just found on the web): NSLU2 becomes too hot. Cooling it somehow helps - see http://forums.linksys.com/linksys/board/message?board.id=Network_Storage&message.id=1016.
Using SlugOS/BE Got "network name is no longer available" all the time. Got data corruption on most files I moved to and from the device. Have a 750Gb iomega harddrive.
I began with these (issues found on the internet):
Still had problems after these fixes but maybe less than before(?), hard to say.
Next I did this:
Shouldn't affect samba stability but you never know, also did this:
"/dev/sda1 / ext3 noatime 1 1"
"none /var/run tmpfs defaults,size=512K 0 0" "none /var/lock tmpfs defaults,size=512K 0 0" "none /var/tmp tmpfs defaults,size=128K 0 0" "none /var/log tmpfs defaults,size=512K 0 0" "none /usr/local/samba/var tmpfs defaults,size=128K 0 0"
The last one should be set to the path samba uses for logging.
No problems anymore. I have tested to transfeed multi Gb files to and from the device and md5sum tested them after, always ok now. I suspect it was primary the tcp buffers but unsure.