<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>Hi Nick/Michael,</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>Why would it be a tinc issue, if no one else chimes in 
to report the same problems?</FONT></DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>- 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)?</FONT></DIV>
<DIV><FONT color=#0000ff>- 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.</FONT></DIV>
<DIV> </DIV>
<DIV>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 <EM>client</EM> 
only). Both programs stay up indefinitely.</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>- 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)?</FONT></DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>- 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.</FONT></DIV>
<DIV><FONT color=#0000ff>- 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).</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV>I will be investigating all this. Thanks.</DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV><FONT color=#0000ff>>> Why would three different versions of Windows 
behave different with respect to networking?</FONT></DIV>
<DIV>><FONT color=#0000ff>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?</FONT></DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV><FONT color=#0000ff>The simplest solution is usually the right one. Write 
down your assumptions and prove them wrong. If you fail you are probably 
right.</FONT></DIV>
<DIV><FONT color=#0000ff></FONT> </DIV>
<DIV>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:</DIV>
<OL>
  <LI>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) 
  <LI>A complete lack any of other networking problems in my environment 
  <LI>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) 
  <LI>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)</LI></OL>
<DIV>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.</DIV></DIV></DIV>
<br /><br />
<hr style='border:none; color:#909090; background-color:#B0B0B0; height: 1px; width: 99%;' />
<table style='border-collapse:collapse;border:none;'>
        <tr>
                <td style='border:none;padding:0px 15px 0px 8px'>
                        <a href="http://www.avast.com/">
                                <img border=0 src="http://static.avast.com/emails/avast-mail-stamp.png" />
                        </a>
                </td>
                <td>
                        <p style='color:#3d4d5a; font-family:"Calibri","Verdana","Arial","Helvetica"; font-size:12pt;'>
                                This email is free from viruses and malware because <a href="http://www.avast.com/">avast! Antivirus</a> protection is active.
                        </p>
                </td>
        </tr>
</table>
<br />
</BODY></HTML>