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,
Well, this would be much more usefull... A modem dialup: async_ppp0=( '/dev/ttyS0' 'modem' 'ctsrts' )
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...
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
(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 #)
Oh, sorry: my fail. Its ok.
(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.
> 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.
(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
(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.
(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.
(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.
(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.
> (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?
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.
(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 :)
Created attachment 94931 [details, diff] Patch for pppd.sh 2200
Created attachment 94932 [details, diff] 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? :)
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?
(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.
(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.
(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.
Created attachment 94936 [details, diff] Patch for pppd.sh 2200 This is a more complete patch, with backward-compatibility.
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.
(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.
Comitted to svn, thanks for the patch.
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.
Fixed
