Old thread: Re: Allowing large PPPoE frames

[Paul Ripke]

Just wondering if anything happened to this old issue - I've just
tripped over the same thing with my ISP.

http://mail-index.netbsd.org/tech-net/2003/08/15/0002.html

Cheers,

[Quentin Garnier]

Post by Paul Ripke
Just wondering if anything happened to this old issue - I've just

Not so much an issue as an unexpected feature of my PPPoE setup at the
time, which, sadly, came to an end shortly after when I changed my
contract with the ISP and received a new modem that wouldn't let large
frames through.

Post by Paul Ripke
tripped over the same thing with my ISP.

What do you mean by trip over? You're in a situation where oversized
frames actually go as far as ether_input?

In that case, it's a 10 minute job to revive that patch, it was very
simple after all.

[Paul Ripke]

Post by Quentin Garnier

Post by Paul Ripke
Just wondering if anything happened to this old issue - I've just

Not so much an issue as an unexpected feature of my PPPoE setup at the
time, which, sadly, came to an end shortly after when I changed my
contract with the ISP and received a new modem that wouldn't let large
frames through.

Post by Paul Ripke
tripped over the same thing with my ISP.

What do you mean by trip over? You're in a situation where oversized
frames actually go as far as ether_input?

Initially, only 802.1Q VLAN-compatible sized frames were getting
that far. Then I removed an ethernet switch out of the path, and
yes, 1522 byte frames were being received.

Post by Quentin Garnier
In that case, it's a 10 minute job to revive that patch, it was very
simple after all.

I took a slightly more brutal approach. I just removed the "return"
from the check and passed all oversize frames through. Hey, it works.
The NIC is a gigabit sk that supports jumbo frames, so that part
works. I didn't find your patch until after I got it working. For
me, it was breaking large udp and icmp packets, possibly ipsec, too.

It's an annoying position to be in.

Cheers,

[Paul Ripke]

Post by Paul Ripke

Post by Paul Ripke
Just wondering if anything happened to this old issue - I've just

<snip>
In that case, it's a 10 minute job to revive that patch, it was very
simple after all.

I took a slightly more brutal approach. I just removed the "return"
from the check and passed all oversize frames through. Hey, it works.
The NIC is a gigabit sk that supports jumbo frames, so that part
works. I didn't find your patch until after I got it working. For
me, it was breaking large udp and icmp packets, possibly ipsec, too.
It's an annoying position to be in.

Well, Ethernet devices are not supposed to let such frames through;
and as I said, I had an unusual setup (for various reasons) which
broke down in that respect when I made my situation with my ISP
"normal".
Think of your position still as a privileged one, as a PPPoE
vict^Wuser.

Heh.

What's the driver of your NIC? I'll revive that patch, and get it
committed as you will be able to test it.

As above, a Marvell/SysKonnect sk (if_sk.c) gigabit NIC. Since it
supports jumbo frames (~9000 bytes?) it just works. I should be able
to test any patches over the next week or so.

Cheers,

[Quentin Garnier]

Post by Paul Ripke

Post by Quentin Garnier

Post by Paul Ripke
Just wondering if anything happened to this old issue - I've just

Not so much an issue as an unexpected feature of my PPPoE setup at the
time, which, sadly, came to an end shortly after when I changed my
contract with the ISP and received a new modem that wouldn't let large
frames through.

Post by Paul Ripke
tripped over the same thing with my ISP.

What do you mean by trip over? You're in a situation where oversized
frames actually go as far as ether_input?

Initially, only 802.1Q VLAN-compatible sized frames were getting
that far. Then I removed an ethernet switch out of the path, and
yes, 1522 byte frames were being received.

Cool for you!

Post by Paul Ripke

Post by Quentin Garnier
In that case, it's a 10 minute job to revive that patch, it was very
simple after all.

I took a slightly more brutal approach. I just removed the "return"
from the check and passed all oversize frames through. Hey, it works.
The NIC is a gigabit sk that supports jumbo frames, so that part
works. I didn't find your patch until after I got it working. For
me, it was breaking large udp and icmp packets, possibly ipsec, too.
It's an annoying position to be in.

Well, Ethernet devices are not supposed to let such frames through;
and as I said, I had an unusual setup (for various reasons) which
broke down in that respect when I made my situation with my ISP
"normal".

Think of your position still as a privileged one, as a PPPoE
vict^Wuser.

What's the driver of your NIC? I'll revive that patch, and get it
committed as you will be able to test it.

[Martin Husemann]

I thought we added proper support to negotiate large MTUs, but (of course)
leave the default at the standard mandadet value.

If you change the mtu after creating the interface and the peer agrees
with your value, it should just work.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paul Ripke]

Post by Martin Husemann
I thought we added proper support to negotiate large MTUs, but (of course)
leave the default at the standard mandadet value.
If you change the mtu after creating the interface and the peer agrees
with your value, it should just work.

Hmm... But the packets are getting dropped by the underlying ethernet
interface, and I don't particularly want to change its MTU to 1508
since I also run my LAN off that NIC.

My problem is that both ends are advertising and accepting a 1492
byte MRU, but the remote end is actually using 1500 byte MTU. Very
annoying.

Cheers,

[Martin Husemann]

Post by Paul Ripke
Hmm... But the packets are getting dropped by the underlying ethernet
interface, and I don't particularly want to change its MTU to 1508
since I also run my LAN off that NIC.

Could you do it anyway just for a test, just to see if your PPPoE peer accepts
the MTU?

Thanks,

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paul Ripke]

Post by Martin Husemann

Post by Paul Ripke
Hmm... But the packets are getting dropped by the underlying ethernet
interface, and I don't particularly want to change its MTU to 1508
since I also run my LAN off that NIC.

Could you do it anyway just for a test, just to see if your PPPoE peer accepts
the MTU?

Hmm. Couldn't get past:
ifconfig: SIOCSIFMTU: Invalid argument
no matter what I tried. Reading the code, it should be possible.

Cheers,

[Martin Husemann]

Post by Paul Ripke
ifconfig: SIOCSIFMTU: Invalid argument
no matter what I tried. Reading the code, it should be possible.

I think you need to enlarge the mtu on the ethernet device before
assigning it to pppoe via pppoectl -e. The pppoe device then should pick
up the right mtu for itself automatically.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paul Ripke]

Post by Martin Husemann

Post by Paul Ripke
ifconfig: SIOCSIFMTU: Invalid argument
no matter what I tried. Reading the code, it should be possible.

I think you need to enlarge the mtu on the ethernet device before
assigning it to pppoe via pppoectl -e. The pppoe device then should pick
up the right mtu for itself automatically.

Yeah, I had about 6 goes. Roughly, my "best attempt" steps were:

ifconfig sk0 mtu 1560
ifconfig pppoe0 down destroy
ifconfig pppoe0 create debug
pppoectl -e sk0 pppoe0
pppoectl pppoe0 myauthproto=...
ifconfig pppoe0 inet 0.0.0.0 0.0.0.1 mtu 1500
ifconfig pppoe0 up

At the end, the interface MTU was 1492, and the MRU in the
negotiation was 1492. I'm pretty sure I tried without the
"mtu 1500" above, and it still ended up with 1492.

If I just tried:

ifconfig sk0 mtu 1560
ifconfig pppoe0 down debug
ifconfig pppoe0 mtu 1500

... and I'd get SIOCSIFMTU returning EINVAL.

Am I missing something?