pages tagged turrisFeeding the Cloudhttps://feeding.cloud.geek.nz/tags/turris/Feeding the Cloudikiwiki2023-10-28T23:54:26ZRemote logging of Turris Omnia log messages using syslog-ng and rsysloghttps://feeding.cloud.geek.nz/posts/remote-logging-turris-omnia-router/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2023-10-28T23:54:26Z2022-07-02T03:45:00Z
<p>As part of debugging an upstream connection problem I've been seeing
recently, I wanted to be able to monitor the logs from my <a href="https://www.turris.com/en/omnia/overview/">Turris
Omnia</a> router. Here's how I
configured it to send its logs to a server I already had on the local
network.</p>
<h2 id="Server_setup">Server setup</h2>
<p>The first thing I did was to open up my server's
<a href="https://www.rsyslog.com/">rsyslog</a> (Debian's default syslog server) to
remote connections since it's going to be the destination host for the
router's log messages.</p>
<p>I added the following to <code>/etc/rsyslog.d/router.conf</code>:</p>
<pre><code>module(load="imtcp")
input(type="imtcp" port="514")
if $fromhost-ip == '192.168.1.1' then {
if $syslogseverity <= 5 then {
action(type="omfile" file="/var/log/router.log")
}
stop
}
</code></pre>
<p>This is using the latest rsyslog configuration method: a handy scripting
language called
<a href="https://www.rsyslog.com/doc/v8-stable/rainerscript/index.html">RainerScript</a>.
<a href="https://wiki.archlinux.org/title/Rsyslog#Severity_levels">Severity level</a> 5
maps to "notice" which consists of <em>unusual non-error conditions</em>, and
<code>192.168.1.1</code> is of course the IP address of the router on the LAN side.
With this, I'm directing all router log messages to a separate file,
filtering out anything less important than severity 5.</p>
<p>In order for rsyslog to pick up this new configuration file, I restarted it:</p>
<pre><code>systemctl restart rsyslog.service
</code></pre>
<p>and checked that it was running correctly (e.g. no syntax errors in the new
config file) using:</p>
<pre><code>systemctl status rsyslog.service
</code></pre>
<p>Since I added a new log file, I also setup log rotation for it by putting
the following in <code>/etc/logrotate.d/router</code>:</p>
<pre><code>/var/log/router.log
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
</code></pre>
<p>In addition, since I use
<a href="https://packages.debian.org/stable/logcheck">logcheck</a> to monitor my server
logs and email me errors, I had to add <code>/var/log/router.log</code> to
<code>/etc/logcheck/logcheck.logfiles</code>.</p>
<p>Finally I opened the rsyslog port to the router in my server's firewall by
adding the following to <code>/etc/network/iptables.up.rules</code>:</p>
<pre><code># Allow logs from the router
-A INPUT -s 192.168.1.1 -p tcp --dport 514 -j ACCEPT
</code></pre>
<p>and ran <code>iptables-apply</code>.</p>
<p>With all of this in place, it was time to get the router to send messages.</p>
<h2 id="Router_setup">Router setup</h2>
<p>As <a href="https://forum.turris.cz/t/remote-log-how-to-configure/992/3">suggested on the Turris
forum</a>, I
ssh'ed into my router and added this in <code>/etc/syslog-ng.d/remote.conf</code>:</p>
<pre><code>destination d_loghost {
network("192.168.1.200" time-zone("America/Vancouver"));
};
source dns {
file("/var/log/resolver");
};
log {
source(src);
source(net);
source(kernel);
source(dns);
destination(d_loghost);
};
</code></pre>
<p>Setting the <a href="https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.33/administration-guide/time-zone">timezone</a> to the same as my server was needed because the router
messages were otherwise sent with UTC timestamps.</p>
<p>To ensure that the destination host always gets the same IP address
(<code>192.168.1.200</code>), I went to the <a href="https://192.168.1.1/cgi-bin/luci/admin/network/dhcp">advanced DHCP configuration
page</a> and added a
<em>static lease</em> for the server's MAC address so that it always gets assigned
<code>192.168.1.200</code>. If that wasn't already the server's IP address, you'll have
to restart it for this to take effect.</p>
<p>Finally, I restarted the syslog-ng daemon on the router to pick up the new
config file:</p>
<pre><code>/etc/init.d/syslog-ng restart
</code></pre>
<h2 id="Testing">Testing</h2>
<p>In order to test this configuration, I opened three terminal windows:</p>
<ol>
<li><code>tail -f /var/log/syslog</code> on the server</li>
<li><code>tail -f /var/log/router.log</code> on the server</li>
<li><code>tail -f /var/log/messages</code> on the router</li>
</ol>
<p>I immediately started to see messages from the router in the third window
and some of these, not all because of my severity-5 filter, were flowing to
the second window as well. Also important is that none of the messages make
it to the first window, otherwise log messages from the router would be mixed
in with the server's own logs. That's the purpose of the <code>stop</code> command in
<code>/etc/rsyslog.d/router.conf</code>.</p>
<p>To force a log messages to be emitted by the router, simply ssh into it and
issue the following command:</p>
<pre><code>logger Test
</code></pre>
<p>It should show up in the second and third windows immediately if you've got
everything setup correctly</p>
<h2 id="Timezone_problems">Timezone problems</h2>
<p>If I do the following on my router:</p>
<p> /etc/init.d/syslog-ng restart
logger TestA</p>
<p>I see the following in <code>/var/log/messages</code>:</p>
<p> Aug 14 20:39:35 hostname syslog-ng[9860]: syslog-ng shutting down; version='3.37.1'
Aug 14 20:39:36 hostname syslog-ng[10024]: syslog-ng starting up; version='3.37.1'
Aug 15 03:39:49 hostname root: TestA</p>
<p>The correct timezone is the one in the first two lines. Other daemon
messages are displayed using an incorrect timezone like <code>logger</code>.</p>
<p>Thanks to a <a href="https://lists.balabit.hu/pipermail/syslog-ng/2022-August/thread.html#26509">very helpful <code>syslog-ng</code> mailing list thread</a>, I found that this is actually an <a href="https://gitlab.nic.cz/turris/os/packages/-/issues/471">upstream OpenWRT bug</a>.</p>
<p>My favourite work-around is to tell syslog-ng to simply ignore the timestamp
provided by the application and to use the time of reception (of the log
message) instead. To do this, simply change the following in
<code>/etc/syslog-ng.conf</code>:</p>
<pre><code>source src {
internal();
unix-dgram("/dev/log");
};
</code></pre>
<p>to:</p>
<pre><code>source src {
internal();
unix-dgram("/dev/log", keep-timestamp(no));
};
</code></pre>
<p>Unfortunately, I wasn't able to fix it in a way that would survive a
<code>syslog-ng</code> package update, but since this is supposedly fixed in Turris 6.0,
it shouldn't be a problem for much longer.</p>
Upgrading the Wi-Fi cards in a Turris Omnia 2020https://feeding.cloud.geek.nz/posts/upgrading-wifi-cards-turris-omnia/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2022-04-10T07:41:52Z2022-04-10T08:30:00Z
<p>I've been <a href="https://twitter.com/fmarier/status/1204117367149645825">very
happy</a> with my
<a href="https://www.turris.com/en/omnia/overview/">Turris Omnia router</a> and decided
recently to take advantage of the fact that is is easily upgradable to
replace the original radios for <a href="https://en.wikipedia.org/wiki/IEEE_802.11ac-2013#Wave_1_vs._Wave_2">Wave
2</a>
models.</p>
<p>I didn't go for a <a href="https://en.wikipedia.org/wiki/Wi-Fi_6">Wi-Fi 6</a>-capable
card because I don't have any devices that support it at this point. There
is also an <a href="https://youtu.be/qiuLtIqjK-U?t=390">official WiFi 6 upgrade kit</a>
in the works and so I might just go with that later.</p>
<h2 id="Wi-Fi_card_selection">Wi-Fi card selection</h2>
<p>After seeing a report that <a href="https://forum.turris.cz/t/what-mini-pci-express-version-is-omnia-turris-using/11691/2?u=fmarier">someone was already using these cards on the
Omnia</a>,
I decided to look for the following:</p>
<ul>
<li><a href="https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v2-20-2/">Compex WLE1216V2-20</a></li>
<li><a href="https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/">Compex WLE1216V5-20</a></li>
</ul>
<p>Compex themselves don't appear to sell to consumers, but I found an American
store that would sell them to me and ship to Canada:</p>
<ul>
<li><a href="https://www.embeddedworks.net/wlan721/">https://www.embeddedworks.net/wlan721/</a></li>
<li><a href="https://www.embeddedworks.net/wlan720/">https://www.embeddedworks.net/wlan720/</a></li>
</ul>
<p>Each card uses 4 antennas, which means that I would need an additional
diplexer, an extra pigtail to SMA-RP connector, and two more antennas to
wire everything up. Thankfully, the Omnia already comes with two extra holes
drilled into the back of the router (covered by plastic caps) and so there
is no need for drilling the case.</p>
<p>I put the two cards in the middle and right-most slots (they don't seem to
go in the left-most slot because of the SIM card holder being in the way)
without worrying about antennas just yet.</p>
<h2 id="Driver_installation">Driver installation</h2>
<p>I made sure that the chipsets were supported in <a href="https://openwrt.org/releases/19.07/start">OpenWRT
19.07</a> (LTS 4.14 kernel) and found
that support for the <a href="https://www.qualcomm.com/products/technology/wi-fi/qca9984">Qualcomm
QCA9984</a> chipset
was <a href="https://github.com/torvalds/linux/commit/651b4cdcf97e75f6346784b75ca7bf3c85187143">added in the <code>ath10k</code> driver as of kernel
4.8</a>
but <a href="https://wireless.wiki.kernel.org/en/users/drivers/ath10k#supported_devices">only for two cards
apparently</a>.</p>
<p>I installed the following proprietary firmware package via the <a href="https://192.168.1.1/cgi-bin/luci/admin/system/opkg">advanced
configuration
interface</a>:</p>
<pre><code>ath10k-firmware-qca9984
</code></pre>
<p>and that automatically pulled in the free <code>ath10k</code> driver. After rebooting,
I was able to see one of the two cards in the ReForis admin page and
configure it.</p>
<p>Note that there is an <a href="https://www.candelatech.com/ath10k-10.4.php">alternative
firmware</a> available in OpenWRT
as well (look for packages ending in <code>-ct</code>), but since both firmware/driver
combinations gave me the same initial results, I decided to go with the
defaults.</p>
<h2 id="Problems">Problems</h2>
<p>The first problem I ran into is that I could only see one of the two cards
in the output of <code>lspci</code> (after <code>ssh</code>ing into the router). Looking for <code>ath</code>
or <code>wlan</code> in the <code>dmesg</code> output, it doesn't look like the second card is
being recognized at all.</p>
<p>Neither the 2.4 GHz or 5 GHz Wave 2 card worked in the right-most slot, but
either of them works fine when moved to the middle slot. The stock cards
work just fine in the right-most slot. I have no explanation for this.</p>
<p>The second problem was that I realized that the antenna holes are not all
the same. The two on each end are fully round and can accommodate the
diplexers which come with a round SMA-RP connector.</p>
<p>On the other hand, the three middle ones have a notch at the top which can
only accommodate the single antenna connectors which have a flat bit on one
side. I would have to file one of holes in order to add a third diplexer to
my setup.</p>
<h2 id="Final_working_configuration">Final working configuration</h2>
<p>Since I didn't see a way to use both new cards at once, I ended up on a
different configuration that would nevertheless still upgrade both my 2.4
GHz and 5 GHz Wi-Fi.</p>
<p>I moved the <a href="https://compex.com.sg/shop/wifi-module/802-11ac-wave-1/wle900vx-2/">original dual-band
card</a> to
the right-most slot and switched it to the 2.4 GHz band since it's more powerful
(both in dB and in throughput) than the <a href="https://compex.com.sg/shop/wifi-module/802-11n/wle200n2-2/">original half-length
card</a>.</p>
<p>Then I put the WLE1216V5-20 into the middle slot.</p>
<p>The only extra thing I had to buy were two extra <a href="https://www.amazon.ca/gp/product/B00TI1XBOE/">pigtails to SMA-RP
connectors and antennas</a>.</p>
<p>Here's what the final product looks like:</p>
<p><img alt="" src="https://feeding.cloud.geek.nz/posts/upgrading-wifi-cards-turris-omnia/omnia-inside.jpg" /></p>
<p><img alt="" src="https://feeding.cloud.geek.nz/posts/upgrading-wifi-cards-turris-omnia/omnia-outside.jpg" /></p>
Fixing Turris Omnia WiFi Qualityhttps://feeding.cloud.geek.nz/posts/fixing-turris-omnia-wifi-quality/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2021-06-11T20:43:57Z2019-11-25T06:30:00Z
<p>I was recently hoping to replace an aging proprietary router (upgraded to a
<a href="https://www.gargoyle-router.com/">Gargoyle</a> FOSS firmware). After rejecting
a <a href="https://sfconservancy.org/blog/2019/oct/02/cambium-ubiquiti-gpl-violations/">popular brand with a disturbing GPL violation
habit</a>,
I settled on the <a href="https://www.turris.cz/en/omnia/">Turris Omnia router</a>,
built on free software. Overall, I was pretty satisfied with the fact that
it is free and comes with automatic updates, but I noticed a problem with
the WiFi. Specifically, the 5 GHz access point was okay but the 2.4 GHz was
awful.</p>
<h2 id="False_lead">False lead</h2>
<p>I initially thought that the 2.4 GHz radio wasn't working, but then I
realized that putting my phone next to the router would allow it to connect
and exchange data at a slow-but-steady rate. If I moved the phone more than
3-4 meters away though, it would disconnect for lack of signal. To be frank,
the wireless performance was much worse than my original router, even though
the wired performance was, as expected, amazing:</p>
<p><img alt="" src="https://feeding.cloud.geek.nz/posts/fixing-turris-omnia-wifi-quality/fast.png" /></p>
<p>I looked on the <a href="https://forum.turris.cz/">official support forums</a> and found this intriguing
thread about <a href="https://forum.turris.cz/t/slow-wifi-and-bad-signal-finally-solved/7372">interference between USB3 and 2.4 GHz
radios</a>.
This sounded a lot like what I was experiencing (working radio but terrible
signal/interference) and so I decided to see if I could move the radios
around inside the unit, as suggested by the poster.</p>
<p>After opening the case however, I noticed that radios were already laid out
in the optimal way:</p>
<p><img alt="" src="https://feeding.cloud.geek.nz/posts/fixing-turris-omnia-wifi-quality/radios.jpg" /></p>
<p>and that USB3 interference wasn't going to be the reason
for my troubles.</p>
<h2 id="Real_problem">Real problem</h2>
<p>So I took a good look at the wiring and found that while the the <a href="https://compex.com.sg/shop/wifi-module/802-11ac-wave-1/wle900vx/">larger
radio</a>
(2.4 / 5 GHz dual-bander) was connected to all three antennas, the <a href="https://compex.com.sg/shop/wifi-module/802-11n/wle200n2/">smaller
radio</a> (2.4 GHz
only) was connected to only 2 of the 3 antennas:</p>
<p><img alt="" src="https://feeding.cloud.geek.nz/posts/fixing-turris-omnia-wifi-quality/overall.jpg" /></p>
<p>To make it possible for antennas 1 and 3 to carry the signal from both
radios, a duplexer got inserted between the radios and the antenna:</p>
<p><img alt="" src="https://feeding.cloud.geek.nz/posts/fixing-turris-omnia-wifi-quality/duplexer.jpg" /></p>
<p>On one side is the 2.4 antenna port and on the other side is the 5 GHz port.</p>
<p>Looking at the wiring though, it became clear that <strong>my 2.4 GHz radio was
connected to the 5 GHz ports of the two duplexers and the 5 GHz radio was
connected to the 2.4 GHz ports of the duplexers</strong>. This makes sense
considering that I had okay 5 GHz performance (with one of the three chains
connected to the right filter) and abysimal 2.4 GHz performance (with none
of the two chains connected to the right filter).</p>
<h2 id="Solution">Solution</h2>
<p><strong>Swapping the antenna connectors around completely fixed the problem.</strong>
With the 2.4 GHz radio connected to the 2.4 side of the duplexer and the
dual-bander connected to the 5 GHz side, I was able to get the performance I
would expect from such a high-quality router.</p>
<p>Interestingly enough, I found the solution to this problem the same weekend
as I passed my advanced <a href="https://launchpad.net/canadian-ham-exam">amateur radio license
exam</a>. I guess that was a good way
to put the course material into practice!</p>