4 ms·

Now can someone fix the embarrassing network bug in Linux. You know, where if you access a link to a network, or access an open networked path after 255 second

Now can someone fix the embarrassing network bug in Linux. You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. It still begs belief that such a fundamental aspect of Linux is broken ... When I show Linux to newbies and this fault occurs (ie. 100% of the time), I simply say "Linux isn't perfect ..." But inside, I cringe... It occurs under all distros I've tried and it's been there for years. Even on different computers with different hardware...

vidarh 13y ago
I have TCP connections that have stayed open for months so this is highly unlikely to be a kernel issue. I have no idea what you might be running into as I've never seen anything like that occurring.
octo_t 13y ago
backing the previous poster here, I've never experienced anything like this at all. "Network error" makes it sound like you're using KDE or GNOME or something, or Samba isn't liking your configuration...
eksith 13y ago
That's an odd. Have you eliminated all other variables E.G. Common utility/setting, cabling, switch/router etc..? I've had paths open for much longer than that without access issues.
username42 13y ago
Never had such error. Even in Linux 0.99pl10 (in 1992), network was working fine. I have always used a lot remote access to X servers. If network was broken, Linux would have been unusable.
viraptor 13y ago
> You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. I don't even know what this means. What's the actual, reproducible scenario?
joosters 13y ago
If you are connecting to a remote system, it could be NAT configured badly on your router. The router provided by my ISP (Virgin Media) is ruthless at closing idle TCP connections after only a few minutes. I'd see this with idle SSH logins being closed all the time. The solution (for me at least) was to ensure connections used TCP keepalives, and vastly decrease the keepalive times (various sysctl calls, I don't have the details to hand).
- danbee 13y ago
  Or just use a decent router and put the Virgin supplied thing in modem mode.
  - joosters 13y ago
    My fix involved spending no money and required supporting no more devices :)
    - jrabone 13y ago
      But instead required a bunch of moderately obscure changes to system config which you are bound to forget after a few years when you reinstall / image a new machine. The Virgin Superhub is a crappy barely-consumer grade box from Netgear with firmware written by Virgin. Modem mode is all it's good for. Sometimes the right answer is to spend the money on a decent router - Draytek are passable.
stinos 13y ago
not sure what you mean exactly, but one thing that has caused tons of trouble here, with sometimes the sole solution being a restart (ok our IT maintainer might be doing something worng, yet..) is the opposite: take a bunch of workstations and a bunch of servers, put home directories and data on servers then put everything together using NFS shares. Run analysis and whatnot on the data. Then make the server go down somehow and watch all workstation getting completely locked up without seemingly ever generating some kind of timeout error instead waiting endlessly on a dead connection.
- rwg 13y ago
  That's kinda how NFS was designed to work. NFS comes from the dark ages of networking, where transient network errors were very common, even on local networks. "man nfs" and "man mount.nfs" and search for "soft", "intr", "tcp", and "timeo". It sounds like the solution to your problem is some combination of those options.
  - stinos 13y ago
    thanks, will put some more effort into it if it ever happens again
- phaemon 13y ago
  Check that you've assigned an FSID to each share in /etc/exports
mh- 13y ago
> where if you access a link to a network, or access an open networked path after 255 seconds or so this terminology doesn't really make sense in the context of a TCP connection. but, anyway, check: net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl docs for the values here: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt https://www.kernel.org/doc/Documentation/networking/ip-sysct...

vidarh 13y ago

I have TCP connections that have stayed open for months so this is highly unlikely to be a kernel issue. I have no idea what you might be running into as I've never seen anything like that occurring.

octo_t 13y ago

backing the previous poster here, I've never experienced anything like this at all. "Network error" makes it sound like you're using KDE or GNOME or something, or Samba isn't liking your configuration...

eksith 13y ago

That's an odd. Have you eliminated all other variables E.G. Common utility/setting, cabling, switch/router etc..? I've had paths open for much longer than that without access issues.

username42 13y ago

Never had such error. Even in Linux 0.99pl10 (in 1992), network was working fine. I have always used a lot remote access to X servers. If network was broken, Linux would have been unusable.

viraptor 13y ago

> You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. I don't even know what this means. What's the actual, reproducible scenario?

joosters 13y ago

If you are connecting to a remote system, it could be NAT configured badly on your router. The router provided by my ISP (Virgin Media) is ruthless at closing idle TCP connections after only a few minutes. I'd see this with idle SSH logins being closed all the time. The solution (for me at least) was to ensure connections used TCP keepalives, and vastly decrease the keepalive times (various sysctl calls, I don't have the details to hand).

danbee 13y ago
Or just use a decent router and put the Virgin supplied thing in modem mode.
- joosters 13y ago
  My fix involved spending no money and required supporting no more devices :)
  - jrabone 13y ago
    But instead required a bunch of moderately obscure changes to system config which you are bound to forget after a few years when you reinstall / image a new machine. The Virgin Superhub is a crappy barely-consumer grade box from Netgear with firmware written by Virgin. Modem mode is all it's good for. Sometimes the right answer is to spend the money on a decent router - Draytek are passable.

stinos 13y ago

not sure what you mean exactly, but one thing that has caused tons of trouble here, with sometimes the sole solution being a restart (ok our IT maintainer might be doing something worng, yet..) is the opposite: take a bunch of workstations and a bunch of servers, put home directories and data on servers then put everything together using NFS shares. Run analysis and whatnot on the data. Then make the server go down somehow and watch all workstation getting completely locked up without seemingly ever generating some kind of timeout error instead waiting endlessly on a dead connection.

rwg 13y ago
That's kinda how NFS was designed to work. NFS comes from the dark ages of networking, where transient network errors were very common, even on local networks. "man nfs" and "man mount.nfs" and search for "soft", "intr", "tcp", and "timeo". It sounds like the solution to your problem is some combination of those options.
- stinos 13y ago
  thanks, will put some more effort into it if it ever happens again
phaemon 13y ago
Check that you've assigned an FSID to each share in /etc/exports

mh- 13y ago

> where if you access a link to a network, or access an open networked path after 255 seconds or so this terminology doesn't really make sense in the context of a TCP connection. but, anyway, check: net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_probes net.ipv4.tcp_keepalive_intvl docs for the values here: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt https://www.kernel.org/doc/Documentation/networking/ip-sysct...