News items for tag linux - Koos van den Hout

2018-10-12 Serious slowness with rrdgraph from rrdtool 1 week ago
One of the things still needing migrating is the NTP server stats which obviously uses rrdtool. Because I want to keep the history I migrated the datasets with:
/usr/local/rrdtool/bin/rrdtool dump ntpvals-stardate.cs.uu.nl.rrd \
| ssh newhost /usr/bin/rrdtool restore -f - ntpvals-stardate.cs.uu.nl.rrd
And then create a graph of the plloffset for example using:
/usr/bin/rrdtool graph /tmp/plloffset-stardate.cs.uu.nl-24hours.png \
--title "stardate.cs.uu.nl pll offset (last 24 hours)" --imginfo \
'<img src="tmpgraphs/%s" WIDTH="%lu" HEIGHT="%lu" alt="Graph">' \
--start -24hours --end now --vertical-label="Seconds" --color BACK#0000FF \
--color CANVAS#c0e5ff --color FONT#ffffff --color GRID#ffffff \
--color MGRID#ffffff --alt-autoscale --imgformat PNG --lazy \
DEF:offset=ntpvals-stardate.cs.uu.nl.rrd:plloffset:AVERAGE \
CDEF:wipeout=offset,UN,INF,UNKN,IF CDEF:wipeoutn=wipeout,-1,* \
LINE1:offset#000000:"Offset\:" \
GPRINT:offset:LAST:"Current\:%.3lf%s" \
GPRINT:offset:MIN:"Min\:%.3lf%S" \
GPRINT:offset:MAX:"Max\:%.3lf%S" \
GPRINT:offset:AVERAGE:"Average\:%.3lf%S" \
AREA:wipeout#e0e0e0 AREA:wipeoutn#e0e0e0
But on the old server this takes 0.026 seconds, on the new server 3 minutes and 47.46 seconds. No idea what is happening, strace shows nothing strange and rrdtool uses 1 cpu at 100% all that time.
Read the rest of Serious slowness with rrdgraph from rrdtool

Tags: , , ,
2018-10-03 Seeing the same names in logcheck mails every hour 2 weeks ago
I use the logcheck package to monitor for unexpected log entries. Since upgrading to the new homeserver conway I noticed DNSSEC failures coming back regularly, even at weird times of the night while the domain names seemed related to services we sometimes interact with during the day. To search deeper I enabled query logging on DNS (with a short retention period) in order to find the source.

Eventually I found it: the DNSSEC failures came at the time the mail from logcheck was delivered, because it mentioned domain names that cause a DNSSEC failure. So the way to 'fix' this problem and avoid similar other problems was to whitelist logcheck mail.

Update 2018-10-05: That only helps when enabling the Mail::SpamAssassin::Plugin::Shortcircuit plugin and enabling the USER_IN_WHITELIST shortcircuit.

Update 2018-10-07: Even with whitelist and shortcircuit I still see queries for domain names in the logcheck mails. Call to spamassassin is now changed...

Now, once again...this time with FEEwing

Tags: , ,
2018-09-26 Made the big bang to the new homeserver 3 weeks ago
So for months and months I had hardware ready for the new homeserver, I was testing bits and pieces in the new environment and I still did not get around to making the big bang. Part of the time the new system was running and using electricity.

And a few weeks ago I had time for the big bang and forgot to mention it!

So one free day I just did the last sync of homedirectories and started migrating all services in a big bang. No more but, if, when, is it done yet. It's a homeserver, not a complete operational datacenter. Although with everything running it sometimes does look that way!

The new setup, more completely documented at Building - and maintaining home server conway 2017 is now running almost all tasks. The main migration was homedirectories, mail, news, webservers. Things are now split over several virtual machines and the base virtual machine running kvm virtual machines is as minimal as possible.

One thing I just noticed is that the new virtual machine with pppoe kernel mode drivers and updated software is doing great: the bigger MTU is working by default and kernel mode pppoe does not show up as using CPU when a 50 mbit download is active. I looked at CPU usage with htop and at the network traffic with iptraf and the result was that iptraf was using the most cpu.

