Hello,

I am a very experienced Linux kernel and networking engineer (with a little kernel development experience).

I would like to know if the OpenWRT project can utilize any hardware currently on the market as a high-quality "PPPoE media convertor" ?

My specification for this task would be:
* DSL modem built in that supports ADSL2+
* DSL modem and driver _MUST_ be able to support full sized 1500byte ethernet packets over G.DMT/ATM
* Ethernet 10/100 built in
* Ethernet chipset and driver _MUST_ be able to support "mini-jumbo" packets (this allows for a working MTU of at least 1508 bytes or more, or ethernet frame sizes of 1526 or more which allows for payload and source/dest MACs, frame type and CRC)
* Ability to modify/have-access-to DSL modem driver to add support to keep statistics bit-rate/SNR/Atten/etc...
* Ability to write some custom kernel code to handle outbound packet queue to DSL modem (I won't bore the thread with the detail of this, so much to say that I just want to audit/rewrite the "decision point" about next packet selection each time the DSL modem needs feeding with more outbound data, I may also like to signal back towards the PPP-stack/router some flow control / back pressure indicator to allow it to adapt stratagy.  i.e. I want zero packet loss outside of the layer3/4 QoS features of the linux kernel, linux supports traffic shaping at higher levels which works best by knowing the effective bandwidth

The purpose of the extra 8 bytes of allowable ethernet MTU is to provide space for the PPPoE protocol overhead between the media convertor device and the host (which is running the PPP stack/endpoint).  Many standard ethernet cards on the market already support mini-jumbo packets, in fact many chipsets do with a minor tweak in the driver.

It seems that many PPPoE media convertor vendors just don't get it when it comes to this problem.

Maybe it would be possible to go one better with OpenWRT and develop and extension to the PPPoE protocol so that a negotiated "Ethernet frame type" could be setup and locked to a session number.  From this point on all frames passed between the MACs bearing the negotiated "Ethernet frame type" could be related to that session.

So which hardware would be a good candidate, does it actually matter ?   and what kind of DSL chipset support does OpenWRT/linux provide ?

(Last edited by Odin on 14 Nov 2009, 01:56)

I'm currently using a combination of Asus WL500gP and external USB ADSL modems like Speetouch 330 and/or ueagle compatible ones, the downside is that they don't support ADSL 2+. You have also the AR7 based options and I think brcm63xx, maybe they can use 2+.

Warning: I would like to be an expert like you to try to solve the current kernels problem (2.6.29 onwards) with linux-atm/br2684ctl  packages (not just in Openwrt but also in any Linux as far as i know).

Hope this helps.

Thank you for your reply.

Yes I have many years used (at many sites) Thompson/SGS Speedtouch 330 via USB, you are correct it does not support ADSL2+ but only a 2Mbit service    The Speedtouch supports full sized ethernet frames (1500byte MTU over ADSL interface) there are small issues with the drivers over time with reliability/durability, nothing a reboot doesn't fix

The devices I currently use for PPPoE media convertion and ADSL2+ support is Vigor 100/110 series.  I am initially looking to replace this function with something more under my control.   The other problem with these seperate boxes is how the applicance performs when the uplink is saturated in respect of packet-loss, this isn't helped by the fact that 100mbit ethernet is connected to it, if only the PPP host was given indication to throttle itself.

I am already using QoS at the IP layer of the PPP endpoint this effects outbound rate limiting, an odd concept for some to consider, but it stops the embedded device (the PPPoE media convertor) getting overwhelmed with outbound packets.  The next ideal now would be to have the PPPoE device talk to the rate limiter and 1) provide the initial/theoretical maximum and 2) provide achievable data rates, this being based on recent history and 3) provide flow control information such as queue depth/queue payload size.   This would allow the rate limiter to keep trying to push its luck to send more data, this will cause the PPPoE to start a packet queue and signal back about it.

There is one further situation that certain packet types might be given higher priority by the endpoint, for example PPP LCP Echo-Request/Response packets, even if the link is achieving the theoretical maximum in both directions due to saturation it is possible to end up disconnected because 3 LCP packets in a row got lost over 30 to 60 second interval.   This lowers the percieved quality of device/DSL service unecessarly.

I guess that some embeded devices have USB modems inside, I'm not aware of the 2.6.29+ kernel issues, maybe someone can cite a link.