Bug 33653

Summary: DSL PPPoE connection error on 4.5-PRERELEASE
Product: Base System Reporter: motoyuki
Component: kernAssignee: Brian Somers <brian>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.5-PRERELEASE   
Hardware: Any   
OS: Any   

Description motoyuki 2002-01-07 17:20:01 UTC
	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

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.
How-To-Repeat: 	connect to ADSL using PPPoE.
Comment 1 iedowse freebsd_committer freebsd_triage 2002-12-01 21:11:06 UTC
State Changed
From-To: open->feedback


Does this problem still occur with more recent releases?
Comment 2 motoyuki 2002-12-02 11:42:29 UTC
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)
Comment 3 Gleb Smirnoff freebsd_committer freebsd_triage 2004-07-16 11:47:42 UTC
Responsible Changed
From-To: freebsd-bugs->brian

This seems to be a ppp(8) issue, not related to PPPoE. 
Brian, could you please look at it?
Comment 4 Brian Somers freebsd_committer freebsd_triage 2004-12-13 17:58:43 UTC
State Changed
From-To: feedback->closed

Feedback timeout