There are still some things left to migrate, including a few public websites that currently give 50x errors. But I will find the time eventually.

Tags: , , ,
2018-09-24 After 25 years with sendmail there was still something to improve 3 weeks ago
I still like running sendmail on my own systems. But sendmail evolves with time and my configuration does improve slightly sometimes, such as on the introduction of authenticated smtp with secondary passwords.

After the recent upgrades to the home server there is a new mail server with some other new details and suddenly other systems at home could not relay. A bit of searching found Best practice: sendmail and SMTP auth with the right flags for the DAEMON_OPTIONS to only offer authentication on port 587 (submission).

I noticed the local systems tried relaying via port 587 so I changed this to port 25 where IP-based relaying is allowed. No idea why I set this up to use the port 587 when I set it up previously.

And yes, I checked it, I started with sendmail in 1993, so 25 years of sendmail on port 25. I did start with writing my own sendmail.cf rules but I switched to .mc based configurations.

Tags: , , ,
2018-09-21 Setting my bash prompt PS1 to remind me I'm in screen 4 weeks ago
With some systems constantly running screen and others not I started to get confused. Solution: change the visual indications in the prompt inside screen.

I decided to just change the username color in PS1 when I'm in screen. So now:
PS1='${STY:+\[\e[1;36m\]}\u${STY:+\[\e[0m\]}@\h:\w\$ '
In bash, ${STY:+..} gives output when shell variable STY is set. So I add the color set/unset commands to the prompt when STY, a typical screen variable is set. The result is dark cyan, a color that works (for me) on my normal light-grey background xterm/putty sessions.

Oh, and for root things are different:
PS1='\[\e[1;91m\]\u@\h\[\e[0m\]:\w\$ '
Which gives a light red user@hostname.

In the above \e causes an escape to be printed. Wrapping parts of the prompt between \[ and \] causes bash to ignore those for counting the length of the prompt so it doesn't get confused on redrawing the prompt when editing the commandline.

Samples of colours and other formatting at FLOZz' MISC » bash:tip_colors_and_formatting.

Tags: , ,
2018-09-06 Weird interface names in snmp due to virtio driver 1 month ago
I want to measure network traffic so I decided to copy most of my rrdtool setup from the old home server.

But with virtio network cards I have a confused snmpd:
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: Red Hat, Inc Device 0001
IF-MIB::ifDescr.3 = STRING: Red Hat, Inc Device 0001
IF-MIB::ifDescr.4 = STRING: Red Hat, Inc Device 0001
IF-MIB::ifDescr.5 = STRING: dummy0
IF-MIB::ifDescr.6 = STRING: dumhost
IF-MIB::ifDescr.7 = STRING: dumdh6
Fix: go for the IF-MIB::ifName snmp variables, found in oid 1.3.6.1.2.1.31.1.1.1:
IF-MIB::ifName.1 = STRING: lo
IF-MIB::ifName.2 = STRING: eth0
IF-MIB::ifName.3 = STRING: eth1
IF-MIB::ifName.4 = STRING: eth2
IF-MIB::ifName.5 = STRING: dummy0
IF-MIB::ifName.6 = STRING: dumhost
IF-MIB::ifName.7 = STRING: dumdh6
Those are easier to discern, now my snmp scripts are gathering data again.

Tags: , , ,
2018-08-17 Trying (and failing) to correlate security logs 2 months ago
Since activating sendmail authentication with secondary passwords I see a number of attempts to guess credentials to send mail via my system. This is not very surprising, given the constant attack levels on the wider Internet.

For work I am looking at log correlation and monitoring and with that in mind I noted that finding the right information from sendmail where and when the attempt came from is quite hard since there are several processes busy and it's hard to correlate the logging. The failed attempt is logged by saslauthd in /var/log/auth.log:
Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:28:59 greenblatt saslauthd[32648]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error]
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:29:02 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
This is probably related to this sendmail log information:
Aug 16 12:28:56 greenblatt sm-mta[20716]: STARTTLS=server, relay=62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 16 12:29:02 greenblatt sm-mta[20716]: w7GASspx020716: 62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6
But I can't be sure as there are multiple 'did not issue MAIL/EXPN/VRFY/ETRN' messages in the logs. So I can't build a fail2ban rule based on this.

Tags: , , ,
2018-07-27 Automating Let's Encrypt certificates with DNS-01 protocol 2 months ago
Encrypt all the things meme After thoroughly automating Let's Encrypt certificate renewal and installation I wanted to get the same level of automation for systems that do not expose an http service to the outside world. So that means the DNS-01 challenge within the ACME protocol has to be used.

I found out dehydrated Let's Encrypt certificate management supports DNS-01 and I found a sample on how to do this with bind9 at Example hook script using Dynamic DNS update utility for dns-01 challenge which looks like it can do the job.

It took me a few failed tries to find out that if I want a certificate for the name turing.idefix.net that it will request the TXT record for _acme-challenge.turing.idefix.net to make me prove that I have control over the right bit of DNS. I first assumed something in _acme-challenge.idefix.net which turned out wrong. So the bind9 config in /etc/bind/named.conf.local has:
zone "_acme-challenge.turing.idefix.net" {
        type master;
        file "/var/cache/bind/_acme-challenge.turing.idefix.net-zone";
        masterfile-format text;
        allow-update { key "acmekey-turing"; };
        allow-query { any; };
        allow-transfer {
                localnetwork;
        };
};
And in the idefix.net zone there is just one delegation:
_acme-challenge.turing  IN      NS      ns2
I created and used a dnskey with something like:
# dnssec-keygen -r /dev/random -a hmac-sha512 -b 128 -n HOST acmekey-turing
Kacmekey-turing.+157+53887
This gives 2 files, both with the right secret:
# ls Kacmekey-turing.+157+53887.*
Kacmekey-turing.+157+53887.key  Kacmekey-turing.+157+53887.private
# cat Kacmekey-turing.+157+53887.key
acmekey-turing. IN KEY 512 3 157 c2V0ZWMgYXN0cm9ub215
and configured it in /etc/bind/named.conf.options:
key "acmekey-turing" {
        algorithm hmac-md5;
        secret "c2V0ZWMgYXN0cm9ub215";
};
And now I can request a key for turing.idefix.net and use it to generate sendmail certificates. And the net result:
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256          
        verify=OK)                                                              
SMTP between systems with TLS working and good certificates.

Tags: , , ,
2018-07-19 Configuring sendmail authentication like imaps access to allow secondary passwords 3 months ago
I needed to configure sendmail authenticated access because I want a strict SPF record for idefix.net which means I always have to make outgoing mail originate from the right server.

For the sendmail authenticated smtp bit I used How to setup and test SMTP AUTH within Sendmail with some configuration details from Setting up SMTP AUTH with sendmail and Cyrus-SASL. To get this running saslauthd is needed to get authentication at all and I decided to let it use the pam authentication mechanism. The relevant part of sendmail.mc:
include(`/etc/mail/sasl/sasl.m4')dnl
define(`confAUTH_OPTIONS', `A p')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
And now I can login to sendmail only in an encrypted session. And due to sendmail and other services now having valid certificates I can set up all devices to fully check the certificate so I make it difficult to intercept this password.

And after I got that working I decided I wanted 'secondary passwords' just like I configured extra passwords for IMAPS access so I set up /etc/pam.d/smtp to allow other passwords than the unix password and restrict access to the right class of users.
auth    required    pam_succeed_if.so quiet user ingroup users
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    sufficient  pam_userdb.so db=/etc/courier/extrausers crypt=crypt use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
Now I can set up my devices that insist on saving the password for outgoing smtp and if it ever gets compromised I just have to change that password without it biting me too hard.

