Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=94931) [details]
Patch for pppd.sh 2200

Created an attachment (id=94932) [details]
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 an attachment (id=94936) [details]
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