From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 21 13:40:00 2013 Return-Path: Delivered-To: freebsd-sparc64@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1648497 for ; Thu, 21 Nov 2013 13:40:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3F53282B for ; Thu, 21 Nov 2013 13:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rALDe0CV079092 for ; Thu, 21 Nov 2013 13:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rALDe05E079091; Thu, 21 Nov 2013 13:40:00 GMT (envelope-from gnats) Resent-Date: Thu, 21 Nov 2013 13:40:00 GMT Resent-Message-Id: <201311211340.rALDe05E079091@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, James Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4D3D27B for ; Thu, 21 Nov 2013 13:35:42 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA4DA27FF for ; Thu, 21 Nov 2013 13:35:42 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rALDZfSw047144 for ; Thu, 21 Nov 2013 13:35:41 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rALDZf9X047137; Thu, 21 Nov 2013 13:35:41 GMT (envelope-from nobody) Message-Id: <201311211335.rALDZf9X047137@oldred.freebsd.org> Date: Thu, 21 Nov 2013 13:35:41 GMT From: James To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: sparc64/184141: Kernel PPPoE sends bad echo-req magic number on big endian machines X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 13:40:00 -0000 >Number: 184141 >Category: sparc64 >Synopsis: Kernel PPPoE sends bad echo-req magic number on big endian machines >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 21 13:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: James >Release: none >Organization: >Environment: n/a >Description: Recently, I found an OpenBSD bug where pppoe(4) sends echo-req packets with bad magic numbers. The following tcpdump trace below shows the bad echo-req packet with 00-00-00-00: Nov 1 09:24:59 smyslov /bsd: pppoe0: lcp output Nov 1 09:24:59 smyslov /bsd: pppoe0 (8864) state=3, session=0x3d22 output -> 00:90:1a:a3:7e:12, len=16 Nov 1 09:24:59 smyslov /bsd: pppoe0: lcp input(opened): Nov 1 09:24:59 smyslov /bsd: pppoe0: lcp opened->stopping According to RFC 1661, "A Magic-Number of zero is illegal and MUST always be Nak'd". OpenBSD and FreeBSD share the code responsible for in-kernel PPPoE negotiation (sys/net/if_spppsubr.c): else if (sp->pp_phase >= PHASE_AUTHENTICATE) { unsigned long nmagic = htonl (sp->lcp.magic); sp->lcp.echoid = ++sp->pp_seq; sppp_cp_send (sp, PPP_LCP, ECHO_REQ, sp->lcp.echoid, 4, &nmagic); } The problem here is that sparc64 is big endian and 64 bit, and passing the address using '&nmagic' causes sppp_cp_send to see only zeros in the 'first' four bytes (most significant bytes). Small test case showing this: $ cat bigendian.c #include #include int main() { int j; uint64_t i = 0x11335577; uint8_t * p = &i; for( j = 0; j < sizeof(unsigned long); j++) printf("%02x ", p[j]); printf("\n"); return 0; } $ cc -o be bigendian.c bigendian.c: In function 'main': bigendian.c:8: warning: initialization from incompatible pointer type $ ./be 00 00 00 00 11 33 55 77 >How-To-Repeat: Problem eventually occurs during any PPPoE connection. >Fix: Changing nmagic to an int32_t fixes this problem: $ diff /usr/src/sys/net/if_spppsubr.c.orig /usr/src/sys/net/if_spppsubr.c 4595c4595 < unsigned long nmagic = htonl (sp->lcp.magic); --- > int32_t nmagic = htonl (sp->lcp.magic); This is also what NetBSD does: https://github.com/jsonn/src/blob/trunk/sys/net/if_spppsubr.c#L4793 >Release-Note: >Audit-Trail: >Unformatted: