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]"

Reply via email to