Tags: , , ,
2018-07-08 Automating Let's Encrypt certificates further 3 months ago
Encrypt all the things meme Over two years ago I started using Let's Encrypt certificates. Recently I wanted to automate this a step further and found dehydrated automated certificate renewal which helps a lot in automating certificate renewal with minimal hassle.

First thing I fixed was http-based verification. The webserver has been set up to make all .well-known/acme-challenge directories end up in one place on the filesystem and it turns out this works great with dehydrated.

I created a separate user for dehydrated, gave that user write permissions for the /home/httpd/html/.well-known/acme-challenge directory. It also needs write access to /etc/dehydrated for its own state. I changed /etc/dehydrated/config with:
CHALLENGETYPE="http-01"
WELLKNOWN="/home/httpd/html/.well-known/acme-challenge"
Now it was possible to request certificates based on a .csr file. I used this to get a new certificate for the home webserver, and it turned out to be easier than the previous setup based on letsencrypt-nosudo.
Read the rest of Automating Let's Encrypt certificates further

Tags: , , , ,
2018-06-23 SMART can be wrong 3 months ago
Someone brought me a 'WD My cloud' that does not respond at all. So I took it apart and found out how to access the disk in an i386 Linux system: mount the 4th partition as ext4. When the disk was available I did a smart test:
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
But while trying to find out how much data is actually on the disk, I get:
[  866.165641] Sense Key : Medium Error [current] [descriptor]
[  866.165645] Descriptor sense data with sense descriptors (in hex):
[  866.165647]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[  866.165659]         b0 90 ea 60 
[  866.165664] sd 2:0:0:0: [sda]  
[  866.165668] Add. Sense: Unrecovered read error - auto reallocate failed
So the disk isn't very healthy. But rerunning the smart check still shows nothing is wrong. It is a Western Digital 'RED' harddisk especially for NAS systems so it should return errors earlier to the operating system but this disk is bad, which is probably related to why the 'my cloud' enclosure isn't working.
Read the rest of SMART can be wrong

Tags: ,
2018-06-17 Apache 2.2 Proxy and default block for everything but the .well-known/acme-challenge urls 4 months ago
I'm setting up a website on a new virtual machine on the new homeserver and I want a valid letsencrypt certificate. It's a site I don't want to migrate so I'll have to use the Apache proxy on the 'old' server to allow the site to be accessed via IPv4/IPv6 (for consistency I am now setting up everything via a proxy).

So first I set up a proxy to pass all requests for the new server to the backend, something like:
        ProxyPass / http://newsite-back.idefix.net/
        ProxyPassReverse / http://newsite-back.idefix.net/
But now the requests for /.well-known/acme-challenge also go there and they are blocked needing a username/password since the new site is not open yet.

So to set up the proxy correctly AND avoid the username checks for /.well-known/acme-challenge the order has to be correct. In the ProxyPass rules the rule for the specific URL has to come first and in the Location setup it has to come last.
        ProxyPass /.well-known/acme-challenge !
        ProxyPass / http://newsite-back.idefix.net/
        ProxyPassReverse / http://newsite-back.idefix.net/

        <Location />
        Deny from all
        AuthName "Site not open yet"
        [..]
        </Location>

        <Location /.well-known/acme-challenge>
            Order allow,deny
            Allow from all
        </Location>
And now the acme-challenge is done locally on the server and all other requests get forwarded to the backend after authentication.

Tags: , , ,
2018-05-03 The preferring IPv6 policy is working 5 months ago
Yesterday I changed some IPv4 addresses on virtual machines on the new homeserver to make autofs work. This is a known issue with autofs: autofs does not appear to support IPv6 hostname lookups for NFS mounts - Debian Bug #737679 and for me the easy solution is to do NFS mounts over rfc1918 ipv4 addresses. I prefer autofs over 'fixed' NFS mounts for those filesystems that are nice to be available but aren't needed constantly.

It took about 9 hours before arpwatch on the central router noticed the new activity. I guess the policy to try to do everything over IPv6 is working.

