From motoyuki@mk.bsdclub.org  Mon Jan  7 09:15:14 2002
Return-Path: <motoyuki@mk.bsdclub.org>
Received: from mail.mk.bsdclub.org (motoyuki.as.wakwak.ne.jp [61.205.237.31])
	by hub.freebsd.org (Postfix) with ESMTP id 4B41337B404
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  7 Jan 2002 09:15:13 -0800 (PST)
Received: from sakura.mk.bsdclub.org (sakura.mk.bsdclub.org [2001:200:341:0:2a0:c9ff:fe20:9aff])
	by mail.mk.bsdclub.org (8.11.6+3.4W/3.7W) with ESMTP/inet6 id g07HF7x64816
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 8 Jan 2002 02:15:07 +0900 (JST)
Received: (from motoyuki@localhost)
	by sakura.mk.bsdclub.org (8.11.6/3.7W) id g07HF7V09357;
	Tue, 8 Jan 2002 02:15:07 +0900 (JST)
Message-Id: <200201071715.g07HF7V09357@sakura.mk.bsdclub.org>
Date: Tue, 8 Jan 2002 02:15:07 +0900 (JST)
From: Motoyuki Konno <motoyuki@bsdclub.org>
Reply-To: Motoyuki Konno <motoyuki@bsdclub.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: DSL PPPoE connection error on 4.5-PRERELEASE
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         33653
>Category:       kern
>Synopsis:       DSL PPPoE connection error on 4.5-PRERELEASE
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 07 09:20:01 PST 2002
>Closed-Date:    Mon Dec 13 18:00:17 GMT 2004
>Last-Modified:  Mon Dec 13 18:00:17 GMT 2004
>Originator:     Motoyuki Konno
>Release:        FreeBSD 4.5-PRERELEASE i386
>Organization:
BSD Club
>Environment:
System: FreeBSD mserver.mk.bsdclub.org 4.5-PRERELEASE FreeBSD 4.5-PRERELEASE #0: Sat Jan 5 00:46:33 JST 2002 motoyuki@mserver.mk.bsdclub.org:/usr/obj/usr/src/sys/MSERVER i386

>Description:
	ADSL PPPoE/ppp link disconnects with "write (1): Message too long"
        error.  Once this error occurrs, ppp(8) tries to reconnect many times
        but *never* succeeds.

	If a superuser kills ppp process and start ppp again,
        the new ppp process will succeed to connect.

-------- /var/log/ppp.log
Jan  5 02:44:43 mserver ppp[XX]: tun0: Phase: deflink: write (1): Message too long 
        <-- ERROR OCCURS.
Jan  5 02:44:43 mserver ppp[XX]: tun0: CCP: deflink: State change Stopped --> Closed 
Jan  5 02:44:43 mserver ppp[XX]: tun0: CCP: deflink: State change Closed --> Initial 
Jan  5 02:44:43 mserver ppp[XX]: tun0: Phase: deflink: open -> lcp 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP: deflink: LayerDown: 61.205.237.31 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP: deflink: State change Opened --> Starting 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP: deflink: LayerFinish. 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP: Connect time: 6460 secs: 13638722 octets in, 17080388 octets out 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP: : 33262 packets in, 29664 packets out 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP:  total 4755 bytes/sec, peak 165967 bytes/sec on Sat Jan  5 02:44:43 2002 
Jan  5 02:44:43 mserver ppp[XX]: tun0: IPCP: deflink: State change Starting --> Initial 
Jan  5 02:44:43 mserver ppp[XX]: tun0: Phase: bundle: Terminate 

[snip]
	<-- TRIES TO RECONNECT
Jan  5 02:44:46 mserver ppp[XX]: tun0: Phase: deflink: Connected! 
Jan  5 02:44:46 mserver ppp[XX]: tun0: Phase: deflink: opening -> dial 
Jan  5 02:44:46 mserver ppp[XX]: tun0: Phase: deflink: dial -> carrier 
Jan  5 02:44:47 mserver ppp[XX]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") 
Jan  5 02:44:47 mserver ppp[XX]: tun0: Phase: deflink: carrier -> login 
Jan  5 02:44:47 mserver ppp[XX]: tun0: Phase: deflink: login -> lcp 
Jan  5 02:44:47 mserver ppp[XX]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1454 
Jan  5 02:44:47 mserver ppp[XX]: tun0: Phase: deflink: write (1): Message too long 
        <-- SAME ERROR OCCURS AGAIN
Jan  5 02:44:47 mserver ppp[67]: tun0: Phase: deflink: Disconnected! 
-------- /var/log/ppp.log

-------- /etc/ppp/ppp.conf
default:
  set log Phase IPCP CCP tun command
  set device PPPoE:fxp1
  set speed sync
  set mru max 1454
  set mtu max 1454
  set redial 5 0
  set ctsrts off
  set openmode active
  enable mssfixup

provider:
  accept chap
  accept pap
  set authname XXXXXXXX
  set authkey XXXXXXXX
  set ifaddr 0.0.0.0/0 0.0.0.0/0
  nat enable yes
  nat same_ports yes
  nat use_sockets yes
  add default HISADDR
