Re: pppoe(4): use if_hardmtu for RFC 4638 ceilings

David Gwynne <[email protected]>
Newsgroups gmane.os.openbsd.tech
Message-ID <[email protected]>
On Wed, Jun 17, 2026 at 07:19:37AM +0200, Bjorn Ketelaars wrote:
> On Sat 06/06/2026 13:15, Bjorn Ketelaars wrote:
> > As recently explained on misc@, OpenBSD interfaces operate at their
> > maximum supported packet size at all times [0]. The software IP stack
> > MTU does not change this. However, the current RFC4638 implementation in
> > if_pppoe.c stands out as an anomaly.
> > 
> > Currently, if_pppoe.c enforces MTU ceilings during PPPOESETPARMS and
> > SIOCSIFMTU based on the parent's software layer (eth_if->if_mtu). This
> > forces administrators to manually configure the parent interface, e.g.:
> > 
> > # echo "up mtu 1508" > /etc/hostname.em0
> > 
> > This is only needed to allow pppoe0 to use `mtu 1500`. It contradicts
> > the principle that the hardware is already wide open out of the box.
> > 
> > The diff below flips these checks to use `if_hardmtu` instead of
> > `if_mtu`. This allows `hostname.pppoe0` to use `mtu 1500` during early
> > boot via netstart. No arbitrary MTU manipulation on the parent interface
> > is required. 
> > 
> > The diff also cleans up share/man/man4/pppoe.4 to remove the instruction
> > to explicitly set `mtu 1508` on the physical device.
> > 
> > Comments or OK?
> > 
> > [0] https://marc.info/?l=openbsd-misc&m=178061105778390&w=2
> 
> 
> Just a ping

sorry, it's been one of those years.

i like this, so i'm keen to see it go in. however, i'm not on an ISP
that requires pppoe anymore, and the one i was on didn't support RFC4638
anyway, so i can't test it. if it works for you then it's ok by me.

dlg

> 
> 
> diff --git share/man/man4/pppoe.4 share/man/man4/pppoe.4
> index ca0cd209d5d..521b0eda358 100644
> --- share/man/man4/pppoe.4
> +++ share/man/man4/pppoe.4
> @@ -183,9 +183,10 @@ dest 0.0.0.1
>  !/sbin/route add default -ifp pppoe0 0.0.0.1
>  .Ed
>  .Pp
> -The physical interface would also have to be configured correspondingly:
> +The physical interface must also be marked
> +.Ql up :
>  .Bd -literal -offset indent
> -# echo "up mtu 1508" > /etc/hostname.em0
> +# echo "up" > /etc/hostname.em0
>  .Ed
>  .Pp
>  However, RFC 4638 negotiation only takes into account the MTU configured
> diff --git sys/net/if_pppoe.c sys/net/if_pppoe.c
> index a5208d2479c..d13c91e151e 100644
> --- sys/net/if_pppoe.c
> +++ sys/net/if_pppoe.c
> @@ -989,8 +989,8 @@ pppoe_ioctl(struct ifnet *ifp, unsigned long cmd, caddr_t data)
>  			}
>  
>  			if (sc->sc_sppp.pp_if.if_mtu >
> -			    eth_if->if_mtu - PPPOE_OVERHEAD) {
> -				sc->sc_sppp.pp_if.if_mtu = eth_if->if_mtu -
> +			    eth_if->if_hardmtu - PPPOE_OVERHEAD) {
> +				sc->sc_sppp.pp_if.if_mtu = eth_if->if_hardmtu -
>  				    PPPOE_OVERHEAD;
>  			}
>  			sc->sc_eth_ifidx = eth_if->if_index;
> @@ -1093,7 +1093,7 @@ pppoe_ioctl(struct ifnet *ifp, unsigned long cmd, caddr_t data)
>  
>  		if (ifr->ifr_mtu > MIN(PPPOE_MAXMTU,
>  		    (eth_if == NULL ? PPPOE_MAXMTU :
> -		    (eth_if->if_mtu - PPPOE_OVERHEAD))))
> +		    (eth_if->if_hardmtu - PPPOE_OVERHEAD))))
>  			error = EINVAL;
>  		else
>  			error = 0;
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.