Archive for the ‘network’ tag

Streaming pcap to a dummy interface  

Posted at 10:09 pm in Uncategorized

In an earlier article, I described how to stream captured network traffic to a remote host for IDS analysis with Snort. Mikrotik units can stream captured traffic elsewhere using the TaZmen Sniffer Protocol (TZSP). tcpdump and Wireshark natively decode this protocol, but unfortunately it doesn’t seem to be supported by any other of the large amount of useful network analysis tool.

The main usage for streaming the network capture is feeding it to the Snort IDS, and for this single purpose (and since Snort can read from STDIN) piping the traffic directly from tzsp2pcap to Snort works very well. However, now and again I need to look at the network traffic without having to detach Snort from the live stream.

This was solved by making the network traffic stream available over a dummy interface with the brilliant tool tcpreplay, to which I can attach any tool that understands pcap. These are the required incantations:

/sbin/modprobe dummy
/sbin/ip link set name eth10 dev dummy0
/sbin/ifconfig eth10
/usr/bin/screen -dm -S tzsp2pcap \
bash -c "/usr/local/sbin/tzsp2pcap -f | \
/usr/bin/tcpreplay --topspeed -i eth10 -"
/etc/init.d/snort start # configured to listen to eth10

The tzsp2pcap process must be run in a screen. Involving bash is required because of the pipe. With tcpreplay --topspeed is useful to avoid delays in the feed.

At this stage, I can point any network tool at eth10 without disrupting Snort.

Written by bjorn on October 5th, 2015

Tagged with , , , , , ,

Mobile entertainment center  

Posted at 8:25 pm in Uncategorized

Our three kids very seldom agree which TV program or movie to watch. Allowing for less discussion when screen time is granted, I’ve set up a mobile entertainment center where each kid may watch the movie of their choice – this may be used during long drives, on trains or buses, and everywhere else where there’s low or no voltage and a need to grant the kids some screen time.

The setup is simple, using a Raspberry Pi B+ running Raspbian and a Mikrotik mAP2n. The RPi is directly connected to the mAP2n with an Ethernet cable. Both are/can be powered by microUSB voltage and cable. The RPi is also equipped with a USB WiFi adapter, configured as a WiFi client, so when the unit is within range of the wireless network at home I can update it and transfer media files to it.


The two units tied together with velcro. When finalizing the project I will need to find a better case.

Packages installed on the RPi

After having slimmed down the RPi by removing any package not needed, I installed minidlna. While the minidlna project was recently renamed to ReadyMedia, in Debian/Raspbian it still goes by its former name. To administer the mAP2n from the RPi I also installed mactelnet, and to make sure both units logged with useful timestamps I added an ntp server. Finally, it seems the mAP2n does not support running a DHCP server, so I left that to the RPi (isc-dhcp-server). The DHCP server listens only on eth0, to which the mAP2n is connected.

Configuring the tablets

On each kid’s tablet, I installed a DLNA controller (I chose the Ginkgo DLNA player, but I assume any kind of DLNA/UPnP controller will do). Note that the Ginkgo DLNA player is simply streaming from the media center to the device, but not rendering the content – you will need something else for that. I’m very fond of VLC for Android and it works excellent in this use case.

Setting up the mAP2n

Configuring the mAP2n as an AP/bridge, a separate SSID was configured. The mAP2n synchronizes its clock to the RPi. The interfaces wlan1 and ether2 are bridged, and the bridge holds the unit’s IP address.


In essence:

  1. Install Raspbian on a Raspberry Pi.
  2. Install minidlna and isc-dhcp-server.
  3. Configure wlan0, supplying SSID and credentials, for being a WiFi client.
  4. Make sure you can SSH to the RPi over the wlan0 interface. When successful, configure static IP on eth0.
  5. Connect ether2 on mAP2n to eth0 on the RPi.
  6. Configure the mAP2n as an AP/bridge. Set up SSID and credentials for the AP.
  7. Set up the tablets for DNLA streaming.
