<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Defective Semantics &#187; openwrt</title>
	<atom:link href="http://scarff.id.au/blog/tag/openwrt/feed/" rel="self" type="application/rss+xml" />
	<link>http://scarff.id.au</link>
	<description>Dean Scarff's perpetual struggle with technology, and other anecdotes</description>
	<lastBuildDate>Thu, 03 Nov 2011 22:39:55 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>dudders and reliable DNS zone updates</title>
		<link>http://scarff.id.au/blog/2010/dudders-and-reliable-dns-zone-updates/</link>
		<comments>http://scarff.id.au/blog/2010/dudders-and-reliable-dns-zone-updates/#comments</comments>
		<pubDate>Mon, 23 Aug 2010 03:48:26 +0000</pubDate>
		<dc:creator>Dean</dc:creator>
				<category><![CDATA[Problems]]></category>
		<category><![CDATA[Programs]]></category>
		<category><![CDATA[dns]]></category>
		<category><![CDATA[dudders]]></category>
		<category><![CDATA[openwrt]]></category>

		<guid isPermaLink="false">http://scarff.id.au/?p=485</guid>
		<description><![CDATA[<p>I&#8217;ve released a new version of dudders, 1.04, and finally submitted it as a package to OpenWRT.  The focus of this release was on making the update more robust to network failure as the result of an email correspondence with Peter Holik.  I am of the opinion that DNS UPDATE is a strong candidate for being TCP by default (along with zone-transfers).</p>
<p>In RFC 1123 it is stipulated that:</p>
<blockquote cite="http://tools.ietf.org/html/rfc1123#page-75"><p>a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.</p></blockquote>
<p>However, if you are doing a DNS UPDATE you really want the reliability that TCP offers, even if you don&#8217;t expect truncation to be an issue.  The update is sent to the relevant authority server, so the arguments about load on root servers in the RFC aren&#8217;t applicable.</p>
<p>I&#8217;ve made the UDP implementation retry by default, but I think if you need more&#8230; <a href="http://scarff.id.au/blog/2010/dudders-and-reliable-dns-zone-updates/" class="read_more">more</a></p>]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve released a new version of dudders, 1.04, and finally submitted it as a package to OpenWRT.  The focus of this release was on making the update more robust to network failure as the result of an email correspondence with Peter Holik.  I am of the opinion that DNS UPDATE is a strong candidate for being TCP by default (along with zone-transfers).</p>
<p>In RFC 1123 it is stipulated that:</p>
<blockquote cite="http://tools.ietf.org/html/rfc1123#page-75"><p>a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.</p></blockquote>
<p>However, if you are doing a DNS UPDATE you really want the reliability that TCP offers, even if you don&#8217;t expect truncation to be an issue.  The update is sent to the relevant authority server, so the arguments about load on root servers in the RFC aren&#8217;t applicable.</p>
<p>I&#8217;ve made the UDP implementation retry by default, but I think if you need more than 2 retries, you should be considering using TCP with its (much more advanced) retransmission algorithms.</p>
<p>Peter also found a bug in glibc&#8217;s <code>res_send</code> (actually in their <code>send_dg</code> function) whereby the resolver interprets the lack of the DNS &#8220;recursion available&#8221; flag in the header as an error.  However, that flag isn&#8217;t even meaningful for DNS UPDATE responses; according to RFC 2136, those bits:</p>
<blockquote cite="http://tools.ietf.org/html/rfc2136#page-5"><p>Should be zero (0) in all requests and responses.  A non-zero Z field should be ignored by implementations of this specification.</p></blockquote>
<p>As a result, glibc was setting errno to <code>ECONNREFUSED</code> or <code>ETIMEDOUT</code> even when the update was successful.  I&#8217;ve hacked dudders to double-check after <code>res_send</code>, but it&#8217;s making me question the wisdom of using <code>res_send</code> at all, given that I&#8217;m constantly working around it.</p>
<p><small class="postscript">Update: submitted glibc bug report <a href="http://sources.redhat.com/bugzilla/show_bug.cgi?id=11950">#11950</a></small></p>
<p>To get dudders-1.04 on OpenWRT, simply update the official package feed and select dudders from the Net &gt; DNS &gt; dudders menu in the buildroot config.  For systems other than OpenWRT, you can grab the source from <a href="http://dudders.sourceforge.net">sourceforge</a>, or even <a href="http://github.com/p00ya/dudders">github</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://scarff.id.au/blog/2010/dudders-and-reliable-dns-zone-updates/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>miniupnpd stale EXTIP</title>
		<link>http://scarff.id.au/blog/2008/miniupnpd-stale-extip/</link>
		<comments>http://scarff.id.au/blog/2008/miniupnpd-stale-extip/#comments</comments>
		<pubDate>Mon, 15 Sep 2008 07:11:43 +0000</pubDate>
		<dc:creator>Dean</dc:creator>
				<category><![CDATA[Problems]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[miniupnpd]]></category>
		<category><![CDATA[openwrt]]></category>
		<category><![CDATA[upnp]]></category>

		<guid isPermaLink="false">http://scarff.id.au/?p=121</guid>
		<description><![CDATA[<p>Miniupnpd comes with the script <code>iptables_init.sh</code>, which among other things adds an iptables rule:</p>
<pre class="codeblock sh">
#adding the rule to MINIUPNPD
$IPTABLES -t nat -A PREROUTING -d $EXTIP -i $EXTIF -j MINIUPNPD
</pre>
<p>Unfortunately, this rule isn&#8217;t replaced when the connection is dropped (and the router gets a new dynamic IP).  OpenWRT does have a hotplug script:</p>
<pre class="codeblock sh">
[ "$ACTION" = "ifup" -a "$INTERFACE" = "wan" ] &#38;&#38; \
/etc/init.d/miniupnpd enabled &#38;&#38; \
/etc/init.d/miniupnpd restart
</pre>
<p>Problem here is that <code>/etc/init.d/miniupnpd enabled</code> returns false!  It&#8217;s a function defined in <code>/etc/rc.common</code> that checks for <code>/etc/rc.d/S95miniupnpd</code>.  So the solution is:</p>
<pre class="codeblock sh">
ln -s /etc/init.d/miniupnpd ./S95miniupnpd
</pre>
<p>Realistically, the ipkg should come with this file (effectively enabling miniupnpd by default).  A more robust solution would be to modify the hotplug script so that it restarts the daemon without the enabled check, and rely on the restart function not to start the daemon if it wasn&#8217;t already running.</p>
]]></description>
			<content:encoded><![CDATA[<p><a href="http://miniupnp.tuxfamily.org/">Miniupnpd</a> comes with the script <code>iptables_init.sh</code>, which among other things adds an iptables rule:</p>
<pre class="codeblock sh">
#adding the rule to MINIUPNPD
$IPTABLES -t nat -A PREROUTING -d $EXTIP -i $EXTIF -j MINIUPNPD
</pre>
<p>Unfortunately, this rule isn&#8217;t replaced when the connection is dropped (and the router gets a new dynamic IP).  OpenWRT does have a <a href="https://svn.openwrt.org/openwrt/packages/net/miniupnpd/files/miniupnpd.hotplug">hotplug script</a>:</p>
<pre class="codeblock sh">
[ "$ACTION" = "ifup" -a "$INTERFACE" = "wan" ] &amp;&amp; \
/etc/init.d/miniupnpd enabled &amp;&amp; \
/etc/init.d/miniupnpd restart
</pre>
<p>Problem here is that <code>/etc/init.d/miniupnpd enabled</code> returns false!  It&#8217;s a function defined in <code>/etc/rc.common</code> that checks for <code>/etc/rc.d/S95miniupnpd</code>.  So the solution is:</p>
<pre class="codeblock sh">
ln -s /etc/init.d/miniupnpd ./S95miniupnpd
</pre>
<p>Realistically, the ipkg should come with this file (effectively enabling miniupnpd by default).  A more robust solution would be to modify the hotplug script so that it restarts the daemon without the enabled check, and rely on the restart function not to start the daemon if it wasn&#8217;t already running.</p>
]]></content:encoded>
			<wfw:commentRss>http://scarff.id.au/blog/2008/miniupnpd-stale-extip/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>dudders: Dynamically Updating DNS Duly Embracing RSA SIG(0)</title>
		<link>http://scarff.id.au/blog/2007/dudders-dynamically-updating-dns-duly-embracing-rsa-sig0/</link>
		<comments>http://scarff.id.au/blog/2007/dudders-dynamically-updating-dns-duly-embracing-rsa-sig0/#comments</comments>
		<pubDate>Fri, 14 Dec 2007 06:31:05 +0000</pubDate>
		<dc:creator>Dean</dc:creator>
				<category><![CDATA[Programs]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[bind]]></category>
		<category><![CDATA[dns]]></category>
		<category><![CDATA[dudders]]></category>
		<category><![CDATA[openwrt]]></category>

		<guid isPermaLink="false">http://scarff.id.au/blog/12/dudders-dynamically-updating-dns-duly-embracing-rsa-sig0/</guid>
		<description><![CDATA[<p>For those of us with dynamic IP addresses at home (assigned via IPCP/PPP/ADSL) it&#8217;s nice to have a stable host name for remote access.  My previous solution was to use dyndns, which uses an HTTP-based protocol to update a subdomain of one of dyndns&#8217;s domains.  However, I preferred to use my own domain.</p>
<p>As I try to use cool crypto wherever possible, the public-key based SIG(0) from RFC2931 seemed like a nifty protocol to use.  The usual tool for generating keys is <code>dnssec-keygen</code>, and for performing updates it&#8217;s <code>nsupdate</code>, both part of ISC&#8217;s BIND.  I set this up and tested it from scud, where it worked fine.</p>
<p>However, since spade controls my PPP connection, and thus knows when my IP address changes, the logical place to be running <code>nsupdate</code> was on spade.  Unfortunately OpenWRT&#8217;s nsupdate (packaged as <code>bind-client</code>) is relatively large at 439186 octects; add to this libopenssl and bind-libs,&#8230; <a href="http://scarff.id.au/blog/2007/dudders-dynamically-updating-dns-duly-embracing-rsa-sig0/" class="read_more">more</a></p>]]></description>
			<content:encoded><![CDATA[<p>For those of us with dynamic IP addresses at home (assigned via IPCP/PPP/ADSL) it&#8217;s nice to have a stable host name for remote access.  My previous solution was to use dyndns, which uses an <a href="https://www.dyndns.com/developers/specs/syntax.html">HTTP-based protocol</a> to update a subdomain of one of dyndns&#8217;s domains.  However, I preferred to use my own domain.</p>
<p>As I try to use cool crypto wherever possible, the public-key based SIG(0) from RFC2931 seemed like a nifty protocol to use.  The usual tool for generating keys is <code>dnssec-keygen</code>, and for performing updates it&#8217;s <code>nsupdate</code>, both part of ISC&#8217;s BIND.  I set this up and tested it from <a href="/hosts#scud">scud</a>, where it worked fine.</p>
<p>However, since <a href="/hosts#spade">spade</a> controls my PPP connection, and thus knows when my IP address changes, the logical place to be running <code>nsupdate</code> was on spade.  Unfortunately OpenWRT&#8217;s nsupdate (packaged as <code>bind-client</code>) is relatively large at 439186 octects; add to this libopenssl and bind-libs, and I&#8217;d run out of room on my JFFS2 partition.  If you have the room, it&#8217;ll work for TSIGs: Ignace Mouzannar <a href="http://ghantoos.org/2007/11/29/wrt54gl-openwrt-kamikaze-09-and-dynamic-dns-nsupdatebind/">describes</a> how to do it.  However, even when I got it installed, I couldn&#8217;t make it sign a SIG(0) request.  Chip Rosenthal has also <a href="http://www.unicom.com/chrome/a/000954.html">noticed problems</a>, and came up with an HTTP-based solution to get another host to run nsupdate, called <a href="http://www.unicom.com/chrome/a/001080.html">web-nsupdate</a>.</p>
<p>My solution?  Write my own client in C, that can read the &#8220;dnssec-keygen&#8220; key files.  Presenting dudders: my <a href="http://dudders.sourceforge.net">lightweight DNS UPDATE</a> client.  It even comes as an OpenWRT ipkg.  It still needs a crypto library, but it can use libgcrypt which (even after dependencies) still weighs in lighter than libopenssl.</p>
]]></content:encoded>
			<wfw:commentRss>http://scarff.id.au/blog/2007/dudders-dynamically-updating-dns-duly-embracing-rsa-sig0/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

