[IPFW] [DIVERT] IP header checksums - why calculate twice?

2013-08-28 Thread Dom F
[Copy of my post to FreeBSD Firewalls forum sent here by suggestion from 
moderator]


I've been toying with using IPDIVERT to adjust values in an IPv4 header. 
When adjusting an incoming IP header, the man page for divert(4) says:


Quote:
Packets written as incoming and having incorrect checksums will be dropped.

My main issue was with trying to leverage the optimised kernel functions 
for checksumming an IP header, for example in_cksum_hdr(). Processes 
that connect to DIVERT sockets are based in user-land so in_cksum_hdr() 
isn't readily available during compile.


Eventually the thought hit me that if some part of the kernel has to 
validate checksums (to decide whether to drop a packet) AND if my 
user-land process has to calculate a checksum to avoid its packet being 
dropped THEN surely there are two wasted checksum calculations going on?


If a root-owned process, root needed for RAW socket, can be trusted to 
inject packets back into the IP stack then surely we can skip the 
checksum test and save a few CPU cycles plus a bit of latency.


Very simple patch for /usr/src/sys/netinet/ip_divert.c (based on rev 
224575):


Code:
--- ip_divert.c.orig2013-08-26 20:52:18.0 +0100
+++ ip_divert.c 2013-08-26 20:52:44.0 +0100
@@ -496,6 +496,12 @@
/* Send packet to input processing via netisr */
switch (ip->ip_v) {
case IPVERSION:
+   /* mark mbuf as having valid checksum
+  to save userland divert process from
+  calculating checksum, and kernel having
+  to check it */
+   m->m_pkthdr.csum_flags |= CSUM_IP_CHECKED |
+ CSUM_IP_VALID;
netisr_queue_src(NETISR_IP, (uintptr_t)so, m);
break;
 #ifdef INET6
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


cas(4) PCI errors

2014-03-08 Thread Dom F

Hello,

I have a Sun quad gigaswift ethernet card in an ASUS K8V-SE-Deluxe 
motherboard. It's a 64-bit PCI card in a PCI v2.2 32-bit slot. It pretty 
much works fine except I see these errors in /var/log/messages:


Mar  8 12:44:31  kernel: cas2: cas_eint: status 0x123c1010, PCI bus 
error 0x20

Mar  8 12:44:31  kernel: cas2: link state changed to DOWN
Mar  8 12:44:33  kernel: cas2: link state changed to UP
Mar  8 12:47:47  kernel: cas2: cas_eint: status 0x18541016, PCI bus 
error 0x20

Mar  8 12:47:47  kernel: cas2: link state changed to DOWN
Mar  8 12:47:49  kernel: cas2: link state changed to UP
Mar  8 12:50:02  kernel: cas2: cas_eint: status 0x9d41016, PCI bus error 
0x20

Mar  8 12:50:02  kernel: cas2: link state changed to DOWN
Mar  8 12:50:04  kernel: cas2: link state changed to UP
Mar  8 12:50:17  kernel: cas2: cas_eint: status 0x128c1010, PCI bus 
error 0x20

Mar  8 12:50:17  kernel: cas2: link state changed to DOWN
Mar  8 12:50:19  kernel: cas2: link state changed to UP
Mar  8 12:59:45  kernel: cas2: cas_eint: status 0xf141010, PCI bus error 
0x20

Mar  8 12:59:45  kernel: cas2: link state changed to DOWN
Mar  8 12:59:47  kernel: cas2: link state changed to UP
Mar  8 13:02:43  kernel: cas2: cas_eint: status 0x1f5c1016, PCI bus 
error 0x20

Mar  8 13:02:43  kernel: cas2: link state changed to DOWN
Mar  8 13:02:45  kernel: cas2: link state changed to UP

The 2-second ethernet renegotiation hurts the most. I have tried other 
replacement cards but the messages still pop up. Anyone else seen these? 
Currently running 9.1-RELEASE-p6.


The "pciconf -lv" reports this:

cas0@pci0:3:0:0:class=0x02 card=0x chip=0x0035100b 
rev=0x30 hdr=0x00

vendor = 'National Semiconductor Corporation'
device = 'DP83065 [Saturn] 10/100/1000 Ethernet Controller'
class  = network
subclass   = ethernet

[ditto for cas1, cas2, cas3]

Device attach logs from /var/log/messages:

Mar  8 17:06:30  kernel: cas0:  mem 
0xfce0-0xfcff irq 17 at device 0.0 on pci3

Mar  8 17:06:30  kernel: miibus0:  on cas0
Mar  8 17:06:30  kernel: nsgphy0:  
PHY 1 on miibus0
Mar  8 17:06:30  kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, auto, auto-flow

Mar  8 17:06:30  kernel: cas0: 16kB RX FIFO, 9kB TX FIFO
Mar  8 17:06:30  kernel: cas0: Ethernet address: 00:03:ba:db:ab:5f
Mar  8 17:06:30  kernel: cas1:  mem 
0xfd60-0xfd7f irq 18 at device 1.0 on pci3

Mar  8 17:06:30  kernel: miibus1:  on cas1
Mar  8 17:06:30  kernel: nsgphy1:  
PHY 1 on miibus1
Mar  8 17:06:30  kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, auto, auto-flow

Mar  8 17:06:30  kernel: cas1: 16kB RX FIFO, 9kB TX FIFO
Mar  8 17:06:30  kernel: cas1: Ethernet address: 00:03:ba:db:ab:60
Mar  8 17:06:30  kernel: cas2:  mem 
0xfd00-0xfd1f irq 19 at device 2.0 on pci3

Mar  8 17:06:30  kernel: miibus2:  on cas2
Mar  8 17:06:30  kernel: nsgphy2:  
PHY 1 on miibus2
Mar  8 17:06:30  kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, auto, auto-flow

Mar  8 17:06:30  kernel: cas2: 16kB RX FIFO, 9kB TX FIFO
Mar  8 17:06:30  kernel: cas2: Ethernet address: 00:03:ba:db:ab:61
Mar  8 17:06:30  kernel: cas3:  mem 
0xfd40-0xfd5f irq 16 at device 3.0 on pci3

Mar  8 17:06:30  kernel: miibus3:  on cas3
Mar  8 17:06:30  kernel: nsgphy3:  
PHY 1 on miibus3
Mar  8 17:06:30  kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, auto, auto-flow

Mar  8 17:06:30  kernel: cas3: 16kB RX FIFO, 9kB TX FIFO
Mar  8 17:06:30  kernel: cas3: Ethernet address: 00:03:ba:db:ab:62

Dom
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"