Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
Christoph Biedl wrote... > Let's see. I have some time to kill tonight and will try to reproduce > the issue. If all else fails, I'll get back to you. When starting pptp manually, I also get the warning message: | Error: either "to" is duplicate, or "uid" is a garbage. Since James' patch is obviously about this issue (and makes the warning disappear), I've uploaded a new version of pptp-linux. You should see it in a few hours, give it a try. If your problem persists, feel free to re-open. Christoph signature.asc Description: Digital signature
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
manul wrote... > I dont think I am able to check this in a sense compiling/installing > latest code from upstream. > > If someone provides me with a deb package which includes the patch, I > could try installing it and report the results. Let's see. I have some time to kill tonight and will try to reproduce the issue. If all else fails, I'll get back to you. Christoph signature.asc Description: Digital signature
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
Package: pptp-linux
Version: 1.9.0+ds-1
Followup-For: Bug #887370
Dear Maintainer,
>> Upstream pptp-linux patch is 7d9a428 ("Remove uid from ip route get
>> output.").
> manul, can you check this? (Since it would take some time [days] until I
> could work on this.)
Yes I confirm that during the upgrade my iproute2 package crossed the 4.10.0
boundary.
I dont think I am able to check this in a sense compiling/installing latest
code from upstream.
If someone provides me with a deb package which includes the patch, I could try
installing it and report the results.
manul
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages pptp-linux depends on:
ii libc6 2.26-4
ii perl 5.26.1-4
ii ppp2.4.7-1+4
pptp-linux recommends no packages.
pptp-linux suggests no packages.
-- no debconf information
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
James Cameron wrote...
> If your iproute2 package crossed the 4.10.0 boundary, then "ip route
> get" will show uid, which pptp-linux will not handle as it parses the
> output carelessly.
Nice catch.
> Upstream pptp-linux patch is 7d9a428 ("Remove uid from ip route get
> output.").
manul, can you check this? (Since it would take some time [days] until I
could work on this.)
Christoph
signature.asc
Description: Digital signature
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
Speculating.
If your iproute2 package crossed the 4.10.0 boundary, then "ip route
get" will show uid, which pptp-linux will not handle as it parses the
output carelessly.
Upstream pptp-linux patch is 7d9a428 ("Remove uid from ip route get
output.").
https://github.com/quozl/pptp/commit/7d9a428a0744b3053767dc2d239f305c86f1fcee
--
James Cameron
http://quozl.netrek.org/
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
Package: pptp-linux Version: 1.9.0+ds-1 Followup-For: Bug #887370 Dear Maintainer, The list of updated packages is rather long (see below) and I lack competence to find out which one affected this behaviour (and to which package a fix needs to be applied). What I was able to determine is: - it is not related to an upgrade of ppp or pptp-linux (same versions of these packages worked fine before, they were not upgraded) - it is not related to kernel upgrade (when starting the system with the older kernel, the issue still persists) - one of the packages which *might* be related and which were upgraded is iproute2 So it seems to be kind if multi-package interrelated issue (for example - thus is only an amateur guess - like some old cmd syntax got deprecated in latest version of iproute2, so in case ppp uses this syntax to add the extra route, it no longer works). I have the issue reproduced on two separate sid/buster boxes, which I upgrade at the same time (with the same pptp VPN tunnel settings). Here is a list of the upgraded packages (after this dist-upgrade the issue appeared), as shown in /var/log/apt/history.log: Start-Date: 2018-01-13 08:44:21 Commandline: apt dist-upgrade Install: libplacebo2:amd64 (0.2.0-2, automatic), python3-distutils:amd64 (3.6.4-2, automatic), kdialog:amd64 (4:17.08.3-2, automatic), libnorm1:amd64 (1.5r6+dfsg1-6, automatic), libkf5kiogui5:amd64 (5.37.0-2, automatic), qml-module-org-kde-kirigami:amd64 (1.1.0-2, automatic), libkf5konq6:amd64 (4:17.08.3-2, automatic), libarchive13:amd64 (3.2.2-3.1, automatic), libqmobipocket2:amd64 (4:17.08.3-2, automatic), linux-image-4.14.0-3-amd64:amd64 (4.14.12-2, automatic), libsuitesparseconfig5:amd64 (1:5.1.2-1, automatic), libvlccore9:amd64 (3.0.0~rc5-1, automatic), libnfs8:amd64 (1.11.0-2, automatic), libprotobuf-lite10:amd64 (3.0.0-9.1, automatic), libilmbase23:amd64 (2.2.1-2, automatic), qt5-assistant:amd64 (5.9.2-5, automatic), keditbookmarks:amd64 (17.08.3-2, automatic), python3-lib2to3:amd64 (3.6.4-2, automatic), libsodium23:amd64 (1.0.16-2, automatic), libokular5core7:amd64 (4:17.08.3-2, automatic), libkf5kexiv2-15.0.0:amd64 (17.08.3-1, automatic), rxvt-unicode:amd64 (9.22-3, automatic), libgeos-3.6.2:amd64 (3.6.2-1, automatic), libical3:amd64 (3.0.1-5, automatic), libtesseract4:amd64 (4.00~git2188-cdc35338-2, automatic), libkf5jsapi5:amd64 (5.37.0-2, automatic), libmicrodns0:amd64 (0.0.8-1, automatic), libaribb24-0:amd64 (1.0.3-1, automatic), liblzo2-2:amd64 (2.08-1.2+b2, automatic) Upgrade: kde-baseapps-bin:amd64 (4:16.08.3-1, 4:16.08.3-3), qtermwidget5-data:amd64 (0.8.0-4, 0.8.0-5), kde-runtime-data:amd64 (4:16.08.3-2, 4:17.08.3-1), vlc-bin:amd64 (2.2.8-2+b1, 3.0.0~rc5-1), libjson-glib-1.0-0:amd64 (1.4.2-2, 1.4.2-3), libreoffice-style-breeze:amd64 (1:5.4.3-4, 1:5.4.4-1), libx265-146:amd64 (2.6-2, 2.6-3), dmz-cursor-theme:amd64 (0.4.4, 0.4.5), perl-base:amd64 (5.26.1-3, 5.26.1-4), libc-ares2:amd64 (1.13.0-2, 1.13.0-3), libreoffice-math:amd64 (1:5.4.3-4+b1, 1:5.4.4-1), libopencv-photo3.2:amd64 (3.2.0+dfsg-4, 3.2.0+dfsg-4+b3), libsoup-gnome2.4-1:amd64 (2.60.2-1, 2.60.2-2), mutt:amd64 (1.9.1-5, 1.9.2-1), bluez:amd64 (5.47-1, 5.47-1+b1), exim4-base:amd64 (4.90~RC3-2, 4.90-3), libcroco3:amd64 (0.6.12-1, 0.6.12-2), liblept5:amd64 (1.74.4-1, 1.74.4-2), vlc-plugin-video-output:amd64 (2.2.8-2+b1, 3.0.0~rc5-1), libdns-export169:amd64 (1:9.11.2+dfsg-4, 1:9.11.2+dfsg-5), libldb1:amd64 (2:1.2.2-2, 2:1.2.3-1), libhttp-message-perl:amd64 (6.13-1, 6.14-1), libcomerr2:amd64 (1.43.7-1, 1.43.8-2), libgpgmepp6:amd64 (1.9.0-8, 1.10.0-1), libavformat57:amd64 (7:3.4-4+b1, 7:3.4.1-1+b1), libreoffice-report-builder-bin:amd64 (1:5.4.3-4+b1, 1:5.4.4-1), fonts-ricty-diminished:amd64 (4.1.0-1, 4.1.1-1), libpython3.6-minimal:amd64 (3.6.4~rc1-1, 3.6.4-3), libpangoft2-1.0-0:amd64 (1.40.13-2, 1.40.14-1), libavfilter6:amd64 (7:3.4-4+b1, 7:3.4.1-1+b1), akonadi-server:amd64 (4:16.04.3-6+b1, 4:17.08.3-2), libnghttp2-14:amd64 (1.28.0-1, 1.29.0-1), libgles2-mesa:amd64 (17.2.5-1, 17.3.2-1), libgphoto2-port12:amd64 (2.5.16-1, 2.5.16-2), libumfpack5:amd64 (1:4.5.6-1, 1:5.1.2-1), glib-networking-services:amd64 (2.54.1-1, 2.54.1-2), libaudit-common:amd64 (1:2.8.1-2, 1:2.8.2-1), sound-theme-freedesktop:amd64 (0.8-1, 0.8-2), libart-2.0-2:amd64 (2.3.21-2+b2, 2.3.21-3), libisccfg160:amd64 (1:9.11.2+dfsg-4, 1:9.11.2+dfsg-5), libvte-2.91-0:amd64 (0.50.2-2, 0.50.2-3), libcups2:amd64 (2.2.6-2, 2.2.6-4), libvulkan1:amd64 (1.0.61.1+dfsg1-1, 1.0.65.2+dfsg1-1), libimlib2:amd64 (1.4.8-1, 1.4.10-1), intel-microcode:amd64 (3.20171117.1, 3.20180108.1), irqbalance:amd64 (1.2.0-0.2, 1.3.0-0.1), libkonq5-templates:amd64 (4:16.08.3-1, 4:16.08.3-3), libgtop2-common:amd64 (2.38.0-1, 2.38.0-2), libnih-dbus1:amd64 (1.0.3-9, 1.0.3-10), python-openssl:amd64 (16.2.0-1, 17.5.0-1), libphonon4:amd64 (4:4.9.0-4, 4:4.9.1-3), qml-module-qtwebkit:amd64 (5.212.0~alpha2-5, 5.212.0~alpha2-6), libdrm-nouveau2:amd64 (2.4.88-1, 2.4.89-1),
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
manul wrote... > IMPORTANT NOTE: > The bug seems not to belong to pptp-linux package per se, since this package > was not upgraded (and since the recent upgrade, the same pptp-linux version > worked ok). > So the upgrade of some other system packages actually broke this default > behaviour (iproute2 was one of the packages that were upgraded). > I am not sure however to which package to attribute the bug and therefore > posting the bug report against pptp-linux. Before looking closer: There should be a file /var/log/dpkg.log (perhaps older generations) containing a protocol which packages were upgraded and when. That should give a hint. Regards, Christoph signature.asc Description: Digital signature
Bug#887370: pptp-linux: when redirecting all traffic the host routing entry to VPNserver via old eth0 is not added automatically
Package: pptp-linux Version: 1.9.0+ds-1 Severity: important Dear Maintainer, I have a VPN tunnel configuration which aims to redirect all internet traffic via the remote VPN. The following pppd options are used in pppd tunnel configuration: defaultroute, replacedefaultroute Everything worked ok since recent dist-upgrade (3 days ago). Expected behaviour is so 'pon TUNNEL' replaces the default gw and creates two more new entries in the routing table, i.e. Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp0 VPNSERVER-PUBLIC-IP 192.168.0.1 255.255.255.0 UHG 0 0 0 eth0 VPNSERVER-INTERNAL-IP0.0.0.0 255.255.255.255 UH0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 00 eth0 Since recent system upgrade, 'pon TUNNEL' fails to automatically create host routing entry with the VPNSERVER-PUBLIC-IP via the old iface eth0, so now I get: Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp0 VPNSERVER-INTERNAL-IP0.0.0.0 255.255.255.255 UH0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 00 eth0 This leads to network not being accessible (and 100% cpu load). When the missing host routing entry is added manually, by 'route add -host gw 192.168.0.1' everything works ok. IMPORTANT NOTE: The bug seems not to belong to pptp-linux package per se, since this package was not upgraded (and since the recent upgrade, the same pptp-linux version worked ok). So the upgrade of some other system packages actually broke this default behaviour (iproute2 was one of the packages that were upgraded). I am not sure however to which package to attribute the bug and therefore posting the bug report against pptp-linux. Thanks, manul -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages pptp-linux depends on: ii libc6 2.26-4 ii perl 5.26.1-4 ii ppp2.4.7-1+4 pptp-linux recommends no packages. pptp-linux suggests no packages. -- no debconf information
