The DrayTek Vigor 3900 isn’t bad, just very confusing

3900-other-01The DrayTek Vigor 3900 has been around for some time now. Sadly, this isn’t exactly mirrored on the world wide web. The amount of documentation, samples, and FAQs is sparse; guides, and discussions are few. For a product in this class. And that’s not very good at all.

DrayTek has always gone their own way, and it’s usually a good way. The biggest problem, IMHO, is that you need to wrap your head around how the DrayTek engineers think. To add insult to injury, several of the “DrayTek websites” require you to have an account on their sites to download technical guides. I have no idea how this came to be, but it’s not good. And, it’s not like the good people at Clavister or ZyXEL is going to steal “ideas” from a DrayTek guide. #lol

I’ve toyed with quite a few firewalls. They all have their pros and cons. Well, almost all of them. Some only have cons, really. But I cannot for the life of me understand why DrayTek has such crap documentation, crap support information archives, and have to go their own way on every single administration user interface design. Because they really do make great products. Maybe they are a little bit too aware of that fact.

#draytek #network #security #firewall #vigor

IP-Only, NOC, customer service, support, and network loops

IP-Only often boasts about being “the man” when it comes to Swedish Internet infrastructure and their competence in networks. Customer service and fast response to serious network issues such as routing loops seems to be of … less importance to IP-Only. It’s fascinating how “big players” so often seem to ignore “small customers”. We reported this network issue to IP-Only on 13-Jun-2016 (Monday). On 17-Jun-2016 (Friday), they still don’t know what the problem is. But they are “investigating it”. In the meantime, there is zero response from them until you start screaming.

It’s so comforting to know we’re in safe hands with them, being “the man” when it comes to the Internet infrastructure in Sweden.

What’s less comforting is that they don’t seem to monitor their network equipment nor know how it works.

  3  62.109.44.150 (62.109.44.150)  1 ms  1 ms  1 ms
  4  62.109.44.154 (62.109.44.154)  1 ms  1 ms  2 ms
  5  sesto1024-rc1.ip-only.net (62.109.44.153)  1 ms  2 ms  4 ms
  6  62.109.44.154 (62.109.44.154)  1 ms  1 ms  1 ms
  7  sesto1024-rc1.ip-only.net (62.109.44.153)  1 ms  3 ms  1 ms
  8  62.109.44.154 (62.109.44.154)  1 ms  1 ms  1 ms
  9  sesto1024-rc1.ip-only.net (62.109.44.153)  1 ms  2 ms  1 ms
 10  62.109.44.154 (62.109.44.154)  2 ms  1 ms  1 ms
 11  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  1 ms  3 ms
 12  62.109.44.154 (62.109.44.154)  3 ms  3 ms  2 ms
 13  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  4 ms
 14  62.109.44.154 (62.109.44.154)  4 ms  1 ms  1 ms
 15  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  1 ms  2 ms
 16  62.109.44.154 (62.109.44.154)  24 ms  5 ms  2 ms
 17  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 18  62.109.44.154 (62.109.44.154)  2 ms  2 ms  2 ms
 19  sesto1024-rc1.ip-only.net (62.109.44.153)  3 ms  3 ms  3 ms
 20  62.109.44.154 (62.109.44.154)  2 ms  2 ms  2 ms
 21  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 22  62.109.44.154 (62.109.44.154)  3 ms  2 ms  2 ms
 23  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 24  62.109.44.154 (62.109.44.154)  2 ms  2 ms  2 ms
 25  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  3 ms
 26  62.109.44.154 (62.109.44.154)  3 ms  3 ms  4 ms
 27  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  3 ms  2 ms
 28  62.109.44.154 (62.109.44.154)  2 ms  6 ms  2 ms
 29  sesto1024-rc1.ip-only.net (62.109.44.153)  2 ms  2 ms  2 ms
 30  62.109.44.154 (62.109.44.154)  2 ms  4 ms  4 ms

SSH keys are no longer working after upgrading to Ubuntu 16.04.LTS – Help!

I recently upgraded one of my laptops to Ubuntu 16.04.LTS (going from 14.04.LTS). The upgrade went very smooth and I have no issues with the resulting operating environment 🙂 Having said that, I quickly discovered a quite serious issue for me when I attempted connecting to one of many servers I need to get into. All of a sudden, my SSH key was no longer accepted by the server, and I was prompted for a password! WTF!?

I immediately feared the worst and started looking at the server(s), tailing log files, enabling debugging, etc. No trace was to be found other than that no key was presented by the client. The servers were intact, the authorized_keys had not been compromised, and vanilla ice cream was still the number one flavor. The problem is not with Ubuntu 16.04.LTS. The problem is with my SSH key, as well as a recent change in “acceptable keys” by OpenSSH, version 7.

Doing “ssh -vvv user@server.com” told me that the SSH client couldn’t find an acceptable key to present to the server. After having figured that out, and facepalming for a few seconds, I added this to my /etc/ssh/ssh_config file:

PubkeyAcceptedKeyTypes=+ssh-dss

Saved the file and tried again. Voila! One could say many things about using this type of SSH key, but rest assured I will change mine. You should too if you run into this problem. This is a workaround, not a fix or a solution. So sit down with some vanilla ice cream (with actual vanilla) and something nice to drink and go through the process of replacing your public SSH keys everywhere.

wget segfault | wget segmentation fault

We mirror the Webmin website to bring it somewhat closer to Sweden, and recently I had to move the hosted mirror to another of our servers running Debian 8. All of a sudden, a cron job that had been working for many years went tits up with a segmentation fault.

Odd, to say the least. It became even more strange when I turned on “verbose” (-v) output and wget told me that “UTF8 cannot be converted to UTF8”. This is a truly silly error message, imho. wget apparently knows the local encoding, and it apparently knows the remote encoding, so why is it attempting a conversion when there’s non conversion needed?#stupid

Hello?

Adding –no-iri to the wget command-line solves this issue.

rsyslogd eats CPU on OpenVZ

All of a sudden, rsyslogd on an Ubuntu installation running under OpenVZ is using 100% CPU. One alternative is to replace rsyslogd for syslog-ng, but if you want to “fix” rsyslogd instead, here’s how:

service rsyslog stop
sed -i -e 's/^$ModLoad imklog/#$ModLoad imklog/g' /etc/rsyslog.conf
service rsyslog start

Credits: www.ramnode.com