i386/104826: FreeBSD 6.1 not RFC 768 (UDP) compliant on Compaq/HP DL-380G3

[Frans van der Veer]

>Number:         104826
>Category:       i386
>Synopsis:       FreeBSD 6.1 not RFC 768 (UDP) compliant on Compaq/HP DL-380G3
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 26 10:30:15 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Frans van der Veer
>Release:        6.1
>Organization:
PEEK Traffic BV, The Netherlands
>Environment:
FreeBSD gandalf.rd.nl.peeknet.prv. 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Wed Oct 25 11:31:21 CEST 2006     root at gandalf.rd.nl.peeknet.prv.:/usr/src/sys/i386/compile/GANDALF  i386
>Description:
During testing of a Profibus/Ethernet gateway device that was suspected not have implemented UDP RFC 768 correctly, we stumbled onto a possible bug on FreeBSD 6.1 in the same area.

It appears that 6.1 is not capable of sending out UDP checksum 0xffff when the internal combination of pseudo-header, upd header and udp payload requires that.
In stead of that, the machine sends out 0x0000 as UDP checksum which is interpreted as "no checksum calculated".

We tracked the failure down to the bge driver. We found that the bge device driver uses a feature called "checksum offload". When we switch that feature off, the system operates accoring to RFC 768.

We noticed this with FreeBSD 6.1 on a Compaq/HP DL380G3 system.
Relevant lines from the messages file are:

Oct 25 11:51:55 gandalf kernel: FreeBSD 6.1-RELEASE #1: Wed Oct 25 11:31:21 CEST 2006
-
-
Oct 25 11:51:55 gandalf kernel: bge0: <Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002> mem 0xf06f0000-0xf06fffff irq 29 at device 1.0 on pci2
Oct 25 11:51:55 gandalf kernel: bge0: No checksum offload

(This log is from after we created a patch for ourselves, the last log line is due to that patch)

We created a dirty fix to get outselves out of trouble for the moment: we switched of the "hwassist" feature in the initialisation phase of the bge driver to give the checksum calculation task back to software in stead of the Broadcom hardware.

Kind regards,

Frans van der Veer
Senior software engineer.
R&D department,
PEEK Traffic B.V., The Netherlands.
>How-To-Repeat:
We repeated the problem by creating a small UDP echo program that answered on a machine sending UDP packets. With ethereal (run on another machine since ethereal is troubles by the same checksum offload feature as well) we checked the checksum, did a hexadecimal calculator exercise and modified the data the echo program is sending out to achieve checksum 0xffff.
>Fix:
As told, we created a "dirty fix" to get us out of trouble for the time being. This is how:

Patched File /usr/src/sys/dev/if_bge.c: (from line 2213 on)

/*
	 * 5700 B0 chips do not support checksumming correctly due
	 * to hardware bugs.
	 */
	if ( 1 ) {
		ifp->if_capabilities &= ~IFCAP_HWCSUM;
		ifp->if_capenable &= IFCAP_HWCSUM;
		ifp->if_hwassist = 0;
		device_printf(sc->bge_dev, "No checksum offload\n");

	}

Original code:

      /*
	 * 5700 B0 chips do not support checksumming correctly due
	 * to hardware bugs.
	 */
	if (sc->bge_chipid == BGE_CHIPID_BCM5700_B0) {
		ifp->if_capabilities &= ~IFCAP_HWCSUM;
		ifp->if_capenable &= IFCAP_HWCSUM;
		ifp->if_hwassist = 0;
	}As told, we created a "dirty fix" to get us out of trouble for the time being. See attached documents on how we did that.
>Release-Note:
>Audit-Trail:
>Unformatted: