On Thu, 2015-10-22 at 15:26 +0200, Gert Doering wrote: > > NAK on that - it's extra code, another "two branches that need testing" > addition, and I have not seen any mention of these "weird issues" yet - > so please explain the problem scenario better. > > (I might be happy to go for "use adapter index, always!", but I really > *really* do not want "try this, fall back to that!" unless it's well > understood why this is needed). > > Also, I wonder why this is not needed for route addition if it's needed > for ip address setting..
Because Windows. You don't get to *understand*; you just get to work around the brokenness. And drink. I've had reports of something similar happening with OpenConnect on a German Windows installation too. At http://lists.infradead.org/pipermail/openconnect-devel/2015-June/003033.html is a log showing the interface name failing for some operations, and working for others: 2015-06-17 10:48 executing: netsh interface ipv4 set subinterface "Ethernet 2" mtu=1342 store=active 2015-06-17 10:48 Element nicht gefunden. 2015-06-17 10:48 Configuring "Ethernet 2" interface for Legacy IP... 2015-06-17 10:48 executing: netsh interface ip set address "Ethernet 2" static 137.248.72.208 255.255.255.0 2015-06-17 10:48 Element nicht gefunden. 2015-06-17 10:48 executing: netsh interface ip add wins "Ethernet 2" 192.168.16.26 index=1 2015-06-17 10:48 executing: netsh interface ip add dns "Ethernet 2" 137.248.1.5 index=1 2015-06-17 10:48 executing: netsh interface ip add dns "Ethernet 2" 137.248.21.22 index=2 2015-06-17 10:48 done. Besides, route addition doesn't use the network interface name on Windows, does it? FWIW the reporting user said that *renaming* the interface would make the problem go away: http://lists.infradead.org/pipermail/openconnect-devel/2015-July/003088.html -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
