My eagle-usb ADSL-Modem driver patch is now included since eagle-usb 1.9.9. Debian (at least unstable) provides 1.9.9 or later. So I removed the install instructions (you will find it actually in the HTML source as comment... :-)

You probably still have to remove the "mtu" and "mru" directive in the pppd configuration in case of PPPoA encapsulation...

What the patch changed and why:

(I changed the following text in some technical details (UDP, "default IP packet size", etc.) on 5.9.2004. I updated my knowledge, so I want the following paragraphs to reflect more the truth than before. - I didn't change the tense. So please remember that the text was written before the inclusion of the patch in eagle-usb.)

Lifts artificial MTU limits on the ppp device. This results in a "normal" sized MTU of 1500, probably the most common value in the Internet. Disables automatically all connectivity problems related to smaller MTU values...

Oh, hold on, this is only for PPPoA encapsulations. Important! I'm talking only about the two PPPoA methods. eagle-usb also supports other methods as well. The patch does not change anything there!

What was up to now? The eagle-usb package propagates some pppd options to use: "mtu 1492" and "mru 1492". The first sets the MTU of the ppp device to 1492 so that no bigger IP packets get injected there. The second requests the ppp peer not to send ppp packets with payloads bigger than 1492.

If the peer agrees we introduced successfully an artificial limit for our IP packets in the communication: 1492 bytes in size.

The pitfall: My ppp peer does not agree. The PPP defaults to a MTU of 1500. PPP implementation must support this value in case it gets used during handshake. Well, in the handshake my ADSL PPP peer is not willing to negotiate smaller MTUs. - And actually, from the protocol stack view, there is no need either.

What happens: While my PPP side won't send bigger packets as configured, the peer still feels great sending packets with 1500 byte payload and 2 byte PPP overhead.

The problem: The unpatched eagle-usb driver drops these packets.

The workaround: Never provoke the peer sending packets as big. PPP actually allows padding every packet to MTU size, so I cant prevent it 100% from doing so. But fortunately, my peer does no extra padding, so it's enough to keep the wrapped IP packet small. Very generally spoken, this is impossible as anybody can send me IP packets of any size. But I could influence upper layer protocols to negotiate the use of adequate packet sizes for communication. TCP is doing so automatically with the MSS option, which it already set's accordingly to the MTU of the interface. By this the TCP communication partner is advised to "not send packets bigger than I can handle (but, please bigger than 576...)". For UDP I would need to influence every application using this protocol as UDP does not decide about packet size, but the application does. Other protocols will still suffer if they don't sail round that problem like TCP does. Fazit: For a workstation, there is usually no problem visible as most UDP applications work with UDP packets <= 576 bytes.

If we connect more machines to the ADSL link, we do so by letting the directly connected computer play router with NAT aka Masquerading. As a router, the machine must accept all incoming packets up to MTU size. For the ppp peer this is 1502 byte. For eagle-usb unpatched this is 1500, bigger packets get dropped.

The router problem: A computer connected via Ethernet to the router would announce "I can handle packets up to 1500 bytes (Ethernet MTU)." Of course it can do so only with protocols allowing such announcements, like TCP with MSS option or others unknown to me. On the next TCP download, 1500 byte IP (makes 1502 byte PPP) packets will enter through the ADSL modem, but get dropped.

The router workaround: make all computers connected to the router think they have a smaller MTU by changing it on there corresponding interface. You can also connect them via a network which has naturally smaller MTUs (no, I have no suggestion... :-). Or you use the best know hack named "clamp MSS". Last one changes the MSS option of TCP handshake packets passing the router to a lower value. The new value will reflect the MTU of the ppp device. With Linux, "clamp MSS" is done with ipfilter for example. UDP or other protocols suffer at least like in the workstation case.

The real solution: dont drop the packets in the eagle-usb driver. The patch is widening the rx and tx path from pppd to the driver. As the adsl modem is transmitting ATM cells, there is no visible change for it. This solution is the only general one for UDP and all other protocols which don't expect total loss of packets with a specific size.

PPPoE similarities: You might wonder why this is only for PPPoA. Indeed, the technical background does not change... The difference is that PPPoE really imposes a smaller MTU. Too big packets don't arrive at eagle-usb, they arrive at your ISP where they won't fit into small PPP packets (below more on "small PPP packets"). The ISP machine has to fragment the big IP packet into smaller IP packets which fit into the little PPP packets. Fragmentation is not an option - it is a must. The reassembling is done at the target (or earlier). Fragmentation exception: the packet is carrying the "dont fragment" (DF) bit. The packet is dropped and an "ICMP fragmenation needed" message is send to the sender. On reception of ICMP fn the original sender will generate smaller packets further on.

Many hosts set the DF bit for Path MTU Discovering (PMTUD) which is a good thing, but the ICMP fn is sometimes filtered on the way to the sender, gets lost or isn't even generated. This problem is like "the router problem", happens only with the ADSL-connected computer acting as router and can be solved like in "The router workaround". Of course the patch as suggested workaround wont work as it can't eliminate encapsulation limits. But additionally you could switch off PMTUD at the other side or update it to a implementation which can deal which "black holes". The computer at your network can work with PMTUD, as it will get notified when sending too big packets (of course, dont filter ICMP fn in this network :-).

To the "small PPP packets": With PPPoE, the PPP packets get cramed into Ethernet frames. IP packets in these PPP packets must be smaller than the usual IP packets directly embedded into Ethernet frames. So, from normally 1500 bytes to 149x bytes.

Patch PPPoA: lift artificial limits --> MTU = 1500

Patch in details:

Some misnamings:

From the names I thougth, pppd is froming ppp packets, pppoa is turning them to ATM cells and the driver delivers them. But no, pppd is converting between IP packets (ppp0 interface) and PPP packets in HDLC-like frames to be transceived over a serial/stream-like channel (pty and device option of pppd). pppoa converts framed PPP from/to "naked" PPP packets with ethernet-like header in exchange with the eagle-usb network interface. The driver then chucks the ethernet-like header away (or generates one) and chops into AAL5 ATM cells (or reassembles from).

Everybody has noticed that the HDLC frames and the ethernet-like headers are only there to get removed again... That's reality. (-:

And very important: pppoa (the program) has nothing to do with ATM.

For the PPPoE case, ... next time... AAL5 ATM -- Ethernet frame ++ ethX ++ pppoe ++ HDLC PPP ++ pppd ++ ppp0 -- IP

pppoe is at least a good name for what it does. On the other side: PPPoA refers to the whole stack, PPPoE is just a part of something like "PPPoEoA". Remember, all ADSL lines I know carry ATM cell. In any case!

Future: change the driver to represent a ATM interface. Don't know if the 2.6-kernel has a working ATM-stack... But with all these ADSL-modems in this world it better should... (-:

If somebody has still no clue what the patch is good for or if you want to read the hole story and more in other words, read on. This is a snippet from a mail to the eagle-dev ML:

> From my understanding, you've identified two main impacts : 
>  - the peer (the ISP) does not accept mtu/mru at 1492, hence the user has to 
> configure (manually) mtu/mru at 1500 
>  - when the connected computer acts as a gateway some packets do not respect 
> this size either and are rejected 

Not quite. The two main impacts are:
-technical: there is no need to impose any MTU restrictions in the PPPoA
 case. PPPoA is capable of MTUs > 60000 bytes, so the _driver_
 should not limit it, especially not below the critical 1500 bytes.
-policy: An IP target host is allowed to simply drop packets > 576,
 but an IP router _must_ accept packets on all interfaces up to interface
 MTU. With PPPoA the ppp interface MTU is not fix, but an implementation
 must support at least 1500 bytes as specified by RFC1661. As the driver 
 does not fulfill it's PPP obligation (drops 1502 byte PPP packets 
 (1500 MTU + 2 byte PPP overhead)), the host (as router) can't fulfill
 it's IP duties.
 Note: it is correct behaviour from the PPP peer to reject smaller MTUs.

