crazyscot

Previously...

I played around with MTUs, which might have helped a little but there aren't many data points.

My current suspicion is that my own slightly wacky network setup may have been to blame.

• I had been running two different IP nets on the same physical net.
  
• Clients were allocated an address by DHCP (running on my server), server was DNS and gateway (amongst other things) to the second logical net. (My server has but a single ethernet interface.)
  
• Only my server and the DSL modem were on the second logical net.
  
• The DSL modem was itself running NAT.

So my desktop was behind double-NAT, which the internets (and my colleague Thomas) pointed out were likely to break many things. Having moved the DSL modem to be on the same part of RFC1918-space as the rest of the wired net, I have started using the DSL modem as a direct gateway for desktop clients - and it all works much better. I don't think I've had a single blackhole event since making the change a couple of days ago.

The only downside that I can see is that I no longer have the fine-grained firewall control that I enjoyed with iptables. Right?

OK, internets, help me out here, my google-fu is deserting me and possibly because I'm using the wrong terminology...

I have some regular weirdness with networking on my desktop PC at home. I regularly lose the ability to route packets to certain destinations. It tends to be the same destinations. For a long time it was feedproxy; now it's that and facebook. The interface remains up, and I can reach those destinations from the Linux PC that is the immediate router; just that those failing destinations seem to be blackholed on my desktop.

So it's obviously (?) entirely my machine at fault.

If I bounce the interface, it all works again. For a while, but it usually blackholes again soon.

It may be relevant that I am running the dreaded double NAT; once on my router/fileserver PC, and again on the DSL modem. I did briefly try to make the DSL modem not do NAT, but couldn't readily make it work. I suppose I ought to try again; and I could also try putting my PC outside the inner NAT to see if that makes a difference (though it wouldn't then be able to see the fileserver unless I reconfigured that *sigh*).

My googling did take me as far as a possible kernel bug to do with ARP caching and ICMP redirects and suggested echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects - but it hasn't helped. ip route list cache shows affected destinations as redirected, but I'm not entirely sure what that means or how I might prevent it.

31.13.75.17 via 192.168.1.1 dev eth0  src 172.20.45.26 
    cache   ipid 0xc125 rtt 206ms rttvar 67ms cwnd 10
31.13.75.17 from 172.20.45.26 via 192.168.1.1 dev eth0 
    cache   ipid 0xc125 rtt 206ms rttvar 67ms cwnd 10

172.20.45.26 is my desktop. 192.168.1.1 is the DSL router.

Any ideas?

The state of Linux video editing and animation software hasn't drastically improved in the last year and half, has it?

I'm going to end up getting Final Cut Pro and Motion (and a Mac to run them on), aren't I?