Problem with dump over SSH: Operation timed out

Nikos Vassiliadis nvass at teledomenet.gr
Thu Aug 9 07:05:58 PDT 2007


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


More information about the freebsd-questions mailing list