Profile cover photo
Profile photo
Kevin Otte
153 followers -
Linux, IPv6 geek. Air and space fan.
Linux, IPv6 geek. Air and space fan.

153 followers
About
Posts

Post has attachment

Post has attachment
The 80's text generator has been making the rounds today. My contribution:
Photo

Since filing bugs directly with the Google mothership is a noop, I figured I'd at least warn some folk here.

I have an OpenVPN to home that issues ULA space and individual routes to various VLANs. I got OpenVPN Connect installed on my Android 5.1 device, profile loaded, and brought up the connection.

I then tried to access a web server on one of the routed subnets in Chrome. It says:
This site can't be reached
grafana.mibloving.net's server DNS address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

I then started up Firefox and was able to access the site without issue.

Clearly Chrome is making some assumptions about its route availability, and is also giving a red herring of an error message.

Post has attachment

Post has attachment
If you're a Reddit user, could you pop over and upvote IPv6 on this thread?

Post has attachment

Post has attachment
Digital voice on HF. FlexRadio just added this mode to their latest software release, so there have been quite a few more stations on lately.

Putting aside briefly the shouting match that is https://code.google.com/p/android/issues/detail?id=32621, I brought up a test network with SLAAC+RDNSS and no IPv4 to drop my Android 5.1 tablet onto. I figured since Google said most of their stuff is IPv6 enabled, most everything should work, right? shakes head

Play Store, GMail, and well most everything failed with "No connection". I found this odd because the web versions of these things work just fine from an IPv6 only network. Why the lack of feature parity for the Android API services?

OK, I want to file a bug on this, but I don't even know where the appropriate place is or if I'm too far off in the weeds.

In Debuntu the common practice is to add a line to /etc/hosts on the order of:
127.0.1.1 mystic.home.nivex.net mystic

Now, this is a hideously IPv4-centric hack, so I decided to remove the line. Unfortunately that's when everything went sideways. Long story short, "hostname -d" no longer returns a value, which confuses things like Kerberos.

Doing an ltrace against hostname -d, I find that they system does a gethostname(), which returns the bare hostname, then does a getaddrinfo(...) against it to find the IP address, and then looks that up. When I mock this up in ipython:

In [1]: import socket

In [2]: socket.getaddrinfo(socket.gethostname(),None)
Out[2]:
[(10, 1, 6, '', ('2001:470:8:64f:21d:92ff:fed7:ad8a%4', 0, 0, 4)),
 (10, 2, 17, '', ('2001:470:8:64f:21d:92ff:fed7:ad8a%4', 0, 0, 4)),
 (10, 3, 0, '', ('2001:470:8:64f:21d:92ff:fed7:ad8a%4', 0, 0, 4)),
 (2, 1, 6, '', ('172.31.3.6', 0)),
 (2, 2, 17, '', ('172.31.3.6', 0)),
 (2, 3, 0, '', ('172.31.3.6', 0))]

Now I'm betting the %4 scope is what's confusing the system there. I could be wrong.

As an aside: most IPv6 hosts don't have reverse DNS, especially with DHCPv6-PD, so how best to do "127.0.1.1" in an IPv6-ish way?

Post has attachment
Wait while more posts are being loaded