144194 2006-08-17 05:24 0000 wrong pppoa usage specs with >=sys-apps/baselayout-1.12.4-r4 2006-09-14 03:22:12 0000 1 1 1 Unclassified Gentoo Linux baselayout 2006.0 All Linux RESOLVED FIXED P2 major --- 1 g.tomassoni@libero.it uberlord@gentoo.org net-dialup@gentoo.org g.tomassoni@libero.it 2006-08-17 05:24:16 0000 Dears, there is a problem with the new way >=sys-apps/baselayout-1.12.4-r4 allows defining a pppd connection. When using pppd for a PPPoA connection, there is no way to specify pppoatm.so plugin's options, like 'vc-encaps', 'llc-encaps' or even the [itf.]vpi.vci address because the 'plugin pppoatm.so' directive is appended after the pppd options themself in the pppd runstring, thereby causing 'unknown option' errors. The problem is easily circumvented by: 1) specifing link_ppp0='/dev/null' 2) not specifing the plugins_ppp0=( 'pppoa' ) 3) specifing the pppoa plugin and its options in the pppd_ppp0=( ) array. Anyway, this basically defeats the purposes of the plugins_ppp0 parameter, is an inelegant solution and may need external actions, like in loading the pppoatm kernel module. The fastest fix for this is to specify plugins at the beginning of the pppd runstring, thereby allowing them to interpret their own options correctly. Maybe it is too late, but I would also suggest a different schema for the pppd parameters, in which the high-level (i.e.: lcp, ipcp and network) options are specified by the pppd_ppp0=( ) array, while low-level (i.e.: device and connect) options are specified by arrays which resemble the device type. Non-device and non-connect plugins (like the auth ones) may still be specified by the plugins_ppp0=( ) array, provided they are placed early in the runstring. Examples: A modem dialup: async_ppp0=( '/dev/null' 'modem' 'ctsrts' ) A pppoa: pppoa_ppp0=( '0.8.35' 'vc-encaps' ) A pppoe: pppoe_ppp0=( 'eth1' ) Regards, g.tomassoni@libero.it 2006-08-17 05:33:49 0000 Well, this would be much more usefull... A modem dialup: async_ppp0=( '/dev/ttyS0' 'modem' 'ctsrts' ) mrness@gentoo.org 2006-08-17 06:10:01 0000 We designed plugins_ppp0 to cope with the eventual parameters of the plugins. Lets say you need to pass bar param to the foo plugin. This could be accomplished as follows: plugins_ppp0=( 'foo bar' ) @Roy: Maybe this should be mentioned in net.example... g.tomassoni@libero.it 2006-08-17 06:26:46 0000 Well, I have this in /etc/conf.d/net: config_ppp0=( 'ppp' ) link_ppp0='/dev/null' plugins_ppp0=( 'pppoa' ) username_ppp0='myusername' password_ppp0='mypassword' pppd_ppp0=( 'updetach' 'defaultroute' 'persist' 'maxfail 0' 'holdoff 5' 'mtu 1456' 'pppoa 0.8.35 vc-encaps' 'ipcp-accept-remote' 'ipcp-accept-local' ) and I get this (sys-apps/baselayout-1.12.4-r6): * Caching service dependencies ... [ ok ] * Service net.ppp0 starting /usr/sbin/pppd: unrecognized option 'pppoa' pppd version 2.4.3 Usage: /usr/sbin/pppd [ options ], where options are: <device> Communicate over the named device <speed> Set the baud rate to <speed> <loc>:<rem> Set the local and/or remote interface IP addresses. Either one may be omitted. asyncmap <n> Set the desired async map to hex <n> auth Require authentication from peer connect <p> Invoke shell command <p> to set up the serial line crtscts Use hardware RTS/CTS flow control defaultroute Add default route through interface file <f> Take options from file <f> modem Use modem control lines mru <n> Set MRU value to <n> for negotiation See pppd(8) for more options. * Service net.ppp0 started uberlord@gentoo.org 2006-08-17 06:29:10 0000 (In reply to comment #2) > We designed plugins_ppp0 to cope with the eventual parameters of the plugins. > Lets say you need to pass bar param to the foo plugin. This could be > accomplished as follows: > plugins_ppp0=( 'foo bar' ) > > @Roy: Maybe this should be mentioned in net.example... > Something like this? #plugins_ppp0=( # "pppoe" # Required plugin for PPPoE # "pppoa 0.8.35 vc-encaps" # Example plugin for PPPoA # "capi" # Required plugin for ISDN #) g.tomassoni@libero.it 2006-08-17 06:35:21 0000 Oh, sorry: my fail. Its ok. mrness@gentoo.org 2006-08-17 06:55:02 0000 (In reply to comment #4) > # "pppoa 0.8.35 vc-encaps" # Example plugin for PPPoA That should do it. Anyway, most plugins have parameters, even though you need to take a look in the plugin's source for discovering it. g.tomassoni@libero.it 2006-08-17 07:10:24 0000 > Something like this? > #plugins_ppp0=( > # "pppoe" # Required plugin for PPPoE > # "pppoa 0.8.35 vc-encaps" # Example plugin for PPPoA > # "capi" # Required plugin for ISDN > #) There is a thing I don't like too much: the fact that some ppp conn types are handled specially with respect to others. In pppoa, the '0.8.35' option may be seen as the ppp link device. In pppoe, in example, the 'ethX' link device is specified through the link_pppY variable, not by plugin options. There should be a way to abstract this details in a common setup interface in order to 'get things simpler' to the user. uberlord@gentoo.org 2006-08-17 07:25:49 0000 (In reply to comment #7) > There is a thing I don't like too much: the fact that some ppp conn types are > handled specially with respect to others. In pppoa, the '0.8.35' option may be > seen as the ppp link device. In pppoe, in example, the 'ethX' link device is > specified through the link_pppY variable, not by plugin options. > > There should be a way to abstract this details in a common setup interface in > order to 'get things simpler' to the user. OK, think of something. Once Alin (mrness here) agrees to it then I'll put it into baselayout mrness@gentoo.org 2006-08-17 07:27:59 0000 (In reply to comment #7) > ... In pppoa, the '0.8.35' option may be seen as the ppp link device. Not true. These are simple parameters (in this case, VPI&VCI) to an unnamed interface (although for ISDN and PPPoA /dev/null must be used as interface name). In PPPoE case we used link_ppp0 to pass the interface name, which is in fact one of the parameters of the plugin, but I cannot invent a name for PPPoA & ISDN. It isn't our fault, blame it on those who implemented ATM without associated interfaces, prolly thinking you will never have more than one such interface on your computer. g.tomassoni@libero.it 2006-08-17 07:37:21 0000 (In reply to comment #9) > (In reply to comment #7) > > ... In pppoa, the '0.8.35' option may be seen as the ppp link device. > Not true. These are simple parameters (in this case, VPI&VCI) to an unnamed > interface (although for ISDN and PPPoA /dev/null must be used as interface > name). No, 0.8.35 isn't: it is the atm address to which to bound the atm pvc. It is needed and has semantically the same meaning of eth0 in pppoe or ttyS0 in async. vc-encaps is a true option. > In PPPoE case we used link_ppp0 to pass the interface name, which is in fact > one of the parameters of the plugin, but I cannot invent a name for PPPoA & > ISDN. It isn't our fault, blame it on those who implemented ATM without > associated interfaces, prolly thinking you will never have more than one such > interface on your computer. What about the same? link_ppp0='0.8.35' would be fine. Encaps and qos parameters in plugin options are more than reasonable. g.tomassoni@libero.it 2006-08-17 07:54:26 0000 (In reply to comment #9) > It isn't our fault, blame it on those who implemented ATM without > associated interfaces, prolly thinking you will never have more than one such > interface on your computer. Trust me, I would have to blame the Linux's ATM stack a lot. But not for this. There can't be such a thing like an 'ATM associated interfaces' simply because ATM is a circuit standard, not a transport or media one. You use the socket() and connect() calls to open a VC with a given [itf.]vpi.vci and that's a (the only?) correct thing to do with ATM. From the pppd viewpoint, a 'device' is something linking the daemon to its peer. A [itf.]vpi.vci address is a pppd device when pppoatm is around, as well as ethX (and you don't have /dev/ethX) is with pppoe. mrness@gentoo.org 2006-08-17 08:04:20 0000 (In reply to comment #10) > No, 0.8.35 isn't: it is the atm address to which to bound the atm pvc. It is > needed and has semantically the same meaning of eth0 in pppoe or ttyS0 in > async. > > vc-encaps is a true option. What about ADSL concentrators made by Zyxel? I have a command named "show pvcs", which displays the PVCs on all interfaces, from 1-n. All interfaces have the same VPI.VCI settings which, according to you, broke the written rule that says every interface is uniquely identified by its name. When I say interface, I usually imagine some device connecting 2 things. In PPPoA case, is the ADSL modem. But if you consider those numbers a "interface", you should also consider the encapsulation (VC or LLC). As PVC (another name for VPI.VCI if you ask me), encapsulation is a mandatory ATM parameter, needed for properly configuring the interface. Anyway, I'm against considering PVC as interface name. g.tomassoni@libero.it 2006-08-17 08:56:21 0000 > (In reply to comment #10) > What about ADSL concentrators made by Zyxel? I have a command named "show > pvcs", which displays the PVCs on all interfaces, from 1-n. All interfaces have > the same VPI.VCI settings which, according to you, broke the written rule that > says every interface is uniquely identified by its name. But that's not the interface to have that address: it is just that each interface has only one VC open. You're talking of 'show pvcs', not something like 'show itfs': in such a command (don't know if it exists in that Zyxel) you wouldn't see the PVC address, because an ATM interface is not a PVC. A pvc is a link to a specific peer *through* an interface, not an ATM interface itself. With ADSL this doesn't happen (yet), but you may use an interface with multiple VCs at the same time. That's quite the same thing with ISDN, but more powerfull: not just at most 2-3 VCs, but as many as you like. > When I say interface, I usually imagine some device connecting 2 things. Well, right. In ATM they connect a customer with an ATM provider. > In PPPoA case, is the ADSL modem. Wrong. The ADSL modem is (often) connected to your ATM provide, which may even not be your Internet provider. Usually, this is the way things go, but the ATM standard is more powerful than this. In pppd you have to specify the 'device' which connects you to your ISP, not your telephone company. Think the ADSL modem is the media device. The VC may rightly be tought as the 'link'. After all, you have the link_pppX= option, not the interface_pppX= or device_pppX=. So... A peer-to-peer link in ATM is a VC. That's a quite common mistake to think that a vpi.vci address is like, say, the mac one on ethernet interfaces, or -even worse- the IP address assigned to an ethernet interface. But this isn't. A VC is conceptually much more close to a /dev/ttyS0 than an ATM interface. This confusion will be wiped as soon as ADSL lines will start carring ATM voice channels too through the very same ADSL line (and without using the imperfect VoIP). Then, the zyxel's 'show pvcs' will probably carry more than one line per interface... > But if you consider those numbers a "interface", you should also consider the > encapsulation (VC or LLC). As PVC (another name for VPI.VCI if you ask me), > encapsulation is a mandatory ATM parameter, needed for properly configuring > the interface. No, encapsulation is out of the ATM VC specs and is not mandatory: if you don't specify it, the pppoatm plugin enters in a 'discovery mode' for it (see pppoatm.c sources). A peer-to-peer channel in an ATM interface is a VC (Virtual Circuit), which is identified just by it's vpi.vci address. So, a "link" in the ppp meaning is uniquely identified by a itf.vpi.vci address. > Anyway, I'm against considering PVC as interface name. It's a circuit, a link. It's like an asynchronous line. link_ppp0= is great for it. Anyway, pppd.sh works the way it is now too, so... PS: is it politically correct to have this debate here? Do we have to move to some forum? mrness@gentoo.org 2006-08-17 10:03:33 0000 OK, you convinced me. You seem to be a wiz in ATM, while my knowledge about it is minimal at best. Roy, there are following things to consider when you made the change. 1) The old style config must be compatible with the new module. This means /dev/null should be considered a valid link for PPPoA. 2) When link_ppp0 is configured in the new style, the module should append /dev/null to the command line, just as it does now (not sure if it is necessary though). 3) net.example should be changed according to the new style. Also, it should make it clear that plugins accept additional parameters. uberlord@gentoo.org 2006-08-22 16:32:54 0000 (In reply to comment #14) > Roy, there are following things to consider when you made the change. I find myself short of time and am going on holiday soon. If this is required in a month or so, I suggest someone donates a patch :) g.tomassoni@libero.it 2006-08-23 06:27:29 0000 Created an attachment (id=94931) Patch for pppd.sh 2200 g.tomassoni@libero.it 2006-08-23 06:32:13 0000 Created an attachment (id=94932) Patch for net.example rev.2101 for pppoa I don't know if you are asking that to me, Roy. But, after all, I'm the reported of this bug, so... Have a look at the two attached files. They do work with this in conf.d/net: config_ppp0=( 'ppp' ) link_ppp0='0.8.35' plugins_ppp0=( 'pppoa vc-encaps' ) username_ppp0='your_username' password_ppp0='your_password' pppd_ppp0=( 'updetach' 'defaultroute' 'ipcp-accept-remote' 'ipcp-accept-local' ) The net side effect is that this is quite incompatible with the previous way. You may, however, avoid strict conformance to the new one by deleting the lines in which I'm checking ${!link} content. Oh, by the way: whom do I have to send the invoice to, Roy? :) mrness@gentoo.org 2006-08-23 06:45:05 0000 Not good enough. See comment #14, paragraph 1 and 2. link_ppp0=/dev/null *must* be considered valid in PPPoA case. Also, I don't understand the "connect true" sequence. Why do you think it is necessary? g.tomassoni@libero.it 2006-08-23 06:52:20 0000 (In reply to comment #18) > Not good enough. See comment #14, paragraph 1 and 2. > link_ppp0=/dev/null *must* be considered valid in PPPoA case. These lines from the patch enforce an ATM address in ppp0_link: + if [[ ! ( ${!link} =~ '^[ \t]*([1-9]*[0-9]\.){1,2}[1-9]*[0-9][ \t]*$' ) ]] ; then + eerror "an [itf.]vpi.vci ATM address was expected in ${link}" + return 1 + fi + Removing them you have a backward-compatible patch. I added them just to enforce a common behaviour in users, which shurely helps when gentoo will have to change things again. > Also, I don't understand the "connect true" sequence. Why do you think it is > necessary? It was in the pppoe case and it doesn't hurt: both pppoe and pppoa don't need a connect script. I guess it's there to avoid problems to people used to the 'call' option. In the overall: I wanted to minimize changes. mrness@gentoo.org 2006-08-23 07:02:36 0000 (In reply to comment #19) > Removing them you have a backward-compatible patch. I added them just to > enforce a common behaviour in users, which shurely helps when gentoo will have > to change things again. You're welcome to try explaining it to all PPPoA users. I'm sure they'll be glad to break their working setup, especially those who don't have physical access to the computer. g.tomassoni@libero.it 2006-08-23 07:11:13 0000 (In reply to comment #20) > You're welcome to try explaining it to all PPPoA users. I'm sure they'll be > glad to break their working setup, especially those who don't have physical > access to the computer. Well, this already happened: I posted this bug report because my pppd setup was rejected by the new baselayout. If you don't like this, no problem: remove the check lines. Or replace 'eerror' with 'ewarning' (does it exists?). However, Alin, I just sent my own view of a short-and-simple patch with respect to the issue here raised. If you have your own view, well, submit it. g.tomassoni@libero.it 2006-08-23 07:28:46 0000 Created an attachment (id=94936) Patch for pppd.sh 2200 This is a more complete patch, with backward-compatibility. mrness@gentoo.org 2006-08-25 08:49:30 0000 Yeah, this version looks OK to me. Does it work for your PPPoA link for both variants of link_ppp0? I'm asking because, when you set PVC in link_ppp0, you don't have /dev/null appended to your options. g.tomassoni@libero.it 2006-08-25 10:20:33 0000 (In reply to comment #23) > Does it work for your PPPoA link for both variants of link_ppp0? I'm asking > because, when you set PVC in link_ppp0, you don't have /dev/null appended to > your options. With net-dialup/ppp-2.4.3-r16 it seems ok: /proc/net/atm/pvc reports an open VC with the address specified in link_ppp0. Also, pppd doesn't complain about the missing /dev/null. However, I have a CLIP connection here: the pppoa one is a 30Km apart, on a server on which I don't have direct access (nor I want attempt a remote reboot now). But I wouldn't dislike to have it further tested if you have an 'handy' pppoa ADSL link. If you prefer, I can attach the patched pppoa.sh script instead of just the patch file. uberlord@gentoo.org 2006-09-06 01:59:47 0000 Comitted to svn, thanks for the patch. g.tomassoni@libero.it 2006-09-11 07:25:10 0000 Just to avoid putting my name on non-working stuff, I did take the time to test the pppd script. I did put both the 'old' and 'new' confs under test. They were something like this (in /etc/conf.d/net, of course): # # First test conf # (the old way) config_ppp0=( 'ppp' ) username_ppp0='my-user-name' password_ppp0='my-password' link_ppp0='/dev/null' plugins_ppp0=( 'pppoa 0.8.35 vc-encaps' ) pppd_ppp0=( 'defaultroute' 'persist' 'maxfail 0' 'holdoff 30' 'ipcp-accept-remote' 'lcp-echo-interval 12' 'lcp-echo-failure 5' ) # # Second test conf # (the new way) config_ppp0=( 'ppp' ) username_ppp0='my-user-name' password_ppp0='my-password' link_ppp0='0.8.35' plugins_ppp0=( 'pppoa vc-encaps' ) pppd_ppp0=( 'defaultroute' 'persist' 'maxfail 0' 'holdoff 30' 'ipcp-accept-remote' 'lcp-echo-interval 12' 'lcp-echo-failure 5' ) Both worked as expected. The former reported a: WARNING: An [itf.]vpi.vci ATM address was expected in link_ppp0 but of course operations proceeded anyway. Just wondering the why of the /dev/null parameter in the pppd runstring: I even tried running pppd by hand with a runstring equivalent to both the confs, and didn't see any difference in keeping or removing the /dev/null option. I mean, in example, this: echo -n my-password | ( sleep 1; pppd /dev/null unit 0 remotename ppp0 user 'my-user-name' linkname ppp0 defaultroute persist maxfail 0 holdoff 30 ipcp-accept-remote lcp-echo-interval 12 lcp-echo-failure 5 plugin passwordfd.so passwordfd 3 plugin pppoatm.so 0.8.35 vc-encaps 3<&0 ) and this: echo -n my-password | ( sleep 1; pppd unit 0 remotename ppp0 user 'my-user-name' linkname ppp0 defaultroute persist maxfail 0 holdoff 30 ipcp-accept-remote lcp-echo-interval 12 lcp-echo-failure 5 plugin passwordfd.so passwordfd 3 plugin pppoatm.so 0.8.35 vc-encaps 3<&0 ) did behave the same. Bye. PS: You're welcome, Roy. uberlord@gentoo.org 2006-09-14 03:22:12 0000 Fixed 94931 2006-08-23 06:27 0000 Patch for pppd.sh 2200 pppd.sh-pppoa.patch text/plain LS0tIHBwcGQuc2gtMjEwMQkyMDA2LTA4LTIzIDEzOjE2OjU4LjAwMDAwMDAwMCArMDIwMAorKysg cHBwZC5zaAkyMDA2LTA4LTIzIDE0OjA0OjEyLjAwMDAwMDAwMCArMDIwMApAQCAtMTQ0LDkgKzE0 NCwxMSBAQAogCQlbWyAke3BsdWdpblswXX0gPT0gInBwcG9hIiBdXSAmJiBwbHVnaW5bMF09InBw cG9hdG0iCiAJCVtbICR7cGx1Z2luWzBdfSA9PSAiY2FwaSIgXV0gJiYgcGx1Z2luWzBdPSJjYXBp cGx1Z2luIgogCi0JCVtbICR7cGx1Z2luWzBdfSA9PSAicnAtcHBwb2UiIF1dICYmIG9wdHM9IiR7 b3B0c30gY29ubmVjdCB0cnVlIgotCQlvcHRzPSIke29wdHN9IHBsdWdpbiAke3BsdWdpblswXX0u c28gJHtwbHVnaW5bQF06MX0iCi0JCVtbICR7cGx1Z2luWzBdfSA9PSAicnAtcHBwb2UiIF1dICYm IG9wdHM9IiR7b3B0c30gJHshbGlua30iCisJCWlmIFtbICR7cGx1Z2luWzBdfSA9PSAicnAtcHBw b2UiIHx8ICR7cGx1Z2luWzBdfSA9PSAicHBwb2F0bSIgXV0gOyB0aGVuCisJCQlvcHRzPSIke29w dHN9IGNvbm5lY3QgdHJ1ZSBwbHVnaW4gJHtwbHVnaW5bMF19LnNvICR7cGx1Z2luW0BdOjF9ICR7 IWxpbmt9IgorCQllbHNlCisJCQlvcHRzPSIke29wdHN9IHBsdWdpbiAke3BsdWdpblswXX0uc28g JHtwbHVnaW5bQF06MX0iCisJCWZpCiAJZG9uZQogCiAJI1NwZWNpYWxpemVkIHN0dWZmLiBJbnNl cnQgaGVyZSBhY3Rpb25zIHBhcnRpY3VsYXIgdG8gY29ubmVjdGlvbiB0eXBlIChwcHBvZSxwcHBv YSxjYXBpKQpAQCAtMTY4LDYgKzE3MCwxMSBAQAogCWZpCiAKIAlpZiBbWyAiICR7b3B0c30gIiA9 PSAqIiBwbHVnaW4gcHBwb2F0bS5zbyAiKiBdXSA7IHRoZW4KKwkJaWYgW1sgISAoICR7IWxpbmt9 ID1+ICdeWyBcdF0qKFsxLTldKlswLTldXC4pezEsMn1bMS05XSpbMC05XVsgXHRdKiQnICkgXV0g OyB0aGVuCisJCQllZXJyb3IgImFuIFtpdGYuXXZwaS52Y2kgQVRNIGFkZHJlc3Mgd2FzIGV4cGVj dGVkIGluICR7bGlua30iCisJCQlyZXR1cm4gMQorCQlmaQorCiAJCWlmIFtbICEgLWQgL3Byb2Mv bmV0L2F0bSBdXSA7IHRoZW4KIAkJCSMgTG9hZCB0aGUgUFBQb0Ega2VybmVsIG1vZHVsZQogCQkJ aWYgISBtb2Rwcm9iZSBwcHBvYXRtIDsgdGhlbgpAQCAtMTc1LDYgKzE4Miw4IEBACiAJCQkJcmV0 dXJuIDEKIAkJCWZpCiAJCWZpCisKKwkJaW5zZXJ0X2xpbmtfaW5fb3B0cz0wCiAJZmkKIAlbWyAk e2luc2VydF9saW5rX2luX29wdHN9IC1lcSAwIF1dIHx8IG9wdHM9IiR7IWxpbmt9ICR7b3B0c30i CiAK 94932 2006-08-23 06:32 0000 Patch for net.example rev.2101 for pppoa net.example-pppoa.patch text/plain LS0tIG5ldC5leGFtcGxlLTIyMDAJMjAwNi0wOC0yMyAxNDoyMDoyOC4wMDAwMDAwMDAgKzAyMDAK KysrIG5ldC5leGFtcGxlCTIwMDYtMDgtMjMgMTQ6MjQ6NTguMDAwMDAwMDAwICswMjAwCkBAIC0z OTMsNyArMzkzLDggQEAKICMgRWFjaCBQUFAgaW50ZXJmYWNlIHJlcXVpcmVzIGFuIGludGVyZmFj ZSB0byB1c2UgYXMgYSAiTGluayIKICNsaW5rX3BwcDA9Ii9kZXYvdHR5UzAiIAkJIyBNb3N0IFBQ UCBsaW5rcyB3aWxsIHVzZSBhIHNlcmlhbCBwb3J0CiAjbGlua19wcHAwPSJldGgwIiAgICAgICAJ CSMgUFBQb0UgcmVxdWlyZXMgYW4gZXRoZXJuZXQgaW50ZXJmYWNlCi0jbGlua19wcHAwPSIvZGV2 L251bGwiCQkJIyBQUFBvQSBhbmQgSVNETiBsaW5rcyBzaG91bGQgaGF2ZSB0aGlzCisjbGlua19w cHAwPSJbaXRmLl12cGkudmNpIgkJIyBQUFBvQSByZXF1aXJlcyB0aGUgQVRNIFZDJ3MgYWRkcmVz cworI2xpbmtfcHBwMD0iL2Rldi9udWxsIgkJCSMgSVNETiBsaW5rcyBzaG91bGQgaGF2ZSB0aGlz CiAjbGlua19wcHAwPSJwdHkgJ3lvdXJfbGlua19jb21tYW5kJyIJIyBQUFAgbGlua3Mgb3ZlciBz c2gsIHJzaCwgZXRjCiAjCiAjIEhlcmUgeW91IHNob3VsZCBzcGVjaWZ5IHdoYXQgcHBwZCBwbHVn aW5zIHlvdSB3YW50IHRvIHVzZQpAQCAtNDAxLDcgKzQwMiw3IEBACiAjCQkJIHJhZGF0dHIsIHJh ZHJlYWxtcyBhbmQgd2luYmluZCAKICNwbHVnaW5zX3BwcDA9KAogIwkicHBwb2UiCQkJCSMgUmVx dWlyZWQgcGx1Z2luIGZvciBQUFBvRQotIwkicHBwb2EgMC44LjM1IHZjLWVuY2FwcyIJIyBFeGFt cGxlIHBsdWdpbiBmb3IgUFBQb0EKKyMJInBwcG9hIHZjLWVuY2FwcyIJCSMgUmVxdWlyZWQgcGx1 Z2luIGZvciBQUFBvQSB3aXRoIGFuIG9wdGlvbgogIwkiY2FwaSIJCQkJIyBSZXF1aXJlZCBwbHVn aW4gZm9yIElTRE4KICMpCiAjCg== 94936 2006-08-23 07:28 0000 Patch for pppd.sh 2200 pppd.sh-pppoa.patch text/plain LS0tIHBwcGQuc2gtMjEwMQkyMDA2LTA4LTIzIDEzOjE2OjU4LjAwMDAwMDAwMCArMDIwMAorKysg cHBwZC5zaAkyMDA2LTA4LTIzIDE1OjI4OjI5LjAwMDAwMDAwMCArMDIwMApAQCAtMTQ0LDkgKzE0 NCwxMSBAQAogCQlbWyAke3BsdWdpblswXX0gPT0gInBwcG9hIiBdXSAmJiBwbHVnaW5bMF09InBw cG9hdG0iCiAJCVtbICR7cGx1Z2luWzBdfSA9PSAiY2FwaSIgXV0gJiYgcGx1Z2luWzBdPSJjYXBp cGx1Z2luIgogCi0JCVtbICR7cGx1Z2luWzBdfSA9PSAicnAtcHBwb2UiIF1dICYmIG9wdHM9IiR7 b3B0c30gY29ubmVjdCB0cnVlIgotCQlvcHRzPSIke29wdHN9IHBsdWdpbiAke3BsdWdpblswXX0u c28gJHtwbHVnaW5bQF06MX0iCi0JCVtbICR7cGx1Z2luWzBdfSA9PSAicnAtcHBwb2UiIF1dICYm IG9wdHM9IiR7b3B0c30gJHshbGlua30iCisJCWlmIFtbICR7cGx1Z2luWzBdfSA9PSAicnAtcHBw b2UiIHx8ICggJHtwbHVnaW5bMF19ID09ICJwcHBvYXRtIiAmJiAkeyFsaW5rfSAhPSAnL2Rldi9u dWxsJyApIF1dIDsgdGhlbgorCQkJb3B0cz0iJHtvcHRzfSBjb25uZWN0IHRydWUgcGx1Z2luICR7 cGx1Z2luWzBdfS5zbyAke3BsdWdpbltAXToxfSAkeyFsaW5rfSIKKwkJZWxzZQorCQkJb3B0cz0i JHtvcHRzfSBwbHVnaW4gJHtwbHVnaW5bMF19LnNvICR7cGx1Z2luW0BdOjF9IgorCQlmaQogCWRv bmUKIAogCSNTcGVjaWFsaXplZCBzdHVmZi4gSW5zZXJ0IGhlcmUgYWN0aW9ucyBwYXJ0aWN1bGFy IHRvIGNvbm5lY3Rpb24gdHlwZSAocHBwb2UscHBwb2EsY2FwaSkKQEAgLTE2OCw2ICsxNzAsMTIg QEAKIAlmaQogCiAJaWYgW1sgIiAke29wdHN9ICIgPT0gKiIgcGx1Z2luIHBwcG9hdG0uc28gIiog XV0gOyB0aGVuCisJCWlmIFtbICR7IWxpbmt9ID1+ICdeWyBcdF0qKFsxLTldKlswLTldXC4pezEs Mn1bMS05XSpbMC05XVsgXHRdKiQnIF1dIDsgdGhlbgorCQkJaW5zZXJ0X2xpbmtfaW5fb3B0cz0w CisJCWVsc2UKKwkJCWV3YXJuICJXQVJOSU5HOiBBbiBbaXRmLl12cGkudmNpIEFUTSBhZGRyZXNz IHdhcyBleHBlY3RlZCBpbiAke2xpbmt9IgorCQlmaQorCiAJCWlmIFtbICEgLWQgL3Byb2MvbmV0 L2F0bSBdXSA7IHRoZW4KIAkJCSMgTG9hZCB0aGUgUFBQb0Ega2VybmVsIG1vZHVsZQogCQkJaWYg ISBtb2Rwcm9iZSBwcHBvYXRtIDsgdGhlbgo=