Tags: , , ,
2018-04-24 KVM and os-specific defaults 5 months ago
Today I wanted to install a new virtual machine on the new homeserver and virt-install gave me a new warning:
WARNING  No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.
According to the virt-install manpage the --os-variant can be found with osinfo-query os which I can't find in Devuan jessie. But the same information is available via Installing Virtual Machines with virt-install, plus copy pastable distro install one-liners.

I chose debian7 as that is probably the closest to Devuan Jessie to be upgraded to Devuan ascii immediately.

The interesting change is that the resulting linux suddenly has virtio networkcards and a disk /dev/vda. That last bit is quite different from earlier virtual machines.

Tags: , ,
2018-04-06 Keeping squid webproxy running for network mismatches 6 months ago
I considered stopping using squid when upgrading to the new homeserver but I have now changed that decision: I need to keep it running for applications that want to do http connections to IPv6-only systems but can't handle those. There are some old scripts running that need it but it's also the way to fix the problem I noticed with linuxcounter.

Tags: , ,
2018-04-06 25 years of Linux use 6 months ago
Powered by Linux In looking at a problem with the linuxcounter script I noticed I am now passing the 25 years with Linux mark. I first saw it in the beginning of 1993 when part of my internship happened at the 'expa' lab (if I recall correctly) of Hogeschool Utrecht with SLS Linux.

Anyway, still using Linux a lot. It's been an interesting 25 years!

Tags: , ,
2018-01-27 I caused an interesting problem with the VDSL pppoe session 8 months ago
Normally being active on certain HF bands causes one-time VDSL disconnects but what I have currently done seems to have triggered something else. After the connection dropped it refuses to come back at the moment. The entire session looks like:
22:49:28.466922 PPPoE PADI [Service-Name]
22:49:28.490394 PPPoE PADO [AC-Name "dr12.d12"] [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL]
22:49:28.490603 PPPoE PADR [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]
22:49:28.517063 PPPoE PADS [ses 0x40c] [Service-Name] [AC-Name "dr12.d12"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL]
22:49:28.575266 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 72, length 16
22:49:28.575776 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 99, length 22
22:49:28.575798 PPPoE  [ses 0x40c] LCP, Conf-Reject (0x04), id 72, length 10
22:49:28.589161 PPPoE  [ses 0x40c] LCP, Conf-Ack (0x02), id 99, length 22
22:49:28.589164 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 73, length 12
22:49:28.589666 PPPoE  [ses 0x40c] LCP, Conf-Ack (0x02), id 73, length 12
22:49:28.589682 PPPoE  [ses 0x40c] LCP, Echo-Request (0x09), id 0, length 10
22:49:28.589693 PPPoE  [ses 0x40c] CCP, Conf-Request (0x01), id 89, length 17
22:49:28.589702 PPPoE  [ses 0x40c] IPCP, Conf-Request (0x01), id 89, length 18
22:49:28.589711 PPPoE  [ses 0x40c] IP6CP, Conf-Request (0x01), id 89, length 16
22:49:28.603265 PPPoE  [ses 0x40c] LCP, Echo-Reply (0x0a), id 0, length 10
22:49:28.603267 PPPoE  [ses 0x40c] LCP, Term-Request (0x05), id 74, length 6
22:49:28.604033 PPPoE  [ses 0x40c] LCP, Term-Ack (0x06), id 74, length 6
22:49:31.623454 PPPoE PADT [ses 0x40c] [Generic-Error "RP-PPPoE: System call error: Input/output error"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]
So in the end the router at my ISP decides to terminate the connection. On the connection failing I decided to change the configuration to use the kernel mode pppoe driver but after this started showing I reverted that change. Which made no difference, the connection is still not coming up.

Update: I went looking at other changes I made to enable the pppoe server test and reverting the /etc/ppp/pap-secrets file to its original format fixed the problem. I guess I somehow started to authenticate the remote end.

And changing from user-mode pppoe to kernel-mode pppoe does lower the MTU to 1492, so that test is also finished. Back to user-mode pppoe.

