This is to ask for a slight enhancement in the new multi-protocol IP printing. I'm keeping the bug thread because in our machines it revealed another problem with the code that's already there.
The new feature is indeed very useful but something else is needed: print the IP of the server even when the connection is successful, and also print any IPs that were tried but didn't work. These features are particularly important in the transition to IPv6, where many bugs in networking and machine configuration appear, and are complicated by the multiplicity of protocols and addresses. Printing the IP actually used is very important when the connection works but the server at the other end is not the expected one, or has a wrong behavior because the connection came via an unexpected address/route or client address. One of the many examples of this is when the dns name points to an organization for v4 but to another institution for v6, because the v4 one doesn't offer v6 yet. Printing the IPs that didn't work is important because rather frequently they should have worked... These problems become a nightmare when you do many updates every day spread among tens of different repositories from as many organizations. Wayne, it'd be really useful here... The attached path is a suggestion for 3.1; I've hidden it under --debug=CONNECT3. For 3.0.9 I suggest it for verbose > 2. The patch is very small because the current versions already almost do it. Putting it in production showed a bizarre error: the IP produced by inet_ntop (the line commented out) works for v4 but is wrong for IPv6. Here's an example: opening tcp connection to stage-rsync.mozilla.org port 873 Connected to ::2001:4f8:8:36:230:48ff The correct one is 2001:4f8:8:36:230:48ff:fedf:940e. It's wrong for all v6 addresses that we use, and is correct for all v4 ones. The call to inet_ntop looks correct; I don't know if this is a problem with our machines only. Changing to getnameinfo fixed it: opening tcp connection to stage-rsync.mozilla.org port 873 Connected to 2001:4f8:8:36:230:48ff:fedf:940e It thus seems to be a libc problem (glibc in our case). I tested it with Debian stable and unstable. Even if it's specific to this case it may cause portability problems. In the patch I did NOT change the existing code.
patch
Description: Binary data
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
