On 2013-02-21, Pim van Pelt <[email protected]> wrote:
> Hoi,
>
> I have recently switched from a Zyxel modem terminated pppoe
> connection, to an OpenBSD based termination of the pppoe connection. I
> think I have a reasonable configuration, and both kernel as well as
> userland pppoe configs connect fine, but after a few minutes the
> ingress traffic halts and the connection drops. I am running 5.2, with
> the following /etc/ppp/ppp.conf ([1] for userland) and
> /etc/hostname.pppoe0 ([2] for kernel). Both exhibit the same issue.
> When the connection establishes, I have the following device:
> $ ifconfig pppoe0
> pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
>         priority: 0
>         dev: vlan5 state: session
>         sid: 0x1268 PADI retries: 8 PADR retries: 0 time: 00:04:02
>         sppp: phase network authproto chap authname "[email protected]"
>         groups: pppoe
>         status: active
>         inet6 fe80::260:e0ff:fe53:7978%pppoe0 ->  prefixlen 64 scopeid 0x1e
>         inet  81.6.62.85 --> 80.254.161.242 netmask 0xffffffff
>
> The ISP routes me 81.6.62.84/30 and when the connection is up, this
> works (I can ping all 4 IP addresses). There's a netscreen at
> 81.6.62.86 behind this machine and it is responding to ping's from the
> internet just fine. A few minutes later, traffic stops flowing and
> about one minute later, pppoe0 disconnects and then reconnects a few
> minutes later, to rinse and repeat. So I tcpdump'ed the kernel pppoe,
> and noticed the following snippet (see [3] for details). I am MAC
> 00:60:e0:53:79:79 , the ISP is MAC 00:90:1a:a4:8d:20.
>
> At 00:27:30.706636 I see ingress to .86, which is replied at
> 00:27:30.708050 egress. Then, ingress halts. I send three echos at
> 00:27:52.564297, 00:28:02.563980 and 00:28:12.563665, and then give up
> at 00:28:22.563420 and send a Terminate-Request. I then send three
> Initiation requests, which are answered finally at 00:29:27.771647 by
> the ISP. The connection re-establishes and the cycle repeats.

Your log only shows the last incoming packet and a few unanswered
outgoing packets, so it's not enough to tell, does the ISP reply to
any of your earlier LCP echo requests or does it ignore all of them?

Normally if there is a period of 30 seconds with either no LCP
keepalives or no user data, pppoe(4) will drop the session and log
"LCP keepalive timeout", which it looks like should show up at the
bottom of dmesg output.

So, if they do normally respond to LCP, it looks like the link
is dropping out somehow..

Or, if they don't normally respond to LCP, you may either need some
other way to generate data to keep the session alive, disable the
timeout (by hacking the driver), or ideally see if they can start
responding (easier if it's an ISP compliant with xkcd 806 ;)

> I've read up on ppp/pppd/pppoe for both userspace and kernel, but I'm
> stumped and at this point I believe the problem is with the ISP (I say
> this because traffic stops flowing while I'm sending LCP echos, and I
> always reply the ISPs echos, but after a few failed echos pppoe on my
> machine gives up). Can somebody please confirm this before I open a
> problem ticket with my ISP, or help me find a way to gather more
> information to diagnose this issue?

> [1] cat /etc/ppp/ppp.conf
> default:
>   set log Phase Chat LCP IPCP CCP tun command
>   set speed sync
>   disable acfcomp protocomp shortseq vjcomp
>   deny acfcomp
>
> green:
>   set device "!/usr/sbin/pppoe -i vlan5"
>   set mtu max 1492
>   set mru max 1492
>   set authname "[email protected]"
>   set authkey "Y"
>   set ifaddr 0.0.0.0 0.0.0.0
>   disable echo lqr
>   deny lqr

I haven't really used iij ppp since around 1998 so not too sure about
syntax here (though it seems ok).. but

> [2] cat /etc/hostname.pppoe0
> inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan5 authproto chap
> authname '[email protected]' authkey 'Y' up
> dest 0.0.0.1

this definitely looks right to me, and I have a bunch of pppoe(4)
running over vlans, so there's no problem in that respect.

> [3] http://pastebin.com/ph6xrNaW
>
> [4] http://pastebin.com/grifHJ41

Reply via email to