Tags: , , ,
2018-01-25 Building a testing server for pppoe 8 months ago
The new homeserver will have to run the same pppoe client setup as the current server. But I want to get the whole setup tested before the migration to minimize disruption.

Since I'm not going to get a free extra vdsl line and vdsl modem to test with and the complicated part is in the pppoe and ppp client part I decided to use a test vlan and set up a pppoe-server and ppp server on that vlan.

The pppoe server part is started with
# pppoe-server -I eth0.99 -C kzdoos -L 172.16.19.1 -R 172.16.21.19
And it's indeed available from the client:
# pppoe-discovery -I eth2
Access-Concentrator: kzdoos
Got a cookie: 84 39 c6 51 13 fe 32 00 2c 06 2a b4 38 0e 30 87 46 7b 00 00
--------------------------------------------------
AC-Ethernet-Address: 00:1f:c6:59:76:f6
So that part works. Next is to get an actual ppp session working over it.

The server part was a bit of work as I want to get the whole configuration including password checks. Server configuration in /etc/ppp/pppoe-server-options on the server system:
require-pap
lcp-echo-interval 10
lcp-echo-failure 2
hide-password
noipx
ipv6 ,
And the client configuration in /etc/ppp/peers/dray-vdsl:
user testkees
password topsecret
+pap
noauth
noipdefault
ipv6 ,
ipv6cp-use-persistent
defaultroute
persist
maxfail 0
noproxyarp
ipparam xs4all
lcp-echo-interval 10
lcp-echo-failure 6
pty "pppoe -I eth2"
Lots of options to make the setup exactly the same as the current. It took a lot of tries before password authentication was working. I could not get the client-side password in /etc/ppp/pap-secrets to work, but as show above the password in the ppp configuration did work.

And the setup in /etc/network/interfaces on the client just the same as the known configuration:
iface pppdray inet ppp
        provider dray-vdsl

