Hello Benoît! > > In the last days I built a patch available at: > > http://backsla.sh > thanks for submitting it and taking latest cvs version into account.
The hardest part was to locate the developers... Is it sf.net, eagle-usb.org or gna.org?! (-: Biggest problem on eagle-usb.org is that I dont speak French and the German, English and Spanish pages are mostly behind - if existing... <-: > > Please consider integration into main line! (-: > yep sl33p3r is working on it, I've got some questions (see below) (-: > > More information about this difficulty also at http://backsla.sh/ > > and posted in http://forum.eagle-usb.org (english, spanish section) > I saw it this morning... ...I thought nobody is interested. Compare the 12 views to the 13 replies(!) of the support question 12h later... [-: I added some paragraphs (look for "new resulting limits") to my web page. > 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 force or even ask 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 Bytes. 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 packets. > 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 Modem: COMTREND USB ADSL Modem Model: CT-351 P/N: 222417-074 H/W: 5002 USB id (operational): 1110:9021 LEDs: 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... Ciao, Robert
