Re: OpenBSD pppoe and Bell Fibe

2022-02-25 Thread Brodey Dover
Hi Stuart,

You got it right off the bat. I removed mtu config, replaced NONE with
0.0.0.1 and removed the dest line. Booted up and voila, a workable WAN IP
address using pppoe passthrough.

It seems like the realtek card may be holding back performance as I'm only
pulling in 800Mbps or perhaps it is the APU but I have doubts there. My
comparison is using my laptop to test pppoe credentials and fully
saturating the internet connection; as well as using the router that came
with the ISP's service (Home Hub 4000). In any case, all is working and
thank you very much for your help!

Time to find an Intel 10Gb PCIe card.

Brodey Dover

On Sun, 20 Feb 2022 at 12:46, Stuart Henderson  wrote:

> 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  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 
>> wrote:
>>
>>> On 2022-02-19, Brodey Dover  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.
>>>
>>>
>


Re: OpenBSD pppoe and Bell Fibe

2022-02-20 Thread Stuart Henderson
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  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  
wrote:

On 2022-02-19, Brodey Dover  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.




Re: OpenBSD pppoe and Bell Fibe

2022-02-20 Thread Brodey Dover
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 
wrote:

> On 2022-02-19, Brodey Dover  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.
>
>


Re: OpenBSD pppoe and Bell Fibe

2022-02-20 Thread Stuart Henderson
On 2022-02-19, Brodey Dover  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.