I would recommend trying it like my example, there is a race condition when
you list the destination address separately.
--
Sent from a phone, apologies for poor formatting.
On 20 February 2022 16:50:35 Brodey Dover <dover...@gmail.com> wrote:
You make a very good point about attaching the configuration :-).
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 pppoedev re0 authproto pap
authname 'username' authkey 'password' up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1
That should help.
Thank you,
On Sun, 20 Feb 2022 at 06:06, Stuart Henderson <stu.li...@spacehopper.org>
wrote:
On 2022-02-19, Brodey Dover <dover...@gmail.com> wrote:
Hello all,
I've configured hostname.pppoe0 and hostname.re0 as per the pppoe manpage
for OpenBSD (I'm running 7) and I'm unable to successfully leverage the
Bell HomeHub 4000's pppoe passthrough. I've verified that passthrough does
work with my Windows 7 laptop, however, I just can't get pppoe to move past
the initialization stage.
Might help to show your config.
My typical config in hostname.pppoe0 is something like this
inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1 authproto chap authname
"user@realm" authkey "password" up
The PADI gets sent, but ultimately it'll timeout. After adjusting to the
second config in the man page where mut1508 is set to the physical device,
That is a special case and is very unlikely to ever be _required_ by an
ISP and often won't work. Normally you're better off starting with the
default MTU to get things working initially, then try that later if needed
as a refinement (but remember that it's there in case things stop working
later; sometimes internal changes in the ISP network will stop it from
working later)..
pppoe0: ipcp parse opt values: address 10.11.1.81 [not agreed] send
conf-nak
The other side proposed this address (possibly for the address of their
end of the connection?) and your side rejected it.
--
Please keep replies on the mailing list.
