On Thursday 09 August 2007 16:43, Bram Schoenmakers wrote: > Op donderdag 09 augustus 2007, schreef u: > > Try using a much lower MTU, something like 1400 or perhaps lower, > > just for testing. You should configure this, on both client and > > server. > > > > I'm not familiar with ipf to give the exact rule, but I would allow > > ALL ICMP traffic, at least for testing purposes. I think this is > > correct: > > pass out quick proto icmp from any to any > > pass in quick proto icmp from any to any > > > > somewhere above the "block in log quick on re0 all" rule. > > > > Hope this helps a bit > > > > Nikos > > Thank you for your answer. > > I have added the 'pass in for icmp' rule to the firewall (pass out did > already exist). There was a noticable improvement, the /usr dump came > much further than before. But at about 80% there was the timeout again.
Strange, is it possible that the filesystem is corrupted and dump cannot continue and quits? Keep in mind that dump(8) uses UFS2 snapshots. I don't know the current status, but in the past, snapshots were not working that good. 1) Can you dump the file locally? 2) Is scp working? > > I tried lowering the MTU value at the server side, but nearly all other > network traffic stopped working, so that is not the way to go. Ofcourse, this could be a problem. MTU must be the same across the ethernet segment. And obviously your upstream router is administered by your ISP. Nikos _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"