Bug 929447 - Incorrect "ipparam" manipulation
Summary: Incorrect "ipparam" manipulation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: xl2tpd
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-30 19:09 UTC by Michal Bruncko
Modified: 2015-01-13 09:46 UTC (History)
3 users (show)

Fixed In Version: xl2tpd-1.3.6-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-21 23:27:27 UTC


Attachments (Terms of Use)
ipparam-to-remotenumber patch (977 bytes, patch)
2013-03-30 20:58 UTC, Michal Bruncko
no flags Details | Diff

Description Michal Bruncko 2013-03-30 19:09:03 UTC
Description of problem:

Basically the problem is that "ipparam" pppd variable is modifed by xl2tpd daemon during establishing of L2TP VPN (using pppd) once the xl2tpd is calling pppd. And this modification cannot be overridden by "ipparam" parameter within ppp option file - it will remains ignored.

What this bahavior cause?
- xl2tpd modifies "ipparam" variable to remote IP of connecting client (in general it is public source IPv4 address of incomming VPN connection requests from client) - this is done instead of fact, that remote IP of client is accessible via global REMOTEIP pppd variable.
- and thus /etc/ppp/ipv6-up script (officially shipped with distribution) will always fail (returns 1) as it looks for configuration file of PPPDEVICE in form "ifcfg-X.X.X.X" where "X.X.X.X" is part given from "ipparam" provided within calling the ipv6-up script.


This request is similar of following requests:
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635472
- https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/947404


Version-Release number of selected component (if applicable):
xl2tpd-1.3.1-5.el6.x86_64


How reproducible:
always

Workaround:
- yes I can use unsupported openl2tpd
- or modify ipv6-{up|down} scripts, but those scripts will be always overwritten with every new release of initscripts package

Main reasons for this report:
- ipv6-up ppp script always fails 
- there is no official l2tp alternative for RHEL

Additional info:
- on mentioned web pages there is also patch provided for removing this unexpected modification of ipparam from xl2tpd.

Comment 1 Michal Bruncko 2013-03-30 20:58:49 UTC
Created attachment 718377 [details]
ipparam-to-remotenumber patch

This patch replaces "ipparam" with supported "remotenumber" variable.
- this parameter "remotenumber" can be used analogously like "ipparam" for logging IP's of connecting VPN clients via RADIUS plugin (without any additional code modification), AND
- this does not break ipv6-up script because ipparam can be defined to some meaningful value which allows matching specifed "ifcfg-$ipparam" config file and ipv6 configuration can seamlessly continues.

Comment 2 Fedora Update System 2013-04-02 03:25:33 UTC
xl2tpd-1.3.1-13.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xl2tpd-1.3.1-13.fc18

Comment 3 Fedora Update System 2013-04-02 03:48:03 UTC
xl2tpd-1.3.1-6.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/xl2tpd-1.3.1-6.el6

Comment 4 Fedora Update System 2013-04-03 02:01:19 UTC
Package xl2tpd-1.3.1-6.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing xl2tpd-1.3.1-6.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0874/xl2tpd-1.3.1-6.el6
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2013-05-22 03:13:33 UTC
xl2tpd-1.3.1-13.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Alexander Demenshin 2013-08-17 18:47:19 UTC
Sorry, but this patch actually does more evil than good. Since migration to F19 I've found that I couldn't see anywhere the LAC address (which was provided with ipparam) - and now, after checking changelogs, I know why.

REMOTEIP is actual IP assigned to remote client, while ipparam is merely additional parameter which pppd adds as 6th parameter when calling up/down scripts (man pppd: it is not used anywhere for anything in pppd itself).

Worse, "remotenumber" is not accessible in up/down scripts, thus making impossible to take any action in script based on LAC IP. Sure, you can still see it in radius logs - but only if you use or rely on radius, and don't need it in scripts (which is not always the case).

Surely it may break ipv6-up/down scripts, but more correctly would be to fix ipv6-ip/down scripts instead of breaking long established (and expected) behavior.

Therefore I kindly request to remove this patch, or at least, do it in the right way - add an option to xl2tpd which will control its behavior.

Thank you!

Comment 7 Paul Wouters 2013-08-19 19:11:48 UTC
re-opened to investigate

Comment 8 Fedora Update System 2014-05-13 15:37:01 UTC
xl2tpd-1.3.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xl2tpd-1.3.6-1.fc20

Comment 9 Fedora Update System 2014-05-13 15:38:52 UTC
xl2tpd-1.3.6-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xl2tpd-1.3.6-1.fc19

Comment 10 Fedora Update System 2014-05-13 15:40:01 UTC
xl2tpd-1.3.6-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/xl2tpd-1.3.6-1.el6

Comment 11 Fedora Update System 2014-05-14 23:55:27 UTC
Package xl2tpd-1.3.6-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xl2tpd-1.3.6-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6347/xl2tpd-1.3.6-1.fc19
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2014-05-21 23:27:27 UTC
xl2tpd-1.3.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2014-05-24 23:24:33 UTC
xl2tpd-1.3.6-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2014-05-31 18:35:54 UTC
xl2tpd-1.3.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 contact 2015-01-13 09:46:11 UTC
Hello,

I can verify that the problem still persists on "xl2tpd-1.3.6-1.el6.x86_64".

The variable "ipparam" isn't sent to radiusclient and therefore we receive empty "Calling-Station-Id" in our backend. 

If we manually set the ipparam variable in our /etc/ppp/options.xl2tpd we receive the seted value in our backend, which indicates that the bug is still here.


Note You need to log in before you can comment on or make changes to this bug.