Lost packets

[PaulnOZ]

I'm loosing inbound packets marked with the "Don't Fragment" flag set and am trying to find the culprit.

Can anyone confirm that their RT-N66U with Merlin's build rejects packets properly that are too large?

Many thanks,

Paul

RT-N66U Merlin's 3.0.0.4.374.38_2
ADSL PPPoE MTU 1492
N10 in bridge mode

 

[sinshiva]

heya;

[edit] ONLY use the script if ABSOLUTELY NECESSARY. I no longer see the problems that caused me to use it in the first place (devices hanging, etc)

add this to /jffs/scripts/wan-start

#!/bin/sh
WANMTU=`nvram get wan_mtu`
ifconfig eth1 mtu $WANMTU up
ifconfig eth2 mtu $WANMTU up
ifconfig br0 mtu $WANMTU up
ifconfig vlan1 mtu $WANMTU up

chmod a+rx /jffs/scripts/*

just set the mtu on the wan page and it updates for all the other interfaces

i also had to do this on my routers acting as switches, via dd-wrt

Administration > Commands

ifconfig eth0 mtu 1456 up
ifconfig eth1 mtu 1456 up
ifconfig vlan1 mtu 1456 up
ifconfig vlan2 mtu 1456 up
ifconfig br0 mtu 1456 up

(save to startup)

obviously you'll want to change yours to 1492

[edit/] just noticed the '#!/bin/sh' didn't copy/paste, sorry about that

 

[sinshiva]

also, for windows vista and later clients;

netsh interface ipv4 show subinterfaces to find the names;

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent

for wireless, on win 7 i generally see "Wireless Network Connection", but on a family member's win8.1 lappy, it's "Wi-Fi"

for android; enable install from unknown sources in dev options and download this; https://code.google.com/p/mtuchanger/

 

[jlake]

I think Merlin made some changes to possibly MSS clamping but I'm not sure though. Not sure exactly what changes he made. But it was related to MTU.

http://www.phildev.net/mss/blackhole_description.shtml

 

[sinshiva]

that's for the pptpd vpn server

[edit/] on a sidenote, i also enable 'accept PING requests from wan', in hopes path-mtu will help connections from the outside. haven't had any trouble yet

 

[sinshiva]

messed up the script when i copy/pasted, sorry; fixed

 

[jlake]

that's for the pptpd vpn server

[edit/] on a sidenote, i also enable 'accept PING requests from wan', in hopes path-mtu will help connections from the outside. haven't had any trouble yet

Oh. Thanks for clearing up Merlin's change.

I have experimented with enabling ping from wan in past and it made no difference. I never have problems with ipv4, but sometimes with ipv6, there are frag problems. Nothing to do with n66u as it also exhibits same behavior on linksys router. Some nights my path is fine. Some nights it's not. Out of my control.

Att DSL PPPoE 6rd tunnel
N66u
IPv4 MTU 1492
IPv6 MTU 1472

 

[sinshiva]

ahh, sorry to hear. i've never played with ipv6, tbh. sounds like a mechanism needs to be implemented or fixed for that

 

[jlake]

ahh, sorry to hear. i've never played with ipv6, tbh. sounds like a mechanism needs to be implemented or fixed for that

Well, I think it's just old school system admins on my path that don't want to risk their jobs to let fragmentation happen. It is improving though as Att has started to realize the problem and made some changes on how things are routed. So ipv6 path works much better now.

 

[PaulnOZ]

Thanks for the code, I'll try it out soon.

It does seem a little extreme though. Surely getting the router to respond to packets properly doesn't seem too big an ask surely, but hey, I just got here and missed most of the MTU discussions so what do I know.

I'm guessing this is just a temporary hack until something better comes along?

Paul

 

[sinshiva]

lol, well, thanks for being a guinea pig. maybe by the time i'm forced to use it, the bugs will be worked out

 

[sinshiva]

Thanks for the code, I'll try it out soon.

It does seem a little extreme though. Surely getting the router to respond to packets properly doesn't seem too big an ask surely, but hey, I just got here and missed most of the MTU discussions so what do I know.

I'm guessing this is just a temporary hack until something better comes along?

Paul

wish i could say one way or another, but i suspect not. dsl is tricky stuff for efficiency, i made a post on it that'll link in an edit here, but before i do; i read somewhere that pppoe encapsulation is more efficient than bridge LLC, despite the fact that LLC users like myself can potentially use 1500 mtu

[edit/] basically, with pppoe, the ideal MTU should be somewhere below 1488, but above my mtu of 1456

so, i found my most efficient MTU to be 1456. therefore, i'm now using tun-mtu 1384 for my configurations.

I don't entirely know how my internet connection works, but here goes.

This is the information i got from my eq660 adsl modem.

[edit15dec] images gone, using a westell 7500 now, anyway. [/edit]

it sorta helped. i learned a bit about ATM googling around and it's 48byte payload, 48*31 = 1488 MTU to fit evenly in ATM cells, etc, etc.

What I ultimately ended up doing was working my way down speedtesting each MTU, dropping 2 bytes at a time from 1488. My maximum down bandwidth would perceptibly drop steadily as it got closer and closer to the ideal MTU. when i hit 1456, my max bandwidth shot up to a bit higher than what i was getting with a 1500 MTU. i then tested this by going back up to 1457 MTU and speedtesting, and it was right back where it was as it was scaling down with the MTU size.

And that's how i figured out my ideal MTU size to be 1456

This is on CenturyLink ADSL with 10mbit down, for the moment. seeing about bumping that up by tonight, actually.

[edit/]

[edit15dec/]image gone, sorry

basically, i can readily confirm that 1456 is my perfect mtu by speedtesting 1457, which gives me a down speed of ~9.8mbit. set it down 1 byte to 1456, and i get ~10.15mbit

 

[sinshiva]

when testing your mtu, i'd first set the mtu on the router to the highest known MTU you should use, like 1492 for pppoe;

then from a client on your network, use the windows commands to lower it.

[edit/] after you find it, set it on the router

 

[PaulnOZ]

Thanks, but speed is the least of my worries at the moment.

Any inbound packets that are larger than my MTU get fragmented properly UNLESS they are flagged as "Don't Fragment". When that happens it appears the router simply silently drops them without a return notification.

I'm not certain if this is the router or somewhere outside (ISP). I'm actually hoping it's not the router, but I can't complain to the ISP until I am certain it's not.

I was hoping that someone else had already confirmed one way or the other, but if not, I guess it'll be up to me.

 

[L&LD]

On a VDSL line I set the WAN MTU (just now, thanks thread!) to 1514 and find this a noticeable improvement when browsing the net (it was 1500 default).

The only indication that this improvement is real is the Ookla speed test results showing a slightly improved (ever) download speed and a 1ms reduction in latency.

Don't know if this helps the OP, but an additional data point may be useful.

 

[sinshiva]

On a VDSL line I set the WAN MTU (just now, thanks thread!) to 1514 and find this a noticeable improvement when browsing the net (it was 1500 default).

The only indication that this improvement is real is the Ookla speed test results showing a slightly improved (ever) download speed and a 1ms reduction in latency.

Don't know if this helps the OP, but an additional data point may be useful.

nice, what a strange mtu lol. though, this is something i expected, that dsl users would find different mtus that worked for them. i spent a lot of time researching dsl mtu, more specifically encapsulation payloads and the only thing i could conclude is that even different implementations of the same types of bridging can cause this to vary from customer to customer. the only cases i foresee users having a truly identical mtu is if they are customers of the same isp AND reside in the same city

L&LD, while i know nothing about vdsl (i only know for certain adsl is over atm, which divides the 1500 ethernet frame into payloads of 48), 1514 seems weird; unless your isp has baby jumbos. i'll do some research on vdsl

 

[PaulnOZ]

hmmm, just thinking about it, is your script for a PPPoE LAN and LAN based clients logging into the ISP?

My setup is a DSL-N10 as a bridge modem and the RT-N66U as the ISP login router.
Router is the LAN DHCP through switches. Then I open ports to certain LAN IPs.

Otherwise, I'm a little confused.

 

[sinshiva]

Sorry, let me try and explain better;

when you are using pppoe, you setup your pppoe configuration on the router. normally, dsl would be setup so that the eth0 interface is at 1500, but everything being nat'ed is through the ppp0 tunnel. pppoe has overhead that takes up 8 bytes of the ethernet frame.

so what you have happen is:

ISP 1500byte ethernet frame has 1492byte pppoe frame inside. your router nats everything through the ppp0 interface rather than directly on eth0, so optimally your lan should see this and only send 1492byte frames to the router. this doesn't always happen and things hang. worse, some clients can't even be manually configured, like the xbox 360. by setting the lan side of the router to 1492, they have an easier time figuring that out, so they'll properly do the following even when they aren't set manually; (though i still advise setting everything manually, for mtu)

1492MTU ethernet frame client > 1492 lan interface > 1492 ppp0 > out the 1500 eth0 interface

[edit/] when i first posted the script, it was NOT for a PPPoE configuration, but i edited that post when i realized my mistake and created one for pppoe

i'm going to make a new script that works for both. i just remembered that i think i get do this by using `nvram get...`

nevermind, don't think that'll work

 

[PaulnOZ]

To answer my original question, which was, does the RT-N66U respond properly to oversized packets with the Don't Fragment flag set.

Yes it appears that it does. From the inside anyways. Still trying to figure out how to test it from the outside.

 

[sinshiva]

updated the first post with the improved script (and thanks merlin.)

on a sidenote, i'm not having any trouble from my clients anymore just letting everything on the lan side sit at 1500 mtu, with only the wan interface of the router set for 1456. this.. is excellent. i didn't particularly enjoy having to use that script. mostly because i hated having to configure every freakin thing on the lan, too. every time windows 8.1 'diagnoses' the connection, it reverts MTU back to 1500, even with 'store=persistent'. this made trying to figure out getting the isolated guest network setup right (see JRusso's thread) such an unbelievable freakin pain in the butt.

good riddance!