Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: brltty (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
> if there is an active IPv6 regular (non-loopback) interface with an
IPv6 address and network connection, then connection attempts to ::1
seem to hang and timeout
Probably it uses the default route to send packets to ::1, which is
deemed not to receive any response.
> I haven't seen any other
Yes you're right it is abnormal.
What's going on is that I had set the sysctl parameter
net.ipv6.conf.lo.disable_ipv6=1, which of course disables the IPv6 loopback.
But it exhibits a curious behavior where if there is an active IPv6
regular (non-loopback) interface with an IPv6 address and
Ok, I better understand why this has never shown up in most situations.
> my system has functional IPV4 and IPV6
Well, it still behaves oddly on the ip6-localhost case:
> connect(3, {sa_family=AF_INET6, sin6_port=htons(4101),
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", _addr),
(Sorry for the delay. Launchpad emails were in my spam)
The directory /var/lib/BrlAPI/ exists, but /var/lib/BrlAPI/0 does not exist.
brltty is not running on my system
strace output is below. my system has functional IPV4 and IPV6
strace: Process 2184 attached
connect(3, {sa_family=AF_INET6,
This is very surprising: what xbrlapi tries to connect to by default is
a local socket in /var/lib/BrlAPI/0 so that should be completely
independent from TCP/IP networking configuration, and should be either
succeeding or failing immediately.
Just to be sure: Does /var/lib/BrlAPI/0 exist? Is
Note that if the network is not connected during the login process, then
there is no delay, perhaps because xbrlapi fails immediately in that
scenario? But if I am connected to a network before login, the issue of
the delay due to xbrlapi occurs. This is specifically with X and not
Wayland.
--
7 matches
Mail list logo
