On 09/11/2009 11:36 AM, Jim Klimov wrote:
Steve Clark wrote:
> DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
> 5 bad IP checksums seen in 5 packets
Sorry Steve, I must have overlooked this.
So DHCP Client also sees broken packets... Perhaps it is in some
logical position between the NIC and IPF like a sniffer would be,
so turning off checksum offload may help anyway.
I guess the more general solution would be a configuration flag
for IPF to not recalculate checksums for packets on specified
interfaces. After all, to fix the problem we're turning of the
acceleration feature which relieves our CPUs...
//Jim
Hi Jim,
Besides the checksum the ip header length is getting munged. Also it doesn't
look like
keep state is working quite right. The same ruleset works perfectly on FreeBSD
6.x.
I have narrowed it down some, the following ruleset works as far as allowing
back in
the dhcp responses. I had to put an explicit pass in rule though
@3 pass in on eth1 proto udp from any port >= 0 to any port 66 >< 69
and dhclient is happy. Also tcpdump show no errors.
[r...@z2966 ~]# tcpdump -nnli eth1 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
12:27:04.457764 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:02:b6:36:97:9f, length: 300
12:27:04.458406 IP 192.168.198.70.67 > 255.255.255.255.68: BOOTP/DHCP, Reply,
length: 320
when I remove the
@3 pass in on eth1 proto udp from any port >= 0 to any port 66 >< 69
then dhcp doesn't work and I get munged ip headers.
12:37:58.950465 IP truncated-ip - 18105 bytes missing! 192.168.198.158.68 >
255.255.255.255.67: BOOTP/DHCP, Request from 00:08:54:05:2c:3c, length: 18405
12:38:14.503571 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:02:b6:36:97:9f, length: 300
12:38:14.504189 IP truncated-ip - 23205 bytes missing! 192.168.198.70.67 >
255.255.255.255.68: BOOTP/DHCP, Reply, length: 23525
These packets seem to be munged when they are looked because of the
@3 pass out proto udp from any to any keep state
and the response comes back. They are obviously being passed on in because
dhclient is seeing them but dropping them because of the bad checksum.
[r...@z2966 ~]# ipfstat -nio
@1 pass out quick on lo from any to any
@2 pass out proto tcp from any to any flags S/S keep state
@3 pass out proto udp from any to any keep state
@4 pass out proto icmp from any to any keep state
@1 block in log from any to any
@2 pass in quick on lo from any to any
@3 pass in on eth1 proto udp from any port >= 0 to any port 66 >< 69
@4 pass in quick on eth1 proto tcp from any port > 1023 to 192.168.198.178/32
port = ssh keep state
@5 pass in quick on eth1 proto tcp from any port > 1023 to 192.168.198.178/32
port = tproxy keep state
@6 pass in quick on eth1 proto icmp from any to 192.168.198.178/32 icmp-type
echo keep state
