Re: kern/34799: IP Filter does not work correctly with gem(4) when hardware chec

["David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>]

The following reply was made to PR kern/34799; it has been noted by GNATS.

From: "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>
To: jdc%coris.org.uk@localhost, gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/34799: IP Filter does not work correctly with gem(4) when 
hardware chec
Date: Tue, 01 Jan 2008 18:55:30 -0500

 Julian Coleman wrote:
 >I have working gem interfaces, but I'm unable to reproduce the problem 
 >here.
 >Looking at the documentation, we have to pre-program the offset at which 
 >the
 >card starts generating the TCP checksum.  We set this to:
 >
 >        v |= (ETHER_HDR_LEN + sizeof(struct ip) +
 >              ((sc->sc_ethercom.ec_capenable & ETHERCAP_VLAN_MTU) ?
 >                ETHER_VLAN_ENCAP_LEN : 0)) << GEM_RX_CONFIG_CXM_START_SHFT;
 >
 >in gem_init().  So, if you have a vlan configured on that interface and
 >the packet is received directly on the interface, then the pre-programmed
 >receive checksum will be incorrect.  Is this the case here?
 
 No, it's just on a conventional LAN.  (The packets go from the host in
 question to a switch, then to a machine doing NAT and firewalling and
 then out to the internet.)
 
 >Could you send a dump of the received packet that is blocked?  Using:
 >
 >  tcpdump -vv -s 1514 -x -X -c 1 host www.google.ca and src port 80
 >
 >should catch just the return packet (from `telnet www.google.ca 80`).
 
 Okay, here's the tcpdump output when TCP checksumming isn't enabled:
 
 tcpdump: listening on gem0, link-type EN10MB (Ethernet), capture size 1514 
 bytes
 18:37:56.541838 IP (tos 0x0, ttl  52, id 2885, offset 0, flags [none], 
 length: 52) py-in-f104.google.com.http > arcusv.nonus-porta.net.65354: S 
 [tcp sum ok] 1236678017:1236678017(0) ack 1361609820 win 5720 <mss 
 1430,nop,nop,sackOK,nop,wscale 6>
         0x0000:  0030 656b e3f2 0001 022c 0f58 0800 4500  .0ek.....,.X..E.
         0x0010:  0034 0b45 0000 3406 d180 40e9 a768 c0a8  .4.E..4...@..h..
         0x0020:  0105 0050 ff4a 49b6 3581 5128 845c 8012  ...P.JI.5.Q(.\..
         0x0030:  1658 5a72 0000 0204 0596 0101 0402 0103  .XZr............
         0x0040:  0306                                     ..
 1 packets captured
 9 packets received by filter
 0 packets dropped by kernel
 
 And here's the output when TCP checksumming is enabled:
 
 tcpdump: listening on gem0, link-type EN10MB (Ethernet), capture size 1514 
 bytes
 18:38:47.750683 IP (tos 0x0, ttl  52, id 29483, offset 0, flags [none], 
 length: 52) py-in-f104.google.com.http > arcusv.nonus-porta.net.65353: S 
 [tcp sum ok] 1424794231:1424794231(0) ack 3091734025 win 5720 <mss 
 1430,nop,nop,sackOK,nop,wscale 0>
         0x0000:  0030 656b e3f2 0001 022c 0f58 0800 4500  .0ek.....,.X..E.
         0x0010:  0034 732b 0000 3406 699a 40e9 a768 c0a8  .4s+..4.i.@..h..
         0x0020:  0105 0050 ff49 54ec a277 b848 1e09 8012  ...P.IT..w.H....
         0x0030:  1658 e17f 0000 0204 0596 0101 0402 0103  .X..............
         0x0040:  0300                                     ..
 1 packets captured
 11 packets received by filter
 0 packets dropped by kernel
 
 Regards,
 
 Dave