<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - systemd.socket unit bind with AF_INET6 on IPv4 ports (cups)" href="https://bugs.freedesktop.org/show_bug.cgi?id=84604#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - systemd.socket unit bind with AF_INET6 on IPv4 ports (cups)" href="https://bugs.freedesktop.org/show_bug.cgi?id=84604">bug 84604</a> from <a class="email" href="mailto:odyx@debian.org" title="odyx@debian.org <odyx@debian.org>"> odyx@debian.org</a> <pre>(For clarity, I'm the current CUPS maintainer for Debian). Let me try to rephrase then: CUPS got patched in Debian using a variation of your patch [0] to support socket activation. I'm trying to find a socket configuration that enables CUPS to be activated on both ipv6-enabled and ipv4-only hosts on all local IPs (that's the subject of <a href="https://bugs.debian.org/747073">https://bugs.debian.org/747073</a>), as well as on all public-facing IPs Now, with the following unit file: ListenStream=631 BindIPv6Only=both … on ipv6-enabled hosts, this will let CUPS be activated when accessing <a href="http://[::1]:631/">http://[::1]:631/</a>, <a href="http://localhost:631/">http://localhost:631/</a> or <a href="http://127.0.0.1:631/">http://127.0.0.1:631/</a>. In the two latter cases though, CUPS will not allow the connection (with 'Bad Request' and 'Forbidden' respectively) with messages like these in the error_log (debug2 level): Accepted from [v1.::127.0.0.1]:631 (IPv6) Request from "[v1.::127.0.0.1]" using invalid Host: field "localhost:631" cupsdIsAuthorized: auth=CUPSD_AUTH_DENY... With BindIPv6Only=ipv6-only, CUPS will not get activated on localhost or 127.0.0.1, of course. On ipv4-only hosts, BindIPv6Only will get discarded and CUPS will get activated _and_ accept the connections on localhost or 127.0.0.1 with "Accepted from 127.0.0.1:631 (IPv4). Now, as I understand it, on ipv6-enabled hosts, systemd will only create IPv6 (AF_INET6 ?) sockets, even on IPv4 addresses, which then causes confusion on the CUPS side (hence the funny [v1.::127.0.0.1] pseudo-IPv6 address coming from httpAddrString [1]), which doesn't expect IPv4 addresses over AF_INET6 (see the <a href="https://www.cups.org/str.php?L4491">https://www.cups.org/str.php?L4491</a> ), thereby refusing the connection. Now, a way around is to specify specifically ListenStream=127.0.0.1:631, but then adding ListenStream=[::1]:631, which will (of course) fail the unit activation on ipv4-only hosts. There doesn't seem to have a way to ask systemd to bind the socket if the address exists. So, if I understand it correctly, I think either systemd is wrong to bind sockets on IPv4 addresses with AF_INET6 and handing IPv4 addresses to CUPS or CUPS is wrong when checking the address over AF_INET6 sockets. The CUPS upstream author seems to think the problem is in systemd (see the CUPS bug linked above). (By the way, this is nowhere near my expertise field, so feel free to correct any of my misconceptions…) Opinions ? [0] <a href="http://sources.debian.net/src/cups/1.7.5-4/debian/patches/systemd-optional-socket-activation.patch">http://sources.debian.net/src/cups/1.7.5-4/debian/patches/systemd-optional-socket-activation.patch</a> [1] <a href="http://sources.debian.net/src/cups/1.7.5-4/cups/http-addr.c/#L403">http://sources.debian.net/src/cups/1.7.5-4/cups/http-addr.c/#L403</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>