After emerging >=sys-apps/iproute2-4.10.0, pppd is not able to set up correct routing table. Similar issue has been encountered also in Arch: https://bbs.archlinux.org/viewtopic.php?id=224744 Could be this upstream error report: https://github.com/paulusmack/ppp/issues/81 Output while running with >=sys-apps/iproute2-4.10.0: Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 Error: either "to" is duplicate, or "uid" is a garbage. CHAP authentication succeeded MPPE 128-bit stateless compression enabled local IP address XXX remote IP address YYY Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 YYYYYYYYYYY 0.0.0.0 UG 0 0 0 ppp0 0.0.0.0 10.0.25.1 0.0.0.0 UG 203 0 0 eth0 YYYYYYYYYYY 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.25.0 0.0.0.0 255.255.255.0 U 203 0 0 eth0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo After downgrading to sys-apps/iproute2-4.9.0: Using interface ppp0 Connect: ppp0 <--> /dev/pts/3 CHAP authentication succeeded MPPE 128-bit stateless compression enabled local IP address XXX remote IP address YYY Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 YYYYYYYYYYY 0.0.0.0 UG 0 0 0 ppp0 0.0.0.0 10.0.25.1 0.0.0.0 UG 203 0 0 eth0 ZZZZZZZZZZ 10.0.25.1 255.255.255.255 UGH 0 0 0 eth0 YYYYYYYYYYY 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.25.0 0.0.0.0 255.255.255.0 U 203 0 0 eth0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo Notice - * no error message after downgrade: either "to" is duplicate, or "uid" is a garbage; * an extra line in routing table (marked as ZZZZ).
Can you please trace the exact ip command that is being run?
This bug also has hit FC26: https://bugzilla.redhat.com/show_bug.cgi?id=1476496 Calls to ip are: /bin/ip route get 5.179.xxx.xxx /bin/ip route replace 5.179.xxx.xxx via 10.0.25.1 dev eth0 src 10.0.25.2 With sys-apps/iproute2-4.9.0 there is no error message, with sys-apps/iproute2-4.14.1-r1, after second ip call I get infamous "Error: either "to" is duplicate, or "uid" is a garbage" and my routing table is missing one entry: 5.179.xxx.xxx 10.0.25.1 255.255.255.255 UGH 0 0 0 eth0
(In reply to MarisN from comment #2) > Calls to ip are: > /bin/ip route get 5.179.xxx.xxx > /bin/ip route replace 5.179.xxx.xxx via 10.0.25.1 dev eth0 src 10.0.25.2 Mea culpa. This is output from sys-apps/iproute2-4.9.0 With sys-apps/iproute2-4.14.1-r1 it looks like this (no idea if it makes difference): /bin/ip route get 5.179.0.66 /bin/ip route replace 5.179.0.66 via 10.0.25.1 dev eth0 src 10.0.25.102 uid 0 Error: either "to" is duplicate, or "uid" is a garbage. Both outputs are generated by patching iproute2: diff --git a/ip/ip.c b/ip/ip.c index b15e6b66..f3289bea 100644 --- a/ip/ip.c +++ b/ip/ip.c @@ -179,9 +179,14 @@ int main(int argc, char **argv) else basename++; - while (argc > 1) { + for (int i = 0; i < argc; i++) { + fprintf(stderr, "%s ", argv[i]); + } + fprintf(stderr, "\n"); + + while (argc > 1) { char *opt = argv[1]; - + if (strcmp(opt, "--") == 0) { argc--; argv++; break;
ppp should NOT be passing 'uid NUMBER' to the replace command. It's only valid in 'get', not add/del/change/append/replace. Rather than route -n output, can you please get me the output of 'ip -4 route' with both 4.9.0 and >=4.10? Open questions: 1. Why does PPP add it now? 2. If UID is meaningful for 'get', why isn't it meaningful for the add/replace etc. Theory: The field was always there, but is only being shown now, and ppp is copying it blindly.
Ok, in researching this, it's from ppp blindly copying route output. iproute2-4.10 added a 'uid' output on some routes, but it's only valid in output & get requests, and NOT to add/change/delete routes. ppp needs to be patches to do something meaningful with the uid line.
Created attachment 507778 [details, diff] Discard uid part of iproute2 ip route get This patch fixes the issue. Tested with iproute2-4.9.0 and iproute2-4.14.1-r1 on ~AMD64.
(In reply to MarisN from comment #6) > Created attachment 507778 [details, diff] [details, diff] > Discard uid part of iproute2 ip route get Ah. File name is not visible. This patch is for net-dialup/pptpclient (I have net-dialup/pptpclient-1.8.0 but should work as well with 1.7.x and 1.9.0 too).
That patch is hazardous: You're simply truncating at the point you see 'uid'. If there is another argument after uid in future, you're going to lose it. Here's a rough patch that I'm just writing in the comment box for a better way to do it: replacing 'uid XXXX' with whitespace. --- route = strdup(buf); + /* Starting with iproute2 4.10.0, call to 'ip route get' will contain uid value. + * Still uid should not be used in other calls (i.e. replace, delete). + * So we overwrite uid & the value with spaces. + */ + uidStart = strstr(buf, " uid"); + if (uidStart) { + const char * uidParamEnd = strstr(uidStart+4+1, " "); + if(!uidParamEnd) + uidParamEnd = strlen(buf); + // Find first space AFTER ' uid X' + for(const char* tmp = uidStart; tmp <= uidParamEnd; tmp++) + *tmp = ' '; + } --- You wrote this patch was for pptpclient? What about net-dialup/ppp. Was your initial report wrong?
(In reply to Robin Johnson from comment #8) > That patch is hazardous: You're simply truncating at the point you see 'uid'. > If there is another argument after uid in future, you're going to lose it. And then it will be necessary to explore this new argument use case (should or should not it be passed on to add/del etc. calls). Feel free to submit your patch upstream (they already accepted my hazardous approach and it works fine for me): https://sourceforge.net/p/pptpclient/git/ci/master/tree/ > You wrote this patch was for pptpclient? What about net-dialup/ppp. Was your > initial report wrong? It seems so – I call pppd and thus I assumed it to be at fault, but actually pppd is calling pptp client and thus the failure in pptp client is causing pppd connection misconfiguration. Now I know about pppd and pptp client more than I ever wanted to know.
*** Bug 641972 has been marked as a duplicate of this bug. ***
(In reply to MarisN from comment #9) > > You wrote this patch was for pptpclient? What about net-dialup/ppp. Was your > > initial report wrong? > It seems so – I call pppd and thus I assumed it to be at fault, but actually > pppd is calling pptp client and thus the failure in pptp client is causing > pppd connection misconfiguration. > Now I know about pppd and pptp client more than I ever wanted to know.
