On 4/2/2007 4:51 PM Dave wrote:
Hi Drew,
I can't remember the specific setting, but it's something heartbeat
in the file daemon's configuration file, that'll fix it. I'm currently
in the process of making a new server for my home network, so don't
have access to my configs at the moment or i'd be more specific. If
you don't find it let me know, and i'll dig them out.
Hth
Dave.
Thanks for your reply. However I did find that and set the heartbeat to
'1', thinking that would ensure that a timed out connection wasn't the
problem. I then restarted the fd and tried again. Same problem. To
further determine if there was some lag in the data stream, I used
tcpdump on the actual interfaces of both machines and watched the
output. Packets just whizzed by until the connection was broken. There
were no pauses whatsoever.
Thanks,
Drew
----- Original Message ----- From: "Drew Tomlinson"
<[EMAIL PROTECTED]>
To: <freebsd-pf@freebsd.org>
Sent: Monday, April 02, 2007 5:15 PM
Subject: Bacula and pf
I run Bacula v1.38 on my home network. Ever since I moved from ipfw2
to pf, backups fail intermittently on my router due to "broken
network pipes" usually after somewhere around 10 MB - 12 MB has been
transfered. Thus small incremental backups are successful but larger
full backups are not. I do not have this problem when I disable pf on
the router, nor do I have problems when completing backups with other
machines on my internal network. My setup looks like this:
bacula director --------- router (client)
192.168.1.4 (fxp0) 192.168.1.2 (dc0)
Communication takes place on ports 9102 and 9103. I captured this
output from pflog0 after starting a backup:
blacksheep# tcpdump -netttti pflog0 "( host blacksheep or blacklamb )
and ( port 9102 or port 9103 )"
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture
size 96 bytes
2007-04-02 13:57:21.021122 rule 7/0(match): pass in on dc0:
192.168.1.4.52295 > 192.168.1.2.9102: S 2822997678:2822997678(0) win
65535 <mss 1460,nop,wscale 1,[|tcp]>
2007-04-02 13:57:23.532037 rule 13/0(match): pass out on dc0:
192.168.1.2.64955 > 192.168.1.4.9103: S 2265048451:2265048451(0) win
65535 <mss 1460,nop,wscale 1,[|tcp]>
2007-04-02 13:57:23.532323 rule 7/0(match): pass in on dc0:
192.168.1.4.9103 > 192.168.1.2.64955: S 3452777266:3452777266(0) ack
2265048452 win 65535 <mss 1460,nop,wscale 1,[|tcp]>
And the rules are:
@7 pass in log on dc0 inet proto tcp from 192.168.1.0/24 to any
modulate state queue(std_out, ack_out)
@13 pass out log on dc0 inet all
Any ideas why Bacula would have such a problem? Other things to check?
Thanks,
Drew
--
Be a Great Magician!
Visit The Alchemist's Warehouse
http://www.alchemistswarehouse.com
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