-------- /etc/ppp/ppp.conf

>How-To-Repeat:
	connect to ADSL using PPPoE.

>Fix:
	Unknown.
	4-STABLE kernel on Dec/12/2001 or before : OK
        4-STABLE kernel on Dec/23/2001 or later  : NG 

	So, I think this problem caused by kernel changes between
        Dec/12 and Dec/23.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Dec 1 13:11:06 PST 2002 
State-Changed-Why:  

Does this problem still occur with more recent releases? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33653 

From: Motoyuki Konno <motoyuki@bsdclub.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: motoyuki@freebsd.org, Ian Dowse <iedowse@freebsd.org>
Subject: Re: kern/33653: DSL PPPoE connection error on 4.5-PRERELEASE
Date: Mon, 02 Dec 2002 20:42:29 +0900

 In the previous mail, I forgot to cc: to GNATS DB.
 
 Ian Dowse <iedowse@FreeBSD.org> wrote:
 > Synopsis: DSL PPPoE connection error on 4.5-PRERELEASE
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: iedowse
 > State-Changed-When: Sun Dec 1 13:11:06 PST 2002
 > State-Changed-Why: 
 > 
 > Does this problem still occur with more recent releases?
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=33653
 
 I'm sorry I've forgotten to write follow-ups.
 
 I've examined this problem since I submitted this PR.  I think
 this is IPv6 problem.
 
 
 1.  ppp hangs up at physical_Write() in src/usr.sbin/ppp/physical.c.
     I found that write() in physical_Write() failed.
 
 2.  When write() faied,  physical_Write() tries to write following
     data.
 
 ------
 00 21 60 06 62 c2 00 20 06 40 3f fe 05 05 20 22  .!`.b.. .@?... " 
 00 00 00 00 00 00 00 00 00 01 20 01 02 18 04 99  .......... ..... 
 00 01 00 00 00 00 00 00 00 02 00 50 0d d5 ac 44  ...........P...D 
 35 29 44 e3 14 c1 80 11 81 c4 08 fd 00 00 01 01  5)D............. 
 08 0a 00 1b b3 63 00 30 63 3a 63 2e              .....c.0c:c.
 ------
 
     First 2 bytes (0x00 0x21) tells that this is PPP encapsulated
     data (RFC 1548).  Third byte (0x60) tells that this is IPv6
     packet.
 
 3.  ppp calculates the size of packet using bit 16-31 of IP header
     (Total Length field of IPv4 header).  bit 16-31 of IPv6
     header is "Flow Label", not "Total Length".  So, when ppp tries
     to write IPv6 packet to ppp line,  the size of data size must
     be illegal.
 
 4.  How to prevent this problem is:
 
     # ip6fw add deny all from any to any via tun*
 
 5.  I think the reasons of this problem are:
 
     o  /usr/sbin/ppp cannot recognize IPv6 packet
     o  kernel sends IPv6 packet to tun* interface which does not
        have IPv6 address.
 
 6.  Now, I'm using FreeBSD 4.7-STABLE.  Here is the ip6fw log:
 
 --------
 Dec  2 10:23:08 mserver /kernel: ip6fw: 2000 Deny P:0 [fe80::02d0:b7ff:fe83:3679] [ff02::0001:ff83:3679] out via tun1
 Dec  2 10:23:08 mserver /kernel: ip6fw: 2000 Deny P:0 [fe80::02d0:b7ff:fe83:3679] [ff02::0002:f470:729c] out via tun1
 Dec  2 10:23:08 mserver /kernel: ip6fw: 2000 Deny IPV6-ICMP:135.0 [::] [ff02::0001:ff83:3679] out via tun1
 --------
 
    It seems that kernel tries to write illegal IPv6 packets to
    tun* (ppp).
 
 --
 ------------------------------------------------------------------------
 Motoyuki Konno                  motoyuki@bsdclub.org             (Home)
                                 motoyuki@FreeBSD.ORG  (FreeBSD Project)
                                 http://www.freebsd.org/~motoyuki/ (WWW)
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Fri Jul 16 10:47:42 GMT 2004 
Responsible-Changed-Why:  
This seems to be a ppp(8) issue, not related to PPPoE. 
Brian, could you please look at it? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33653 
State-Changed-From-To: feedback->closed 
State-Changed-By: brian 
State-Changed-When: Mon Dec 13 17:58:43 GMT 2004 
State-Changed-Why:  
Feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33653 
>Unformatted:
I don't think this is a ppp(8) error....  ppp doesn't look in the ip6_hdr
for the length of the packet, it uses the number of bytes in the mbuf
which is obtained from the read() done on the tun device.

I've just added an additional diagnostic (to both -current and -stable)
to report the length of the attempted write when it fails.  It would be
interesting to see the output.

I suspect this is actually a netgraph issue.  I ran with IPv6 over
PPP over Ethernet here for quite a while, but I wasn't routing data,
so may not have seen this issue....
