Re: amanda/iptables problem

2002-10-21 Thread John Dalbec 
John Dalbec wrote:

I'm using Red Hat 7.1, kernel 2.4.9-34 w/ReiserFS quota patches.


I've since rebuilt the kernel after doubling the UDP timeouts in 
ip_conntrack_proto_udp.c.  So far this seems to be working...

Thanks,
John Dalbec

Re: amanda/iptables problem

2002-09-18 Thread John Dalbec 



Galen Johnson wrote:
> John Dalbec wrote:
> 
>> I sometimes get sendsize packets being dropped by iptables, presumably 
>> because the iptables connection tracking decided the UDP connection 
>> was closed.  This causes the estimates to take much longer because the 
>> first sendsize process gives up.  Has anyone found a solution to this?
>> Thanks,
>> John Dalbec
>>
> I am currently running amanda through an iptables based firewall with no 
> issues.  I'm using Slack 8.1.  Are you able to log the drops?
I'm using Red Hat 7.1, kernel 2.4.9-34 w/ReiserFS quota patches.

These dumps were to tape DailySet104.
The next tape Amanda expects to use is: DailySet105.


STATISTICS:
   Total   Full  Daily
       
Estimate Time (hrs:min)1:00

Run Time (hrs:min) 1:23
Dump Time (hrs:min)0:20   0:06   0:15
Output Size (meg)4865.8 1339.5 3526.2
Original Size (meg)  4865.8 1339.5 3526.2
Avg Compressed Size (%) -- -- --(level:#disks ...)
Filesystems Dumped   23  3 20   (1:19 3:1)
Avg Dump Rate (k/s)  4098.2 4008.7 4133.3

Sep 12 00:45:32 mail03 kernel: INT_IN DROP 5 IN=eth0 OUT= 
MAC=00:02:55:58:9d:fa:00:02:55:7c:ff:52:08:00 SRC=150.134.10.202 
DST=150.134.10.203 LEN=304 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP 
SPT=10080 DPT=604 LEN=284
Sep 12 00:45:34 mail03 kernel: INT_IN DROP 5 IN=eth0 OUT= 
MAC=00:02:55:58:9d:fa:00:02:55:7c:fd:01:08:00 SRC=150.134.10.201 
DST=150.134.10.203 LEN=265 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP 
SPT=10080 DPT=604 LEN=245
Sep 12 00:45:42 mail03 kernel: INT_IN DROP 5 IN=eth0 OUT= 
MAC=00:02:55:58:9d:fa:00:02:55:7c:ff:52:08:00 SRC=150.134.10.202 
DST=150.134.10.203 LEN=304 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP 
SPT=10080 DPT=604 LEN=284
Sep 12 00:45:44 mail03 kernel: INT_IN DROP 5 IN=eth0 OUT= 
MAC=00:02:55:58:9d:fa:00:02:55:7c:fd:01:08:00 SRC=150.134.10.201 
DST=150.134.10.203 LEN=265 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP 
SPT=10080 DPT=604 LEN=245
Sep 12 00:45:52 mail03 kernel: INT_IN DROP 5 IN=eth0 OUT= 
MAC=00:02:55:58:9d:fa:00:02:55:7c:ff:52:08:00 SRC=150.134.10.202 
DST=150.134.10.203 LEN=304 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP 
SPT=10080 DPT=604 LEN=284
... there are more, but you get the idea.

The connection tracking should be handling this.  If I have to hack my 
firewall to let these packets through I might as well be using ipchains.
Thanks,
John Dalbec

Re: amanda/iptables problem

2002-09-17 Thread Galen Johnson 

John Dalbec wrote:

> I sometimes get sendsize packets being dropped by iptables, presumably 
> because the iptables connection tracking decided the UDP connection 
> was closed.  This causes the estimates to take much longer because the 
> first sendsize process gives up.  Has anyone found a solution to this?
> Thanks,
> John Dalbec
>
I am currently running amanda through an iptables based firewall with no 
issues.  I'm using Slack 8.1.  Are you able to log the drops?

=G=

amanda/iptables problem

2002-09-17 Thread John Dalbec 

I sometimes get sendsize packets being dropped by iptables, presumably 
because the iptables connection tracking decided the UDP connection was 
closed.  This causes the estimates to take much longer because the first 
sendsize process gives up.  Has anyone found a solution to this?
Thanks,
John Dalbec