On 2015-06-29, Ed Stout <edst...@gmail.com> wrote:
> Good Morning,
>
> I've recently migrated to a new ISP (Zen UK), from BT, and am facing
> an annoying problem - head banging against a brick-wall has started -
> it is the same broadband product, i.e VDSL2/FTTC, just a different
> ISP. For the last 3 years my current setup has functioned on BT,
> since the migration to Zen things seem to have gone a bit wonky - the
> Zen aspect may or may not be related.
>
> I have an OpenBSD 5.7 router connected to either an HG612 or ECI
> modem, via a switch the PPPoE interface is on a VLAN and in its own
> rdomain, I encounter the same problem with both. The problem? PPPoE
> (kernel) drops frequently between 1 - 15 minutes of connected time and
> reconnects, then repeats, the modem sync is not dropping. The router
> has an OpenVPN (UDP) VPN connection that routes all traffic to the
> OpenVPN server in the DC. I should add, I still have another line
> still with BT with the exact same setup and this does not encounter
> the problem and has been up for some 70 days.
>
> Between migrating from BT -> Zen, the only thing that changed on the
> OpenBSD router was the PPPoE username/password. From the moment the
> migration occurred, this problem started occurring.
>
> Thing's I have ruled out:
>
> - Cabling, no errors on switch ports but all cables have been replaced
> - Not HG612 or ECI modem related, that I can see, problem happens with
> both. Initially thought it could be the HG612 bug with UDP/VPNs,
> however the modem is unlocked and running the latest release. The
> trick of unplugging and reseating the eth cable doesn't make any
> difference.
> - OpenBSD config, there is minimal kernel PPPoE config same setup
> works with BT and continues to work
> - OpenBSD OS versions (tried 3 different releases, 5.5, 5.6 and 5.7)
> - Rolled back RFC4638 setup, i.e for MTU 1500. The Max Payload is
> negotiated successfully during the connection process, so I don't
> believe this is the issue but have tried without anyway.
> - LCP echo/replies are all being sent and responded to in a timely
> manner, there are no ignore/dropped echos/replies before the
> 'term-req' is received'
>
> Enabled debug on the OpenBSD pppoe interface and it seems to me, that
> Zen are sending 'term-req' - although I need to make sure my reading
> of the logs is correct i.e 'lcp input' is the ISP/Zen?
I think that's correct, but you could double-check by running tcpdump
on the parent interface ("pppoedev") and use -e to show MAC addresses.
(I'd use something like -nevvs1500).
> However, the
> below logs also show 'Down event (carrier loss)' but there is no
> carrier loss (the modem stays in sync) and all ethernet ports between
> the modem/switch/router stay up, no errors, etc - although this could
> be because the term-req has already been received and the
> disconnection is in process.
pppoe(4) can't tell anything about carrier on the modem, just read that
message as "pppoe session is down" or similar..
FWIW I'm using pppoe(4) to connect to zen without problem here (-current
with one of their tg589vn configured as a bridge), I'm not using rdomain
though I don't *think* that's related to what you're seeing.
> .. If anyone has any suggestions, or seen anything similar previously,
> I'm all ears. Going to open a case with the ISP as well.
Yep that's worth finding out what if anything they see from their side..
Have you tried rebooting or fully re-creating the pppoe interface
(ifconfig pppoeX destroy; sh /etc/netstarter pppoeX) since changing
across? If not then that might be worth a go.
