RE: strange behavior with m0n0wall, PPPoE and Netgear Powerline connection.

The VLAN and PPOE additions are put into the frame last. You don't have to account for them during this test since you're trying to find the maximum payload that'll pass without fragmentation.

If the power-line adapters have a max MTU of 1500, you can only send 1490 to the m0n0wall box because it will add 10 bytes to the frame.  But part of that 1490 is consumed by headers and checksums.  If a payload of 1407 works, you should set your mtu to 1435.  If you want, you can subtract 40 to determine TCP MSS and change that also (1395 in your case)... you'll have to turn off PMTU in order to do this.  I suspect the latency you are seeing is related to PMTU not working because of NAT/Firewalling.  


-----Original Message-----
From: Peter Teunissen [mailto:[email protected]] 
Sent: Wednesday, November 09, 2011 2:48 PM
To: m0n0wall
Subject: Re: [m0n0wall] strange behavior with m0n0wall, PPPoE and Netgear Powerline connection.

OK, I used linux for this:

1408 (this includes icmp & ip) fails:

    $ ping -s 1380 -c 1 xs4all.nl
    PING xs4all.nl (194.109.21.8) 1380(1408) bytes of data.
    From m0n0wall.onemanifest.net (192.168.1.1) icmp_seq=1 Frag needed and DF set (mtu = 1400)

    --- xs4all.nl ping statistics ---
    1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

1407 works:

    $ ping -s 1379 -c 1 xs4all.nl
    PING xs4all.nl (194.109.21.8) 1379(1407) bytes of data.
    1387 bytes from xs8.xs4all.nl (194.109.21.8): icmp_req=1 ttl=61 time=38.9 ms

    --- xs4all.nl ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 38.996/38.996/38.996/0.000 ms


So, the max MTU would be 1407, but since there'll be PPPoE and VLAN also on the line, the MTU setting should be 1407 - 10 = 1397

Tried this, and it does increase the download with about 10Mb. Oddly enough, the upload remains low and unchanged.

Trying the ping on the m0n0wall itself (through exec.php) gives slightly different result: ideal mtu should be 1395. Tried, but the results are similar to MTU of 1397.



Thanks Ash


On 9 nov. 2011, at 03:11, Payne Jr, Ash C wrote:

> In windows,  do ping [ip] -f -l [MTU to test] 
> 
> -f says do not fragment
> -l sets the length of the payload 
> 
> If 1472 will pass,  but 1473 will not,  you should add 28 to 1472 to determine MTU.  28 is the necessary header size for IP and ICMP.
> 
> Best of luck,
> Ashworth
> 
> Sent from my iPhone
> 
> On Nov 8, 2011, at 6:08 PM, "Peter Teunissen" <[email protected]> wrote:
> 
>> That does make a difference, thanks! I tried lowering in small steps and going as low as 1400 made some difference in throughput. I'm getting close to the maximum the Powerline adapters can do. Need to do some more testing to find an optimal setting.
>> 
>> However, this doesn't affect latency. I'm still at 30ms as opposed to 7ms when using cable of Powerline adapters with the ISP supplied modem.
>> 
>> 
>> On 8 nov. 2011, at 23:39, Payne Jr, Ash C wrote:
>> 
>>> 1492 is too big. Add six bytes for ppoe and four bytes for VLAN tag.  That's ten.  The power line thingamabobs are causing fragments because frame size is 1510 with ppoe and a VLAN.  
>>> 
>>> Sent from my iPhone
>>> 
>>> On Nov 8, 2011, at 1:30 AM, "Peter Teunissen" <[email protected]> wrote:
>>> 
>>>> 
>>>> On 8 nov. 2011, at 02:22, Matthew Cramer wrote:
>>>> 
>>>> Did you force m0n0wall into accepting a PPPoE MTU of 1500 by editing the settings xml? Through the GUI if refuses to go over the default 1492.
>>>> 
>>>>> Try and raise the mtu to 1500. That fixed a problem for me using a vodafone femocell behind a monowall using PPOE.
>>>>> 
>>>>> Sent from my Android phone
>>>>> 
>>>>> On Nov 7, 2011 10:09 PM, "Peter Teunissen" <[email protected]> wrote:
>>>>> Tried lowering the PPPoE MTU setting. Tested with the default 1492, 1400 and 1200. No significant changes is speed, latency is the same. I don't know what an E packet is, so I can't tell whether it's different :-)
>>>>> 
>>>>> 
>>>>> On 7 nov. 2011, at 22:30, Eddie Pounce wrote:
>>>>> 
>>>>>> Long shot:  MTU?  or something - packet being split?
>>>>>>   They don't handle PPOE well (is the E packet formatted differently from normal?)?
>>>>>> 
>>>>>> On 07/11/2011 21:12, Peter Teunissen wrote:
>>>>>>> I'm running on a PIII 1Ghz. I just checked the speed test monitoring the CPU. It only goes slightly over 25% CPU. So I think CPU performance isn't the culprit. Also, when directly connected to the FTU by a cable, I get latency 7ms and 50+Mb up/down. It really has to do with being connect through the Powerline connectors while using PPPoE.
>>>>>>> 
>>>>>>> Peter
>>>>>>> 
>>>>>>> 
>>>>>>> On 7 nov. 2011, at 22:01, James L. Lauser wrote:
>>>>>>> 
>>>>>>>> What kind of hardware is your m0n0wall running on?  It's possible that
>>>>>>>> it's simply not fast enough to do the PPPoE encapsulation at that data
>>>>>>>> rate.  Take a look at the CPU utilization graph while trying to stress
>>>>>>>> your connection.  If you're pegging the CPU, you need a faster device.
>>>>>>>> 
>>>>>>>> --  James L. Lauser
>>>>>>>> [email protected]
>>>>>>>> http://jlauser.net/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Nov 7, 2011 at 15:54, Peter Teunissen <[email protected]> wrote:
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I've got an issue with m0n0wall and PPPoE that I can't explain.
>>>>>>>>> 
>>>>>>>>> - I have FTTH, 50Mb up/down, dual stack, connection is through PPPoE
>>>>>>>>> - When used with the ISP supplied router, I get 7ms latency, and 50Mb up/down
>>>>>>>>> - When m0n0wall is connected directly to the FTU with a cable and responsible for setting up the PPPoE, I get latency 7ms, 50+ up/down
>>>>>>>>> - When the setup is FTU > ISP router > Netgear powerline 500's > m0n0wall (static IP's on the m0n0wall) I still get a latency of 7 ms, only speed is about 48Mb, due to the Powerline connectors.
>>>>>>>>> - when testing the Netgear Powerline 500's separately, they perform consistently at about 48Mb with no dicernable effect on latency.
>>>>>>>>> 
>>>>>>>>> Now the surprise, when I connect the m0n0wall directly to the FTU, having it create the PPPoE by itself, but using the Netgear Powerlines instead of a cable, latency goes up to 25+ms and speeds are down to about 27Mb up/down.
>>>>>>>>> 
>>>>>>>>> I'd think this can't be caused by the Powerlines, since they perform fine by themselves and in combination with the ISP supplied router. Somehow, m0n0wall responds to the Powerline connection when using PPPoE instead of a static IP.
>>>>>>>>> 
>>>>>>>>> What kind of auto configuration does m0n0wall do when setting up PPPoE? It seems to somehow respond differently to the FTU's ethernet socket than to those of the Netgear Powerline.
>>>>>>>>> 
>>>>>>>>> I'm quite clueless about this. Does anyone have any suggestions as to where to look for an explanation or what to try to get m0n0wall to perform better in this setup?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Peter
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>> 
>>>> 
>>> 
>>> E-MAIL CONFIDENTIALITY NOTICE: 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> The contents of this e-mail message and 
>>> any attachments are intended solely for the 
>>> addressee(s) and may contain confidential 
>>> and/or legally privileged information. If you 
>>> are not the intended recipient of this message 
>>> or if this message has been addressed to you 
>>> in error, please immediately alert the sender
>>> by reply e-mail and then delete this message 
>>> and any attachments. If you are not the 
>>> intended recipient, you are notified that 
>>> any use, dissemination, distribution, copying, 
>>> or storage of this message or any attachment 
>>> is strictly prohibited.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 
> E-MAIL CONFIDENTIALITY NOTICE: 
> 
> 
> 
> 
> 
> 
> 
> The contents of this e-mail message and 
> any attachments are intended solely for the 
> addressee(s) and may contain confidential 
> and/or legally privileged information. If you 
> are not the intended recipient of this message 
> or if this message has been addressed to you 
> in error, please immediately alert the sender
> by reply e-mail and then delete this message 
> and any attachments. If you are not the 
> intended recipient, you are notified that 
> any use, dissemination, distribution, copying, 
> or storage of this message or any attachment 
> is strictly prohibited.
> 
> 
> 
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


E-MAIL CONFIDENTIALITY NOTICE: 

 

 

 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.