Bacula and pf

[Drew Tomlinson]

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" 
> <drew at mykitchentable.net>
> To: <freebsd-pf at 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