| Summary: | DSL PPPoE connection error on 4.5-PRERELEASE | ||
|---|---|---|---|
| Product: | Base System | Reporter: | motoyuki |
| Component: | kern | Assignee: | Brian Somers <brian> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.5-PRERELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback Does this problem still occur with more recent releases? 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 This seems to be a ppp(8) issue, not related to PPPoE. Brian, could you please look at it? State Changed From-To: feedback->closed Feedback timeout |
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.