Appears sane is only IPV6 for network connections. Workarounds?

crackpipe · 01-02-2015, 05:56 PM

I was recently at a buddy who has an old Brother MFC8840D on his WiFi LAN. I printed via CUPS but also wanted to try to scan -- I've heard it can be difficult on a network. It was.

In root or as user, I was unable to bind a socket. There's probably a workaround in /etc/hosts settings or some such, but this appears to be a situation where it won't drop back to IPV4 when it tries to bind the socket. Here is the relevant spot it fails as root in "strace scanimage -L"

Code:

socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 132
setsockopt(132, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(132, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(132, {sa_family=AF_INET6, sin6_port=htons(8612), inet_pton(AF_INET6, "fe80::b277:2173:31a6:e71", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=if_nametoindex("enp4s0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
fstat(2, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
write(2, "[bjnp] ", 7[bjnp] )                  = 7
write(2, "create_broadcast_socket: bind so"..., 95create_broadcast_socket: bind socket to local address failed - Cannot assign requested address
) = 95
close(132)

Do I need to put something like "ffff" as a prefix in my Hosts file; some other? Thanks.

unSpawn · 01-03-2015, 05:09 AM

Quote:

Originally Posted by crackpipe

(..) this appears to be a situation where it won't drop back to IPV4 when it tries to bind the socket.

That appears to be the case when getaddrinfo() gets a usable IPv6 result back. (As in why would it ignore a perfectly good response?) I guess you'll have to find out how to make IPv4 stack address resolution requests take precedence over IPv6 ones:
0) see if you have "options inet6" in/etc/resolv.conf,
1) see if you have "multi on" in /etc/host.conf,
2) see if you have a "/etc/gai.conf" file. If you have one comment everything out, make these the last two lines:

Code:

# For sites which prefer IPv4 connections:
precedence ::ffff:0:0/96 100

Then strace lookups again and check for difference in behaviour.

crackpipe · 01-31-2015, 02:40 PM

Quote:

Originally Posted by unSpawn

That appears to be the case when getaddrinfo() gets a usable IPv6 result back. (As in why would it ignore a perfectly good response?) I guess you'll have to find out how to make IPv4 stack address resolution requests take precedence over IPv6 ones:
0) see if you have "options inet6" in/etc/resolv.conf,
1) see if you have "multi on" in /etc/host.conf,
2) see if you have a "/etc/gai.conf" file. If you have one comment everything out, make these the last two lines:

Code:

# For sites which prefer IPv4 connections:
precedence ::ffff:0:0/96 100

Then strace lookups again and check for difference in behaviour.

Thank you very much. The issue was apparently a Brother requirement for a scanning backend when on a network (as opposed to USB scanning). Once I installed the Brother backend for network scanning, the IPV6 situation went away. However the notes you made are extremely helpful and logical for anyone looking to solve an IPV4/6 problem. I used to run into those before curl was updated, for example.

In this problem, I should have known that, just because the MFC-8840D is a printer has zero to do with its scanning firmware. In other words, CUPS has no bearing on the scanning and provides no hidden support in the process. Indeed, once the backend was installed, scanning was accomplished over the network entirely without the CUPS daemon even being enabled. So it's a simple matter of getting the Brother network scanning backend.

I'd like to somehow note this as "solved" but not sure how to edit the title here. Thanks again for the great feedback.