> 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).
Will do, thanks - the LCP echo's come on the input, so I was assuming
the term-req also coming on the input would be from the ISP/BT/Zen.
But will certainly double-check using tcpdump.
> 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.
I've connected my OpenBSD box up to the TG589 handling the PPPoE, this
has been up for a few hours now with no drops so the actual line seems
to be sound. Out of curiosity, do use MTU 1500 on the pppoedev to
take advantage of RFC4638?
The aspect that has me stuck, is that same modem/config/physical
router/ports/etc works fine consistently on my other BT FTTC
connection.
> 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.
I've asked a few times if they can shed any light on the matter, but
it gets silently ignored, they've confirmed that what they see from
the BT stats the drops are PPP related. Am going to leave the TG589
up for a day or so handling PPPoE, then go back to them to see if they
can dig any further on their end. The 'funky' aspects to my setup
are:
- rdomain
- vlan pppoedev
- re(4) patches to enable jumbo frames (use this in conjunction with
RFC4638 so I can get 1508 on the physical NIC, then 1500 on the
pppoedev).
- MTU 1500 on pppoedev
Will build a -current image for the router and see what happens as
well, although this will (I'm assuming) include the re(4) patches, but
then I did also try going back to OpenBSD 5.5 which would negate these
patches being a cause and a reboot/recreate of the pppoe interface.
On 29 June 2015 at 17:38, Stuart Henderson <s...@spacehopper.org> wrote:
> 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.
