+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Running_TP_Link_MR3040_as_a_batman_adv_mesh_node_using_openwrt.html">Running TP-Link MR3040 as a batman-adv mesh node using openwrt</a></div>
+ <div class="date">10th November 2013</div>
+ <div class="body"><p>Continuing my research into mesh networking, I was recommended to
+use TP-Link 3040 and 3600 access points as mesh nodes, and the pair I
+bought arrived on Friday. Here are my notes on how to set up the
+MR3040 as a mesh node using
+<a href="http://www.openwrt.org/">OpenWrt</a>.</p>
+
+<p>I started by following the instructions on the OpenWRT wiki for
+<a href="http://wiki.openwrt.org/toh/tp-link/tl-mr3040">TL-MR3040</a>,
+and downloaded
+<a href="http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-mr3040-v2-squashfs-factory.bin">the
+recommended firmware image</a>
+(openwrt-ar71xx-generic-tl-mr3040-v2-squashfs-factory.bin) and
+uploaded it into the original web interface. The flashing went fine,
+and the machine was available via telnet on the ethernet port. After
+logging in and setting the root password, ssh was available and I
+could start to set it up as a batman-adv mesh node.</p>
+
+<p>I started off by reading the instructions from
+<a href="http://wirelessafrica.meraka.org.za/wiki/index.php?title=Antoine's_Research">Wireless
+Africa</a>, which had quite a lot of useful information, but
+eventually I followed the recipe from the Open Mesh wiki for
+<a href="http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config">using
+batman-adv on OpenWrt</a>. A small snag was the fact that the
+<tt>opkg install kmod-batman-adv</tt> command did not work as it
+should. The batman-adv kernel module would fail to load because its
+dependency crc16 was not already loaded. I
+<a href="https://dev.openwrt.org/ticket/14452">reported the bug</a> to
+the openwrt project and hope it will be fixed soon. But the problem
+only seem to affect initial testing of batman-adv, as configuration
+seem to work when booting from scratch.</p>
+
+<p>The setup is done using files in /etc/config/. I did not bridge
+the Ethernet and mesh interfaces this time, to be able to hook up the
+box on my local network and log into it for configuration updates.
+The following files were changed and look like this after modifying
+them:</p>
+
+<p><tt>/etc/config/network</tt></p>
+
+<pre>
+
+config interface 'loopback'
+ option ifname 'lo'
+ option proto 'static'
+ option ipaddr '127.0.0.1'
+ option netmask '255.0.0.0'
+
+config globals 'globals'
+ option ula_prefix 'fdbf:4c12:3fed::/48'
+
+config interface 'lan'
+ option ifname 'eth0'
+ option type 'bridge'
+ option proto 'dhcp'
+ option ipaddr '192.168.1.1'
+ option netmask '255.255.255.0'
+ option hostname 'tl-mr3040'
+ option ip6assign '60'
+
+config interface 'mesh'
+ option ifname 'adhoc0'
+ option mtu '1528'
+ option proto 'batadv'
+ option mesh 'bat0'
+</pre>
+
+<p><tt>/etc/config/wireless</tt></p>
+<pre>
+
+config wifi-device 'radio0'
+ option type 'mac80211'
+ option channel '11'
+ option hwmode '11ng'
+ option path 'platform/ar933x_wmac'
+ option htmode 'HT20'
+ list ht_capab 'SHORT-GI-20'
+ list ht_capab 'SHORT-GI-40'
+ list ht_capab 'RX-STBC1'
+ list ht_capab 'DSSS_CCK-40'
+ option disabled '0'
+
+config wifi-iface 'wmesh'
+ option device 'radio0'
+ option ifname 'adhoc0'
+ option network 'mesh'
+ option encryption 'none'
+ option mode 'adhoc'
+ option bssid '02:BA:00:00:00:01'
+ option ssid 'meshfx@hackeriet'
+</pre>
+<p><tt>/etc/config/batman-adv</tt></p>
+<pre>
+
+config 'mesh' 'bat0'
+ option interfaces 'adhoc0'
+ option 'aggregated_ogms'
+ option 'ap_isolation'
+ option 'bonding'
+ option 'fragmentation'
+ option 'gw_bandwidth'
+ option 'gw_mode'
+ option 'gw_sel_class'
+ option 'log_level'
+ option 'orig_interval'
+ option 'vis_mode'
+ option 'bridge_loop_avoidance'
+ option 'distributed_arp_table'
+ option 'network_coding'
+ option 'hop_penalty'
+
+# yet another batX instance
+# config 'mesh' 'bat5'
+# option 'interfaces' 'second_mesh'
+</pre>
+
+<p>The mesh node is now operational. I have yet to test its range,
+but I hope it is good. I have not yet tested the TP-Link 3600 box
+still wrapped up in plastic.</p>
+</div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>, <a href="http://people.skolelinux.org/pere/blog/tags/mesh network">mesh network</a>, <a href="http://people.skolelinux.org/pere/blog/tags/nuug">nuug</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html">Debian init.d boot script example for rsyslog</a></div>
+ <div class="date"> 2nd November 2013</div>
+ <div class="body"><p>If one of the points of switching to a new init system in Debian is
+<a href="http://thomas.goirand.fr/blog/?p=147">to get rid of huge
+init.d scripts</a>, I doubt we need to switch away from sysvinit and
+init.d scripts at all. Here is an example init.d script, ie a rewrite
+of /etc/init.d/rsyslog:</p>
+
+<p><pre>
+#!/lib/init/init-d-script
+### BEGIN INIT INFO
+# Provides: rsyslog
+# Required-Start: $remote_fs $time
+# Required-Stop: umountnfs $time
+# X-Stop-After: sendsigs
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: enhanced syslogd
+# Description: Rsyslog is an enhanced multi-threaded syslogd.
+# It is quite compatible to stock sysklogd and can be
+# used as a drop-in replacement.
+### END INIT INFO
+DESC="enhanced syslogd"
+DAEMON=/usr/sbin/rsyslogd
+</pre></p>
+
+<p>Pretty minimalistic to me... For the record, the original sysv-rc
+script was 137 lines, and the above is just 15 lines, most of it meta
+info/comments.</p>
+
+<p>How to do this, you ask? Well, one create a new script
+/lib/init/init-d-script looking something like this:
+
+<p><pre>
+#!/bin/sh
+
+# Define LSB log_* functions.
+# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
+# and status_of_proc is working.
+. /lib/lsb/init-functions
+
+#
+# Function that starts the daemon/service
+
+#
+do_start()
+{
+ # Return
+ # 0 if daemon has been started
+ # 1 if daemon was already running
+ # 2 if daemon could not be started
+ start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
+ || return 1
+ start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
+ $DAEMON_ARGS \
+ || return 2
+ # Add code here, if necessary, that waits for the process to be ready
+ # to handle requests from services started subsequently which depend
+ # on this one. As a last resort, sleep for some time.
+}
+
+#
+# Function that stops the daemon/service
+#
+do_stop()
+{
+ # Return
+ # 0 if daemon has been stopped
+ # 1 if daemon was already stopped
+ # 2 if daemon could not be stopped
+ # other if a failure occurred
+ start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
+ RETVAL="$?"
+ [ "$RETVAL" = 2 ] && return 2
+ # Wait for children to finish too if this is a daemon that forks
+ # and if the daemon is only ever run from this initscript.
+ # If the above conditions are not satisfied then add some other code
+ # that waits for the process to drop all resources that could be
+ # needed by services started subsequently. A last resort is to
+ # sleep for some time.
+ start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
+ [ "$?" = 2 ] && return 2
+ # Many daemons don't delete their pidfiles when they exit.
+ rm -f $PIDFILE
+ return "$RETVAL"
+}
+
+#
+# Function that sends a SIGHUP to the daemon/service
+#
+do_reload() {
+ #
+ # If the daemon can reload its configuration without
+ # restarting (for example, when it is sent a SIGHUP),
+ # then implement that here.
+ #
+ start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
+ return 0
+}
+
+SCRIPTNAME=$1
+scriptbasename="$(basename $1)"
+echo "SN: $scriptbasename"
+if [ "$scriptbasename" != "init-d-library" ] ; then
+ script="$1"
+ shift
+ . $script
+else
+ exit 0
+fi
+
+NAME=$(basename $DAEMON)
+PIDFILE=/var/run/$NAME.pid
+
+# Exit if the package is not installed
+#[ -x "$DAEMON" ] || exit 0
+
+# Read configuration variable file if it is present
+[ -r /etc/default/$NAME ] && . /etc/default/$NAME
+
+# Load the VERBOSE setting and other rcS variables
+. /lib/init/vars.sh
+
+case "$1" in
+ start)
+ [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
+ do_start
+ case "$?" in
+ 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
+ 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
+ esac
+ ;;
+ stop)
+ [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
+ do_stop
+ case "$?" in
+ 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
+ 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
+ esac
+ ;;
+ status)
+ status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
+ ;;
+ #reload|force-reload)
+ #
+ # If do_reload() is not implemented then leave this commented out
+ # and leave 'force-reload' as an alias for 'restart'.
+ #
+ #log_daemon_msg "Reloading $DESC" "$NAME"
+ #do_reload
+ #log_end_msg $?
+ #;;
+ restart|force-reload)
+ #
+ # If the "reload" option is implemented then remove the
+ # 'force-reload' alias
+ #
+ log_daemon_msg "Restarting $DESC" "$NAME"
+ do_stop
+ case "$?" in
+ 0|1)
+ do_start
+ case "$?" in
+ 0) log_end_msg 0 ;;
+ 1) log_end_msg 1 ;; # Old process is still running
+ *) log_end_msg 1 ;; # Failed to start
+ esac
+ ;;
+ *)
+ # Failed to stop
+ log_end_msg 1
+ ;;
+ esac
+ ;;
+ *)
+ echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
+ exit 3
+ ;;
+esac
+
+:
+</pre></p>
+
+<p>It is based on /etc/init.d/skeleton, and could be improved quite a
+lot. I did not really polish the approach, so it might not always
+work out of the box, but you get the idea. I did not try very hard to
+optimize it nor make it more robust either.</p>
+
+<p>A better argument for switching init system in Debian than reducing
+the size of init scripts (which is a good thing to do anyway), is to
+get boot system that is able to handle the kernel events sensibly and
+robustly, and do not depend on the boot to run sequentially. The boot
+and the kernel have not behaved sequentially in years.</p>
+</div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/bootsystem">bootsystem</a>, <a href="http://people.skolelinux.org/pere/blog/tags/debian">debian</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Browser_plugin_for_SPICE__spice_xpi__uploaded_to_Debian.html">Browser plugin for SPICE (spice-xpi) uploaded to Debian</a></div>
+ <div class="date"> 1st November 2013</div>
+ <div class="body"><p><a href="http://www.spice-space.org/">The SPICE protocol</a> for
+remote display access is the preferred solution with oVirt and RedHat
+Enterprise Virtualization, and I was sad to discover the other day
+that the browser plugin needed to use these systems seamlessly was
+missing in Debian. The <a href="http://bugs.debian.org/668284">request
+for a package</a> was from 2012-04-10 with no progress since
+2013-04-01, so I decided to wrap up a package based on the great work
+from Cajus Pollmeier and put it in a collab-maint maintained git
+repository to get a package I could use. I would very much like
+others to help me maintain the package (or just take over, I do not
+mind), but as no-one had volunteered so far, I just uploaded it to
+NEW. I hope it will be available in Debian in a few days.</p>
+
+<p>The source is now available from
+<a href="http://anonscm.debian.org/gitweb/?p=collab-maint/spice-xpi.git;a=summary">http://anonscm.debian.org/gitweb/?p=collab-maint/spice-xpi.git;a=summary</a>.</p>
+</div>
+ <div class="tags">
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/debian">debian</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>.
+
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
projects / homepage.git / blobdiff