y.st./source/pages/en/weblog/2015/12-December/10.xhtml

<?php
/**
 * <https://y.st./>
 * Copyright © 2015 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => '_services._dns-sd._udp.local.',
	'body' => <<<END
<p>
	I did some research today looking for a setting in Debian to make <a href="/en/domains/<code>cepo</code>.local.xhtml"><code>cepo</code></a> automatically boot back up after a power failure.
	I figured that it was a long shot to think that the operating system would have that level of control over the machine when powered off, but as the operating system can have the machine come back online after a reboot (instead of having the operating system shut the machine down, then needing the user to hit the power bullon to turn the machine back on), it might be possible.
	I never did find such a setting in the operating system, but I did find that <a href="https://technewsworld.com/story/78930.html">many $a[BIOS]es have such an option</a>.
	It was a bit of a pain to pull <code>cepo</code> out of the place I stashed it so I could connect it to a monitor and keyboard and take a look, but it payed off.
	The article said that older $a[BIOS]es do not have this option, so I was worried that <code>cepo</code> might not, but <code>cepo</code> was not as old as I had feared.
</p>
<p>
	I found a new tool today called mdns-scan.
	I do not yet fully understand the output, but it is successfully finding the powered-on machines that I know use $a[mDNS]:
</p>
<pre>+ Zero [00:1f:3a:77:67:48]._workstation._tcp.local
+ Zero._udisks-ssh._tcp.local
+ newdawn [00:19:7e:92:0d:8d]._workstation._tcp.local
+ cepo [00:11:50:d3:e0:11]._workstation._tcp.local</pre>
<p>
	Zero is Vanessa&apos;s laptop, which she left on when she left for school.
	I do not seem to be able to connect to any of those four apparent host names in the usual ways, so I am not sure if they are actually host names or just formatted somewhat like host names.
	The bracketed segment of these results seem to be the $a[MAC] addresses of our machines.
	It seems that the <code>_udisks-ssh</code> segment of the apparent host name is associated with a remote disk management application that Vanessa must have installed and I do not.
</p>
<p>
	It seems that the method of retrieving the list of local network services is fairly simple.
	$a[rDNS] is implemented by reformatting an $a[IP] address into a host name and issuing a PTR $a[DNS] record request on the resulting host name.
	The returned record is supposed to be the host name associated with the $a[IP] address.
	In $a[mDNS] service discovery, a similar method is used.
	The querying machine issues a PTR record query to the broadcast $a[IP] address requesting information about <a href="/en/domains/_services._dns-sd._udp.local.xhtml"><code>//_services._dns-sd._udp.local.</code></a> and any machine can answer with one or more host names.
	The returned host names seem to represent services that are available, though it seems that perhaps the returned host names are not the names that said machines will actually respond to, instead being more like descriptions of the services provided.
	This service-discovery method seems to be based on <a href="https://ietf.org/rfc/rfc6763.txt">a more general specification</a> not specific to $a[mDNS], though I do not seem to be able to get it to work with other domains.
</p>
<p>
	I initially had some problems passing $a[DNS] queries through <code>cepo</code> so that <code>cepo</code> could return responses for <code>//test.</code> and <code>//10.in-addr.arpa.</code> names.
	The issue was that either <code>cepo</code> would not pass queries that it did not have answers about onto the next $a[DNS] server or that such queries ended up creating a loop, as the router would ask the <code>cepo</code>, which would then ask the router, and so on.
	I am guessing that it was the former though, and queries just were not being forwarded at all.
	I found a <a href="https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04">$a[DNS] query forwarding tutorial</a> that helped me solve the problem.
	It was written for Ubuntu, but it works just as well on Debian.
	I used Google&apos;s $a[DNS] servers as the servers to query in case of zones that my server is not authoritative for, which is unfortunate, but it is better than using my $a[ISP]&apos;s $a[DNS] servers.
	My $a[ISP] captures invalid domains and redirects them to their partner&apos;s advertisement server.
	I have not yet made my server authoritative for any zones yet, but just having the network set up so that $a[DNS] queries pass through <code>cepo</code> without breaking anything is a good start.
</p>
<p>
	After changing the router settings a few times, I found that when the router goes down, <code>cepo</code> does not reconnect to it.
	This is a big problem, especially considering that <code>cepo</code> is now handling all $a[DNS] requests for all non-$a[Tor] users on the network.
	If <code>cepo</code> goes down, it is as if the network connection is down for my family.
	Somiaj from <a href="ircs://irc.oftc.net:6697/%23Tor">#Tor</a> suggested using wpasupplicant in roaming mode to make <code>cepo</code> reconnect automatically.
	I found a <a href="http://manual.aptosid.com/en/inet-setup-en.htm">guide for configuring roaming mode in wpasupplicant</a>, but it did not seem to offer working instructions.
	After finally getting everything working with help from a <a href="https://gist.github.com/ajfisher/a84889e64565d7a74888">second guide</a>, I noticed that I had missed something from the first.
	Following the first guide&apos;s instructions seems to give a better setup in my opinion, though somewhere along the way, I ended up using <code>auto wlan0</code instead of <code>allow-hotplug wlan0</code>.
	https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_basic_syntax_of_etc_network_interfacesIf I understand correctly, <a href="https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_basic_syntax_of_etc_network_interfaces"><code>allow-hotplug</code> is used when the Wi-Fi card will actually be added and removed from the machine while running, while <code>auto</code> is used to make the interface start up when the machine boots</a>.
</p>
<p>
	Cepo&apos;s Wi-Fi card does not seem physically sound.
	It was broken in the past, but I fixed it with pliers, thinking that that was the end of that.
	However, the antenna fell off again today and I had to once more squeeze the thing back together with pliers.
	Hopefully this will not be a frequent occurrence, especially with it currently residing on a high-up shelf that no one can reach without a stepping stool.
	It is out of the way and should not get bumped often.
</p>
<p>
	The person at the local community collage I wrote to got back to me today.
	As I expected, she was not the correct person to contact, but also as expected, she knew who I did need to contact.
	I have written to this second person now, so I hope to see what needs to be done soon.
</p>
<p>
	I believe that I have removed all hyperlinks from this website that use the <a href="/en/domains/quystystxtvdgyst.onion.xhtml">quystystxtvdgyst.onion.</a> domain.
	Hopefully, no other dead links exist on this website, at least not dead links involving my own domains.
	Maybe tomorrow, I will work on getting the new weblog index page set up.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);