Note the USB WiFi adapter, providing wireless update of the RPi unit when within range of the home network.

Note the USB WiFi adapter, providing wireless update of the RPi unit when within range of the home network.

Configuration snippets

Configuration for RPi network /etc/network/interfaces:

auto lo
iface lo inet loopback
auto wlan0
iface wlan0 inet dhcp
    wpa-ssid YourSSID
    wpa-psk SomeSecretPassword
auto eth0
iface eth0 inet static


DHCP server configuration file /etc/dhcp/dhcpd.conf:

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
subnet netmask {


DHCP server configuration file /etc/default/isc-dhcp-server:



Minidlna configuration file /etc/minidlna/minidlna.conf:

# These are all defaults


mAP2n configuration (sensitive data removed):

[admin@YourAP] > /export
/interface bridge
add name=bridge
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk \
    mode=dynamic-keys supplicant-identity=MikroTik \
add authentication-types=wpa2-psk mode=dynamic-keys \
    name=YourAP supplicant-identity=YourAP \
    wpa-pre-shared-key=SecretPassword \
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n \
    country=norway disabled=no frequency=auto \
    l2mtu=1600 mode=ap-bridge security-profile=YourAP \
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=wlan1
/ip address
add address= interface=bridge network=
/system clock
set time-zone-name=Europe/Oslo
/system identity
set name=YourAP
/system leds
set 3 interface=wlan1
/system ntp client
set enabled=yes primary-ntp=



Throughput with three concurrent players showing .mkv movies (720×576 px, 25fps, H264 MPEG-4 AVC, MPEG AAC) sometimes peaks at around 22 Mb/s, and the RPi doesn’t break a sweat when serving at that speed. Obviously different formats would affect the RPi load and WiFi throughput.

Attaching a 4 x AA portable battery pack as shown below, the two units (mAP2n USB powered from the RPi) were running for more than three and a half hour, and during this period they streamed movies to one tablet for two and a half hour.

Exibel battery pack bought from Clas Ohlson.

Exibel battery pack bought from Clas Ohlson.

And for those who might ask: Yes, a Raspberry Pi could simply be equipped with two WiFi adapters, one for client access and for for AP. There are lots of different approaches to this. In my case, I had a spare mAP2n just lying there…

Written by bjorn on May 3rd, 2015

Tagged with , , , ,

CRS serial console with kermit  

Posted at 10:57 am in Uncategorized

For those still inclined to use kermit for serial console access, these are the commands for connecting to a MikroTik CRS125 with default settings:

# kermit
C-Kermit 8.0.211, 10 Apr 2004, for Linux
Copyright (C) 1985, 2004,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
(/root/) C-Kermit>set line /dev/ttyUSB0
(/root/) C-Kermit>set speed 115200
/dev/ttyUSB0, 115200 bps
(/root/) C-Kermit>set carrier-watch off
(/root/) C-Kermit>connect

Written by bjorn on April 10th, 2015

Tagged with , , ,

MikroTik configuration revision control with rancid  

Posted at 10:28 pm in Uncategorized

The config revision control tool rancid (Really Awesome New Cisco confIg Differ, but not at all limited to Cisco devices) has proven extremely useful. Rancid notifies you if there’s been some changes to a device, and since it’s Subversion backed it’s easy to extract full configurations in case you need it. Rancid has been supporting MikroTik devices for some time now.

Rancid exists in a lot of Linux repositories, or it could be installed from source – how to do that is documented elsewhere. After installing rancid, here’s what was needed for rancid to keep an eye on my MikroTik devices.

First I created a readonly user across all MikroTik units, intuitively named rancid. To mass create this account, I used dsh – described in an earlier article. Make sure your Linux system’s rancid user is able to log in to your devices using SSH keys and not passwords.

Next step is configuring rancid’s authentication file, ~/.cloginrc. Even though a password is required in the file, setting the identity will make rancid use key based SSH logins. Here’s my .cloginrc for reference:

add user * rancid
add password * SomeGarbledPasswordThatWon'tBeUsedAnyway
add method * ssh
add identity id_dsa

To verify that rancid may log in to the MikroTik devices, try a manual login as the rancid user:

~$ ~rancid/bin/mtlogin

You should be logged in to the device, and in the device’s log you should see

publickey accepted for user: rancid+ct

Now that the rancid user is able to log in to your units, it’s time to move on with configuring rancid. Most rancid.conf settings work out of the box, I only had to change these to convince rancid to use Debian’s standard svn repo directory. Make sure the “rancid” user or group has the necessary permissions to create a new repo. I also created a group called “devices”.

CVSROOT=/var/lib/svn/rancid; export CVSROOT
RCSSYS=svn; export RCSSYS

After running rancid for the first time, a new repo has been created. Under ~rancid/var/ a “devices” directory has been created. In here you will find a file named “router.db”. Here you need to add your devices, like this:

When all this is in place, it’s time to allow rancid to run from cron.

Written by bjorn on February 2nd, 2014

Tagged with , , ,

Securely managing multiple Mikrotik units with dsh  

Posted at 9:01 pm in Uncategorized

dsh is a nice Unix/Linux tool for managing multiple systems efficiently, and I’m using it both at home and at work. In some distributions dsh has been replaced by pdsh, but no worries, pdsh is dsh compatible. Since all MikroTik devices running RouterOS might be managed over SSH, why not use dsh to manage these as well? Here’s a quick howto.

  1. Install ssh and dsh.
  2. If you don’t have one already, create an SSH DSA key pair:
    ssh-keygen -t dsa
    Do this with the Unix/Linux user account you’re managing the devices from. I strongly recommend securing the key pair with a password.
  3. Distribute the public part of the key pair ( to each MikroTik unit, using an existing account (e.g. admin). I used ncftpput for efficient distribution. The public key should now be visible in the “Files” folder on each MikroTik device.
  4. Now attach the public SSH key to a user account. I’ll use the admin account in this example. In cli, this is done with
    /user ssh-keys import user=admin
  5. Create a dsh group file, let’s call the group mikrotik (either /etc/dsh/group/mikrotik or ~/.dsh/group/mikrotik). Add the IP address or hostname of each MikroTik devices to this file, one unit per line. Specify the user name if required.

Sample group file:


You should confirm that SSH works fine with each device before expecting dsh to work. Example command:

~$ ssh admin@

When this works fine, you’re now ready to mass manage your MikroTik devices. A few useful commands are shown below.

Check for and download the newest RouterOS version to all devices:

~$ dsh -g mikrotik '/system package update check-for-updates'
~$ dsh -g mikrotik '/system package update download'
~$ dsh -g mikrotik '/system package update print'

Change admin’s password (note that this will leave the new password in your user’s shell history):

~$ dsh -g mikrotik '/user set password=ThisIsTheNewPassword admin'

Check if any device needs a firmware upgrade:

~$ dsh -g mikrotik '/system routerboard print'

Add a new user:

~$ dsh -g mikrotik '/user add name=NewUser disabled=no group=full'

Written by bjorn on February 2nd, 2014

Tagged with , ,

Reaching multiple instances of the same IP address  

Posted at 7:01 pm in Uncategorized

A friend recently presented me with the following challenge: Configure a system through which several appliances, all of them having an identical, non-routable, default IP configuration, can be reached simultaneously. All appliances are preconfigured with an IP address of and they had no routing configuration enabled. Yet they should all be reachable over the Internet. The diagram below shows the basic infrastructure.

For the server (the nice grey cabinet to the left) to reach all those systems at the same time, a VLAN setup was required, so we set up a VLAN trunk to a nearby switch. Then the different appliances were connected to different un-tagged switch ports in dedicated VLANs – the first appliance was connected to a switch port in VLAN 10, the next to a switch port in VLAN 11, etc. Corresponding VLAN interfaces were configured on the server, and a local IP address was configured on each. To keep a minimum level of sanity, I configured the VLAN interface on vlan10 as, while vlan11 got, etc. To avoid too much confusion on the switch, I also set the MAC address on each VLAN interface to distinct values.

Next step was to configure correct IP routing using iproute2:
# VLAN 10
/sbin/ip link add link eth1 name eth1.10 type vlan id 10
/sbin/ip link set dev eth1.10 down
/sbin/ip link set dev eth1.10 address 00:04:de:ad:be:10
/sbin/ip link set dev eth1.10 up
/sbin/ip addr add local brd dev eth1.10
/sbin/ip route add dev eth1.10 proto kernel scope link src table 10
/sbin/ip rule add from lookup 10 prio 1010
# VLAN 11
/sbin/ip link add link eth1 name eth1.11 type vlan id 11
/sbin/ip link set dev eth1.11 down
/sbin/ip link set dev eth1.11 address 00:04:de:ad:be:11
/sbin/ip link set dev eth1.11 up
/sbin/ip addr add local brd dev eth1.11
/sbin/ip route add dev eth1.11 proto kernel scope link src table 11
/sbin/ip rule add from lookup 11 prio 1011

At this point I could reach the different appliances from the different source IPs:
# ping -I -c1
PING ( from : 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.119 ms

Snooping with tcpdump on the different VLAN interfaces, also showing the MAC addresses, confirmed that the pings were reaching the correct appliance.

Then I set up corresponding IP addresses on the outside interface (eth0). The address matches the device in VLAN 10, matches VLAN 11 and so on. The outside IP addresses are official IP addresses, but I’ve changed them to protect the innocent.

/sbin/ip addr add local dev eth0
/sbin/ip rule add to fwmark 10 table 10
/sbin/ip rule add fwmark 10 lookup 10
/sbin/ip addr add local dev eth0
/sbin/ip rule add to fwmark 11 table 11
/sbin/ip rule add fwmark 11 lookup 11

To make sure the packets were being identified correctly all the way through, they were tagged upon reaching the outside interface, based on the IP on which they arrived.

So far so good, now it was time for iptables to show its powers:
# VLAN 10
/sbin/iptables -t mangle -A PREROUTING -i eth0 -d -j MARK --set-mark 10
/sbin/iptables -t nat -A PREROUTING -i eth0 -d -j DNAT --to-destination
/sbin/iptables -A FORWARD -m mark --mark 10 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 10 -j SNAT --to-source
# VLAN 11
/sbin/iptables -t mangle -A PREROUTING -i eth0 -d -j MARK --set-mark 11
/sbin/iptables -t nat -A PREROUTING -i eth0 -d -j DNAT --to-destination
/sbin/iptables -A FORWARD -m mark --mark 11 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 11 -j SNAT --to-source

The above commands maps the outside addresses on eth0 to the corresponding VLANs on the inside. Note that every incoming packet is destination NATed (DNAT) to while they are being source NATed (SNAT) based on the VLAN to which they are mapped. As the appliances were not able to route traffic, all communication had to look like it happened on the local network only.

Now I expected to be able to access each appliance from the outside, but it turned out that only one appliance could be reached. tcpdumping on each VLAN interface confirmed that traffic from the outside reached each appliance, and the appliance responded, but the response never came all the way back. This was rather puzzling as nothing appeared in any log. However, my colleagues reminded me about rp_filter, which dropped weird traffic without logging anything. Thus, the key that unlocked everything was this:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1.10/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1.11/rp_filter

And voila – from the outside world, we were able to reach every single appliance on the inside, all with the same unroutable RFC1918 address.

Written by bjorn on February 24th, 2011

Tagged with , , , , ,