On Mon, 2017-07-10 at 15:44 -0700, Corey Hickey wrote: > The linked list implementation results in routes being queued in > reverse of the order in which they were received. So, when dequeuing > them, write to the buffer backwards. > > Signed-off-by: Corey Hickey <bugfood-ml at fatooh.org> ... > - *(p++) = ','; > + *(--p) = ','; > ? } > ? script_setenv(vpninfo, "CISCO_SPLIT_DNS", list, 0); That's CISCO_SPLIT_DNS that you're re-ordering, not CISCO_SPLIT_INC as it suggests in the subject. Arguably if order matters, then we ought to keep the list in the correct order in our internal data structures rather than deliberately keep it backwards and then *emitting* it in "reverse" order just because I was lazy about list-handling in cstp.c. But does ordering matter? For CISCO_SPLIT_INC it shouldn't. Those are an unordered list of networks which should be routed to this VPN connection; order really shouldn't matter. Even the overall routing table isn't ordered; it has explicit priorities (metric) for routes. For CISCO_DEF_DOMAIN (the DNS search domain) it does matter. If a hostname lookup fails, we try appending the search domains in *order* until we get a match, and we might get different results for 'foo' if both 'foo.example.com' and 'foo.example.org' both exist and those are our search domains. But in both AnyConnect and Juniper code those are just single strings, so we aren't processing multiple entities.? For CISCO_SPLIT_DNS... I don't think order matters, again. That's an unordered list of "if doing a DNS lookup in one of <these> domains, then ask the DNS server on the VPN, else ask your local DNS servers". If you think order matters there, you're Doing It Wrong?. We need to be careful to distinguish between 'search domain' (CISCO_DEF_DOMAIN) and 'domains to use this DNS server for' (CISCO_SPLIT_DNS). They are completely different things, and should not be conflated. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4938 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170814/6532267a/attachment-0001.bin>
