Computer

The problem

When I was looking at the dmesg of a Conceptronic CH3SNAS (this is similar to a DS-323), I saw the following lines filled the dmesg.

TWSI: mvTwsiStartBitSet ERROR - Start Clear bit TimeOut .
TWSI: mvTwsiStopBitSet ERROR - Stop bit TimeOut .

I’m using fun_plug on the system to be able to do more with it, but this is also the reason the lines appear in dmesg.

A little search provide me with a forum post which explains how to get rid of these messages.

The problem

When the Fedora 20 server at my parents rebooted because of a general power failure, the tinc tunnel between my parents and myself didn’t work anymore.

Troubleshooting

I enabled the debug logging by sending an INT signal to the daemon.

tincd -n ubbink -k INT

This resulted in the following log items (journalctl -f -l –unit tincd@ubbink.service):

tinc.ubbink[9707]: Got INT signal
tinc.ubbink[9707]: Temporarily setting debug level to 5.  Kill me with SIGINT again to go back to level 0.
tinc.ubbink[9707]: Trying to connect to amys (xxx.xxx.xxx.xxx port 655)
tinc.ubbink[9707]: xxx.xxx.xxx.xxx port 655: Network is unreachable
tinc.ubbink[9707]: Could not set up a meta connection to amys
tinc.ubbink[9707]: Trying to re-establish outgoing connection in 35 seconds
tinc.ubbink[9707]: Purging unreachable nodes

I couldn’t find why this was happening because when I used netcat to connect to port 655 via udp everything worked.

nc -vu xxx.xxx.xxx.xxx 655

Why use :> instead of > ?

During a IRC conversation somebody mentioned that using :> was a better way than using >. So to make a file named testfile empty you would use

:> testfile

The explaination is that :> is more portable. Some shells (such as zsh) auto-instantiate a cat in the current shell and listen for stdin when given a redirect with no command. Rather than cat /dev/null, : is much simpler. Often this behavior is different in interactive shells rather than scripts, but if you write the script in a way that also works interactive, debuging by copy-paste is much easier.

This blogpost was original posted on Capitar’s blog

The problem

When customers ask us to allow some IP addresses to their services they might give us an IP-range in the following way.

10.0.0.1-6

This means they want the following IP addresses to have access: 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4, 10.0.0.5 and 10.0.0.6. But when you use this notation with iptables it gives an warning.

# iptables -A INPUT -m iprange --src-range 10.0.0.1-6 -j ACCEPT
xt_iprange: range 10.0.0.1-6 is reversed and will never match

This message is not displayed when 10.0.0.1-16 is used, although this will not result in the expected result.