DD-WRT

I spent some time today dissecting DD-WRT, which is an open source operating system used on many routers and embedded devices (that use Wireless technologies, especially 802.x).

Looks like it uses BusyBox for most of the binaries. BusyBox appears to be a single binary that can run many of the GNU / POSIX unix/linux-descended binaries. It's supposed to be more compact. For example, options have been stripped away or replaced on many of the binaries in the name of compact simplified code (lower footprint).  It is open source, so one can download, inspect, compile, etc.

For ssh, it uses something called DropBear. Again, a compact ssh server.

The webserver, httpd, looks to be an in-house developed web server (meaning, written by developers of dd-wrt). Chillispot is the access point controller.  ttraff is used as the traffic counter. dnsmasq is used as the DHCP server on the box.

All in all, the box looked very tight - with 40M used of 256M,

In some ways interesting, in other ways, uninteresting - which is a good thing for embedded devices.

Windows 10 Chatter

I wanted to take some time to do some forensic analysis on my router (this is another blog entirely).

One of the things I noticed, was how busy the router was.

Well, hey. It's a busy house. And the whole family is here this weekend, all streaming NetFlix on phones, laptops, et al.

But - I noticed an inordinate amount of traffic from one PC.

Upon doing some further investigation, using packet sniffing tools, Task Manager, et al. I realized that Microsoft was calling home for a number of reasons.

I should have looked into this more when I bought this PC, but got busy. Shame on me.  I saw all kinds of things, and starting shutting down services, etc. Finally, I after shutting down so many things, and continuing to see packets flowing, I went out to the web and found this link - which is reasonable recent.

http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/?comments=1

I also read the comments, and wound up installing DisableWinTracking. I downloaded the source code first (as a tar file), and looked it over. Deciding it looked clean, I went ahead and ran the program, which is a series of powershell scripts that disable the tracking. There's a considerable amount of it. I un-installed all of the Microsoft apps listed, and disabled the services (I did not delete them - just disabled them). You have to be a little worried about shutting off your security updates on Windows 10, which is something I will need to monitor.  But a lot of that crap, I agreed with and decided was not really in my interests at all, and in fact was sucking up bandwidth and tying up an already-busy router.

Now, I'll go back and start looking at traffic again.

Firewall HA with conntrackd and keepalived

As we are doing some keepalived work, and looking at groups of IPs, I came across a couple of links worth mentioning:

This link below shows an approach of using a vrrp_sync group for an internal and external network. This is very much along the lines of what we were thinking we wanted to achieve and it was nice to see reassurance that we might be using a sync group as it is intended to be used (given the dirth of use-case documentation on this).

http://manpages.ubuntu.com/manpages/precise/man5/keepalived.conf.5.html

Another link is this one below.

Up to this point I have only been testing the VIP assignment and reassignment by pulling cables and making firewall adjustments (to make sure the VRRP could get through the firewall).

This link below has me concerned that true client testing might (will?) fail. Because indeed, Firewalld and iptables on Linux are, indeed, stateful firewalls. So I may need this link to bail me out.

http://backreference.org/2013/04/03/firewall-ha-with-conntrackd-and-keepalived/

VRRP Testing Round 3

Today, tested the concept of a Synch Group.

Used the configuration (essentially) from this ubuntu manpage.
http://manpages.ubuntu.com/manpages/precise/man5/keepalived.conf.5.html

Worked very well on VirtualBox, where we connected and disconnected virtual cables and watched the IPs move, in tandem.

Using just two instances if you disconnect one interface on each, VRRP considers itself in a complete fault state and neither box gets a virtual IP on either interface - which is what you want if it's a synch group.

Pretty happy with this testing.

BTW...another site I found had some decent comments about some options:
https://linux.die.net/man/5/keepalived.conf

Multicast - Low Level How it Works

http://www.firewall.cx/networking-topics/general-networking/107-network-multicast.html

VRRP Testing Note 2

In doing some extensive testing with VRRP with Keepalived, I was able to put it into Split Brain mode.

I have documented how I did this, and I will need to see if it is repeatable.

Here is one link that discusses troubleshooting for this, although I will need to find others.

https://www.atlantic.net/community/howto/vrrp-keepalived-configuration/

UPDATE: Here is another.

http://serverfault.com/questions/512153/both-servers-running-keepalived-become-master-and-have-a-same-virtual-ip

In his case on this link, here is the solution.

The problem has been resolved.

The problem was from the switch setting. When multicast filter mode is filter-all, the problem happened. The Keepalived runs O.K. when multicast filter mode is forward-all.

In his specific case, unicast could be the answer.

I realize that I do not have that mcast src ip in my file (don't think that is needed but I can add it).

I could also try to use PASS instead of AH. So I can experiment with that as well.

VRRP Testing - Note 1

First problem I ran into was with SeLinux. Apparently when the notify script wanted to write to an output file, SeLinux complained and prevented this. This made it impossible to tell if the script was even working, and therefore made it very hard to tell if VRRP / Keepalived was working.

I got around this by changing SeLinux to permissive in the /etc/selinux/conf file.

With permissive, it still complains, but does not prevent.


Next, I came to realize that the configuration parameters that were being used to start keepalived were in the /etc/sysconfig/keepalived folder.

I changed these parms to use -P -D -d -S 7.

The -P is for VRRP Only option.
-D is for Debug
-d is for dump config
-S is for log level, which is set to 7 for maximum logging.


With these changes, I noticed that BOTH virtual machines had a virtual IP, instead of just one. This surprised me. I expected only one to use the virtual IP and that it would switch back and forth.

But, doing some initial testing by disconnecting adaptors, I could see the state change being logged out to the log file.