To directly answer your questions:

>  - the peer (the ISP) does not accept mtu/mru at 1492, hence the user has to 
> configure (manually) mtu/mru at 1500 

PPP is special. While on "normal" networks the MTU is for both
directions, with PPP it can be asymetric. From the start both PPP peers
are allowed to send 1500 bytes payload. One can allow the other to send
larger payloads (config option mru > 1500) or _ask_ it to send only
smaller payloads (config option mru < 1500). And, yes, my peer says NAK
to mru < 1500.

For sending a peer lowers the mtu by simply sendinger smaller payloads.
There is no way to ask or even force the other end for acceptance of
larger payloads.

So, the user can successfully set mtu to 149x (for sending), but the user
can't lower the mru (for receiving) neither automatically, nor
manually (with my PPP peer (ISP)).

>  - when the connected computer acts as a gateway some packets do not respect 
> this size either and are rejected 

Acting as a an IP gateway, leaving packets are fine, but incoming
packets (not all, but e.g. IP size = 1500) get dropped, not rejected. This
is the fault of the gateway.

> Am I right ? So your proposal is to get the module to adapt to any size it 
> receives (even if it not what has been negotiated). 

My proposal is in no case that the driver should support something the
PPP layer did not agree with. But as it has no idea what PPP negotiated,
it would ideally allow huge PPP packets. - I'm already fine with the
driver supporting MTU sizes which equal the minimal _enforceable_ mru.
I'm fine with that because it accidentally equals also the critical 1500

My proposal is to remove the extra policy in the driver. While actually
the limit should be set by protocol, at least let the buffers be the
limit of the driver, not some bad human decisions. Fortunately the
buffers are already big enough to handle the minimum case the driver
needs to support for beeing RFC1661 compilant. Or at least more
compilant than before... (-:

With my patch the driver still has limits which could be lower than what
the PPP layer agreed with. It is still up to the administrator to not
overstress the driver by not allowing the pppd to arrange huge PPP

> What is your ISP? Wanadoo/Eresmas?

It's Jazztel in Madrid/Spain. ADSL 1Mb/320kb. Including flatrate and
modem rent (no cheaper option): 45,24 EUR/month. Minimum 1 year
contract. Not including telefon line for voice/... call.
Probably can't be combinded with ISDN (or Spanish: RDSI).

VPI/VCI 8/35, PPPoA VC-mux

Model: CT-351
P/N: 222417-074
H/W: 5002

USB id (operational): 1110:9021

Link: blinking=syncronisation, on=link 
Data: blinking=data rx/tx, off=no activity
both on: something weird or usb initialisation or I don't know
both off: dead (-:  or not yet booting

Searching the web for modem/ISP were useless. Open the modem, read
what's on the chips, read the windows .ini-files of the included CD for
ADSL settings. Additional information: DNS server in booklet, same via
PPP. If I recall correct the chip was the second generation eagle.

> Have you seen similar reports or problems elsewhere? 

I've heard of MTU < 1500 problems elsewhere. As these can be semi-solved
with other methods, I don't know how similar they were. My first ADSL was
from Arrakis (256k/128k, VPI/VCI 0/35, PPPoA VC-mux, modem: Aztech DSL
100U, eciadsl linux driver), but I don't have any logs of the PPP
handshake anymore. There where no mtu/mru pppd options, but I used the
link never with a router...