Hi Nick/Michael, Why would it be a tinc issue, if no one else chimes in to report the same problems?
I don't know if it is but based on my experience it's normally symptomatic of the problem. Stable networks (mine is) don't usually cause problems like this (in practice). It's possible of course but 3rd-party software is far more often the cause (hence my suspicions but they're only suspicions at this point). I don’t believe in maligning something without real proof however (I don’t work that way) but based on my experience on these particular machines (I do a lot of low-level development with many different tools), there are no other networking problems normally. - You have not specified the router’s brand. Is it a cheapo thing that was provided with your Internet connection (like mine: a Fritz.Box with a lousy DNS cache for one)? - Does the router properly handle long running connections like remote logins? Do a remote desktop connection to another machine on your LAN and see whether that is still around after 2 days. I bet it isn’t. It's a decent quality router that’s been running without issues for years. I keep Remote Desktop running for days on end and also use TeamViewer to access the home version of Windows (which supports Remote Desktop client only). Both programs stay up indefinitely. - You have not specified the router’s brand. Is it a cheapo thing that was provided with your Internet connection (like mine: a Fritz.Box with a lousy DNS cache for one)? I'm not an authority on routers and exactly what active states they maintain (other than any obvious ones), but their main function is to forward packets to the target machines of course. They normally do this without issue, otherwise problems would be quickly noticed. IOW, stable hardware just shouldn't go down and stay down normally. It's the target servers (software) they communicate with that are far more often the problem (not necessarily in this case but usually). Even if something went down in the router (some cache cleared or whatever), it won’t normally be a blocking problem, especially after being rebooted (which isn’t even necessary usually). The servers talking to it (or rather through it) can normally reinitiate communication without issue. If this doesn’t happen then my first suspicion (after doing a cursory hardware check) is to look at the software package itself. In practice it will usually be the guilty party. - Have you considered the switches in the path? I have seen weird stuff caused by switches going haywire once in a while and dropping almost all the traffic. - If you are doing long running TCP connections over a tunnel that is running on TCP for some reason, your connection could at some point get stalled because of MTU problems. Example: If your client is behind a NAT and normally downloads stuff, but occasionally uploads large amounts, you could stall that connection easily if the MTU on the client is too high (it sends a packet that is too large, but does not get notified because of NAT dropping the ICMP packet). I will be investigating all this. Thanks. >> Why would three different versions of Windows behave different with respect >> to networking? >May I point at a printer spooler locking a document and refusing to delete it, >which has been a pain since Windows 95 right through to Windows 7 and perhaps >later? I agree there may be some lingering issues (unfortunately I’m all too familiar with Windows spooling lockups), but for the most part things work (usually). Network stability problems aren’t normal in Windows (people would be screaming bloody murder about it), and even if there were an issue, it’s highly unlikely the same problem would be manifesting itself on 3 normally stable machines (in the course of a couple of days). The simplest solution is usually the right one. Write down your assumptions and prove them wrong. If you fail you are probably right. Agreed. And I will have to pursue this further to pinpoint what’s wrong. Again, I don’t want to unfairly denigrate tinc. It may not be the cause and it’s also a free package, which I certainly appreciate (kudos to the authors). My instincts might be wrong IOW, but they’re based on: 1.. 25 years of Windows programming experience (with a deep understanding of the Windows API). There’s just a “feel” for these things, especially after having done a superficial review of things (a deeper review to now follow) 2.. A complete lack any of other networking problems in my environment 3.. The assumption that a package like “tinc” would work out-of-the-box based on the default setup (without further tweaking). The environment can potentially play a role of course, but if other settings do need adjusting then it “appears” to be brittle, which I wouldn’t normally expect (since the defaults typically just work in most packages) 4.. Most programs in the real world are poorly written (just a reality) so it’s guilt by association. That’s not fair of course, so I’m open-minded about it (I haven’t looked at the “tinc” code) but right or wrong, I’m conditioned to assume the worst, since it’s usually the case (no disrespect intended to the authors though - it’s a reflection of past experience only, since their own work could be a paragon of excellence but that would be rare in the real world) The upshot is that it just doesn’t pass the smell test which is why I’m suspicious of the package itself at this point. I hope to be proved wrong however and will happily acknowledge it. Thanks again. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