And it works!
# ifup pppdray
Plugin rp-pppoe.so loaded.
# ifconfig ppp0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1492
        inet 172.16.21.45  netmask 255.255.255.255  destination 172.16.19.1
        inet6 fe80::5254:ff:fe3c:2014  prefixlen 10  scopeid 0x20<link>
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 9  bytes 252 (252.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 202 (202.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# ping -c 3 172.16.19.1
PING 172.16.19.1 (172.16.19.1) 56(84) bytes of data.
64 bytes from 172.16.19.1: icmp_seq=1 ttl=64 time=0.721 ms
64 bytes from 172.16.19.1: icmp_seq=2 ttl=64 time=0.436 ms
64 bytes from 172.16.19.1: icmp_seq=3 ttl=64 time=0.449 ms

--- 172.16.19.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.436/0.535/0.721/0.132 ms
The mtu is not yet what I want, but the session is alive.

Tags: , ,
2018-01-23 Avoiding the linux statefull firewall for some traffic 9 months ago
I was setting up a linux based firewall on a busy ntp server and to make sure everything worked as designed I added the usual:
iptables -A INPUT -j ACCEPT --protocol all -m state --state ESTABLISHED,RELATED
And after less than half an hour the system log started filling with
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
It is indeed a busy server. The solution is to exclude all the ntp traffic from the stateful firewall. Which means I have to allow all kinds of ntp traffic (outgoing and incoming) by itself.

The specific ruleset:
iptables -t raw -A PREROUTING --protocol udp --dport 123 -j NOTRACK
iptables -t raw -A OUTPUT --protocol udp --sport 123 -j NOTRACK

iptables -A INPUT -j ACCEPT --protocol udp --destination-port 123
I also made sure the rules for the ntp traffic are the first rules.

Traffic at this server is somewhat over 1000 ntp request per second. So the counters of the NOTRACK rules go fast.
# iptables -t raw -L -v
Chain PREROUTING (policy ACCEPT 1652K packets, 126M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9635K  732M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK
1650K  125M CT         udp  --  any    any     anywhere             anywhere             udp dpt:ntp NOTRACK

Chain OUTPUT (policy ACCEPT 1522K packets, 117M bytes)
 pkts bytes target     prot opt in     out     source               destination 
9029K  686M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK
1520K  116M CT         udp  --  any    any     anywhere             anywhere             udp spt:ntp NOTRACK
But no packets are dropped, which is good as this server is supposed to be under a constant DDoS.

Tags: , , ,
2018-01-14 Recovering firmware on the Draytek Vigor 130 VDSL2 modem with linux / macosx 9 months ago
Note beforehand: I have not tested this procedure, every time I needed it it was faster to boot Windows to run the utility Draytek has available.

I needed the recovery procedure again: there was a new firmware 3.8.12 with newer VDSL modem driver and the standard update via the webinterface failed.

I just want to keep the notes from "OzCableguy" since his shop and blog have gone. I found the saved version via archive.org, Updating Draytek firmare using the MacOS X or UNIX command line and TFTP - OzCableguy.

Draytek modems have several methods available to update their firmware.

You can use the Firmware Upgrade Utility under Windows, load it from the web interface via HTTP, FTP the file to the modem or use the TFTP (Trivial File Transfer Protocol) service built into the box.

If your modem has been bricked you can’t use FTP or HTTP. If you don’t want to use Windows or go through the web interface, then this TFTP method is a viable alternative. Note that unlike a lot of other boxes using TFTP to load firmware, the Draytek is acting as a TFTP server, the UNIX/MacOS box as a client and you PUT the file onto the modem. It is normally the other way around, but that needs some extra setup steps that are conveniently avoided with this method.

The firmware comes in two pieces. Use the .rst version of the file if you want to change the modem settings back to factory defaults, use the .all file to keep the current settings (.all may not be a good option if the modem is bricked).

Secondly you need an ethernet interface on your Mac or UNIX box set to the subnet 192.168.1.0 (eg: with IP address 192.168.1.10) so that you can talk to the modem at its default IP address of 192.168.1.1.

If the modem is up and running (and not bricked), you should now be able to ping it ..
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.309 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.421 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.409 ms
^C
—-192.168.1.1 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.309/0.380/0.421/0.050 ms$ 
If your modem is really bricked then the ping will only work when the modem is actually in TFTP upload mode as below. You can ignore this step, it just demonstrates that the ethernet cable is working.

Now we can upload the firmware. With the modem powered off, press and hold the factory reset button, then power up the modem. Continue to hold the button down until ’some’ of the lights flash together. On the Vigor2820Vn ’some’ is the left column of three. On the 2800 and 2910 the left two LEDs flash.

Release the button and on your UNIX/MacOS box type the following commands (note that the modem only stays in TFTP mode for a short time, you can actually type right up to the end of the put command and just press return when the left-hand modem lights start flashing).

The name of the firmware and the number of bytes transmitted depend on the product you are trying to recover.
$ tftp 192.168.1.1
tftp> binary
tftp> put v2820_v03301_211011_A.rst
Sent 4973144 bytes in 13.1 seconds
tftp> quit
$ 
There will be a pause after the ‘put’ command, but your modem ethernet port light should be flashing madly. The transfer is done when you get the “Sent” message. Quit the TFTP client and perhaps your Terminal session, there’s nothing more to see.

What happens next isn’t really documented but we presume that the modem has to unpack the firmware and load it into flash. On our 2820Vn the column of 3 lights continued to flash, but gradually slowed down, speeded up, then slowed again. Eventually after a minute or two the modem rebooted in the normal fashion. Just be patient.
And this last bit is where the windows utility is better: it will tell you when the recovery is done and a success. With a commandline tool you'll just have to wait for the leds to blink right.

After all the recovery and the waiting the modem works again and the line is stable. I chose the 'modem6' version again. I may try the 'modem5' and 'modem4' version too to see whether I can get lower latency without losing stability. Although the improvement may be in the single digit millisecond range so it would be a lot of work for very little improvement.

Tags: , ,
  Older news items for tag linux ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews