From owner-freebsd-hackers Thu May 30 22:17:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.aus.com (adsl-64-175-246-102.dsl.sntc01.pacbell.net [64.175.246.102]) by hub.freebsd.org (Postfix) with ESMTP id 529B937B405 for ; Thu, 30 May 2002 22:17:22 -0700 (PDT) Received: from localhost (rsharpe@localhost) by ns.aus.com (8.11.6/8.11.6) with ESMTP id g4V6Raq06212 for ; Fri, 31 May 2002 15:57:37 +0930 Date: Fri, 31 May 2002 15:57:36 +0930 (CST) From: Richard Sharpe To: Subject: broadcast packets not reaching sender on if_hwassist capable interfaces Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I was chasing an interesting problem in our FreeBSD 4.3 codebase today. Broadcast IP datagrams were not being received by programs on the same system the IP datagrams were sent from. They were making it out the wire. The were being sent on a Broadcom GigE interface that has hardware checksumming. After a while we realized that what was happening was that the packets were being marked for hardware checksumming in ip_output (m->m_pkthdr.csum_flags), but the decision about looping a packet back to ourselves is made in ether_output, so the packet is never checksummed and is discarded in ip_input. Has this been fixed in a subsequent release? Also, why is the decision to loop the packet back made in ether_output rather than in ip_output? Off the top of my head I can't see any particular advantage, but perhaps there is. The disadvantage is that I will have to disable hardware assist for broadcast packets to make things work right. Regards ----- Richard Sharpe, rsharpe@ns.aus.com, rsharpe@samba.org, sharpe@ethereal.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message