| Summary: | openconnect routing problem | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | eric gerbier <eric.gerbier> |
| Component: | RPM Packages | Assignee: | David GEIGER <geiger.david68210> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins |
| Version: | 7 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | openconnect-8.10-1.mga7.src.rpm | CVE: | |
| Status comment: | |||
Thank you for the report, and apologies for the failure. One imagines that you have had this for a long time, since Mageia 7 is nearing end-of-life.
All I could check was that the straced embedded command
"/sbin/ip", "route", "get", "3.6.70.192/26"
looks sensible from its help:
$ sudo ip route help
...
ip route get [ ROUTE_GET_FLAGS ] ADDRESS
although the preceding "/sbin/ip" is a mystery.
Assigning this to DavidG as the main 'openconnect' committer; CC'ing DaveH in case he has any useful ideas.CC:
(none) =>
davidwhodgins ip route get 3.6.70.192 is valid ip route get 3.6.70.192/26 is not valid Did the /26 come from a config file? I don't have access to a vpn to test with. New iproute2 >= 5.1 doesn't like prefixes other than /32. Older versions silently ignores it.
$ rpm -qa iproute2
iproute2-4.14.1-1.mga6
$ ip route get 3.6.70.192/26
3.6.70.192 via x.x.x.x dev wlp2s0 src y.y.y.y uid 500
cache
$ rpm -qa iproute2
iproute2-5.10.0-1.mga7
$ ip route get 3.6.70.192/26
RTNETLINK answers: Invalid argument
$ ip route get 3.6.70.192/32
3.6.70.192 via x.x.x.x dev wlp2s0 src y.y.y.y uid 500
cache
Perhaps we should update vpnc's vpnc-script to the latest one from https://gitlab.com/openconnect/vpnc-scripts?
At least there is related commit https://gitlab.com/openconnect/vpnc-scripts/-/commit/c0122e891f7e033f35f047dad963702199d5cb9e.
So I update vpnc-script from latest openconnect commit for mga8 and also for mga7! - vpnc-0.5.3-16.mga8 - vpnc-0.5.3-14.1.mga7 Please test if issue is fixed, thanks in advance! I have tested today , and I have no changes.
I have allways the same warning messages :
RTNETLINK answers: Invalid argument
Usage: ip route { list | flush } SELECTOR
but the vpn seems to work anyway (telnet to enterprise is working)
Did this update fix an issue? If so, it needs to be assigned to QA now, or it will be removed from updates_testing soon. Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021. Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja Status:
NEW =>
RESOLVED |
Description of problem: I am using openconnect to connect to my enterprise vpn (cisco anyconnect). It connects to the vpn but then displays the following ip route errors : RTNETLINK answers: Invalid argument Usage: ip route { list | flush } SELECTOR ip route save SELECTOR ip route restore ip route showdump ip route get [ ROUTE_GET_FLAGS ] ADDRESS ... and when I want to use the vpn, I have routings problems : tshark/tcpdump shows only SYN paquets strace on openconnect displays strange calls such [pid 3882] 10:23:55 execve("/sbin/ip", ["/sbin/ip", "route", "get", "3.6.70.192/26"], 0x1d65a50 /* 153 vars */ <unfinished ...> Version-Release number of selected component (if applicable): openconnect-8.10-1.mga7 iproute2-5.10.0-1.mga7 How reproducible: every time on mageia 7. I have tested the same command on fedora 33, debian 10, ubuntu 20.10, and I do not have the same problem Steps to Reproduce: 1. openconnect anyconnect_server 2. 3.