Using vconfig to set vlan tagged interface with 802.1p CoS priority bits set

tux This is just quick how-to on setting up vlan interface on a Linux system. As this is in lengths described elsewhere I will stick just to the commands and brief explanations.

The first thing to do is to get the “vlan” package as it is not normally installed. The other bit is the 8021q kernel module which is not normally loaded but is present on Debian-based systems by defualt.

Checking the state of the module:

lsmod | grep 8021q

if this will return empty result you must load the module using mordprobe

modprobe 8021q

and verify again with lsmod as before.

Now the system is ready to get new tagged interfaces

vconfig add eth0 X

Where eth0 is your physical interface and X is the VLAN ID you want the new interface to be tagged with. The command will have an output saying that interface eth0.X has been created. This is great but you also must now somehow specify what pbit setting do you want in there as by default egress traffic is by default priority 0. In order to make lets say ping ICMP packets marked with CoS we must create an egress map for the default priority (o) in which we will re-map it to whatever we want.

vconfig set_egress_map eth0.X 0 7

In this example I have re-mapped the default priority 0 to egress priority 7

This setup can be made permanent by adding the module name in /etc/modules and adding the relevant lines in the interfaces file e.g.:

auto eth0.100
iface eth0.100 inet static
vlan-raw-device eth0


Prolific USB-to-serial on debian sid howto

As it happens over the time I came across a situation where I was using a Linux machine to connect to some networking boxes. Unfortunately the fact was that the only serial connection available was my personal usb-to-serial cable which I have bought quite some time ago and which was a major pain in the behind to make work under windows 7 64bit. Well long story short making it work under Debian was almost as “happy” and painful experience.

To start with there is enough information all around the Internet but the problems are as usually inconsistency and some Debian specifics. So let us have a look on the pre-requisities for this small exercise. My machine was running Debian Sid/Wheezy with 2.6.32 kernel but it works with the 2.6.38 as well and will probably work wit almost anything. The reason why I am mentioning this is that the first thing you need to find out is if you have the proper driver.  The way to see that is your driver type/make etc. you would need to plug it in and search in the dmessages (dunning the dmesg command) or in the messages file located in /var/log/messages.

May 16 22:26:26 Hell kernel: [ 351.649316] usb 2-1.3: new full speed USB device using ehci_hcd and address 3
May 16 22:26:26 Hell kernel: [ 351.742481] usb 2-1.3: New USB device found, idVendor=067b, idProduct=2303
May 16 22:26:26 Hell kernel: [ 351.742488] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 16 22:26:26 Hell kernel: [ 351.742494] usb 2-1.3: Product: USB-Serial Controller D
May 16 22:26:26 Hell kernel: [ 351.742498] usb 2-1.3: Manufacturer: Prolific Technology Inc.
May 16 22:26:26 Hell kernel: [ 351.830383] USB Serial support registered for pl2303
May 16 22:26:26 Hell kernel: [ 351.830418] pl2303 2-1.3:1.0: pl2303 converter detected
May 16 22:26:26 Hell kernel: [ 351.831987] usbcore: registered new interface driver pl2303
May 16 22:26:26 Hell kernel: [ 351.831990] pl2303: Prolific PL2303 USB to serial adaptor driver

As it happens in my case the usb-toserial reduction is the pl2303 and the driver included in the Debian stock kernel which is nice but not sufficient for anything to work. Now there are two possible things that might have happened when you plug the USB connector in. Either the module has been recognized an loaded automatically or you would need to load it manually (it depends on your udev configuration). The command to find out if the module is loaded already is this:

$ modprobe -l | grep pl2303

As it is obvious that we do work on rather low level of the OS I don’t think that reminding the necessity of being logged in as a root is really needed. If the returned result is empty then the module has not been loaded. In which case it is necessary  to load it manually with the following command:

$ modprobe pl2303

and then verify

$ lsmod | grep pl2303

If the result is satisfactory and the module is loaded the next step is to verify that the proper device in the /dev directory has been created. This is a point where various tutorials will claim different things as this is one of the distribution-and-version-specific things. Anyway in the system I’ve described above the file is under /dev/ttyUSB0 Again this might and probably will be different on different systems. You can find what device has been created by the same means as you’ve used for finding out of the driver options – with dmesg command or in the /var/log/messages file

May 16 22:26:26 Hell kernel: [ 351.831964] usb 2-1.3: pl2303 converter now attached to ttyUSB0

Once you find out the what is the device created by udev you’ll need to change two things. If you want to use the console as unprivileged user you need to add this user to the group “dialout” the second and actually more important thing is to change the group ownership of the device file in /dev The reason behind this is that all hardware is by default owned by root and the group root unless specified otherwise. that is fairly good point as normal users don’t normally have the need to access the hardware directly except for few cases and this i exactly one of those.

So the final ownership is owner:root group:dialout

root@Hell:/dev# ls -lah ./tty0
crw-rw-rw- 1 root dialout 4, 0 Jun 11 21:07 ./ttyUSB0

The last step in connecting to the remote system. As in this instance the logic is the same as with dialed connection we need some small software to handle in my case I picked the “cu” software which behaves best amongst those I’ve tested. As the package is in the standard repository you can use the

$ apt-get install cu

or if you think that it might be already installed just try

$ dpkg -l cu

which will give you the following result

$ dpkg -l cu
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
ii cu 1.07-20 call up another system

So the last step is to use cu to connect to the device. This can be achieved by

cu -s 9600 -l /dev/ttyUSB0

Where -s parameter is obviously for speed in bauds and th -l parameter is for the line interface.
After this you should be able to communicate with the networking device. Hope this was helpful – I believe I will enhance this article but as t quick & dirty howto it should be all right.


tuxFirehol is an nice and easy overlay for IPtables – which means it will allow you to manage IPtables without going really learn their syntax by providing simple config file and few scripts that will do the work for you.

For better description see the FireHOL’s  homepage. As this is not a firewall in the real meaning of the word so if you need a full-scale solution you should consider using something more powerful (e.g. software or even hardware firewall). But if you are looking for some solid but simple solution for Linux FireHOL is what you were looking for.

So at first what firehol can and can’t. As FireHOL is basicaly just a way how to write the iptables entries it has more or less the same possibilities and limitations. Iptables programme is a way how to access the NetFilter (which is part of the kernel), and FireHOL is just an simpler way how to write the iptables access rules  in a form of simple config file.  As for you getting the idea – iptables have  “chains of rules” which means you can do something like ACL rules where these rules belong to one ACL. These basic chains are predefined: INPUT, OUTPUT, and FORWARD. Each of these chains have some some action like ACEPT, REJECT of DROP. So this is really very similar to ACLs – just much more extensive. But there is one small problem (or davantage if you want) – as IPtables operates on L3 and L4 with all kinds of protocols. The rules are held in one huge table so things can get little more than complex very easily. This can result in difficult orientation in case of problem occurence. For example very simple config done in FireHOL (shown later) results in 139 lines of rules in iptables (you can use command “iptables -L” to review your rules).

So that’s for limitations and background. But what actually FireHOL (IPTables) can do. Well it is simple it can do almost everything. From simple firewall to protect a single server to setup where this will be a primary way to secure acceses between LAN,DMZ and WAN and thus relieveing your overloading router. The possibilities are really wide.

If you wisit the mainpage of FireHOL project you can notice that the last release is more than year old but that is just as there are no changes in IPtables and neither in any related piece of code.

This being said there is few bonuses which make firehol better choice than IPTables. As FireHOL is not a service it adds no overhead, but it adds few perks IPTables do not have (at least I am no aware of it).

  • First one is command “firehol try” when you can try if your config will not cut you off before saving the IPtables chains.
  • Second is command “firehol panic” which after some small sonfig will cut off all connections except of predefined ssh so in case of attack you can efectively re-gain at least some control over your mashine.
  • Third is command “firehol helpme” which will try to guess what services are running on your server and even generates some sample config file you can use for start.
  • Foutrh and final is that FireHOLstores it’s config in much nicer and more “human-readable” from than IPtables.

So these are the advantages, and there is one more – if you are in need of manipulating the IPtables directly you can do that. Unfortunately when you will re-generate the IPtables rules with firehol the changes will be lost. So maybe it is a good idea to have your manual changes backed up with “iptables-save” command.

So now when the dry theory is behind us let’s go for some quick and dirty setup of firehol as a simple server/ PC station firewall.

As usually firehol is a standard debian package and after installation it will expect a config file in /etc/firehol But as we did not yet create one there will be none. The point is when you install FireHOL on debian it will be automatically added to rc default which means it will run automatically after boot and if there was a sample config you could end up unable to connect to your box.

Wll step one is to su to root (as IPtables are not accessible by common users) and run

charon:~# firehol helpme > firehol.conf

:,v 1.256 2007/05/22 22:52:53 ktsaou Exp $
(C) Copyright 2003, Costa Tsaousis <>
FireHOL is distributed under GPL.
Home Page:
FireHOL controls your firewall. You should want to get updates quickly.
Subscribe (at the home page) to get notified of new releases.
FireHOL will now try to figure out its configuration file on this system.
Please have all the services and network interfaces on this system running.
Your running firewall will not be stopped or altered.
You can re-run the same command with output redirection to get the config
to a file. Example:
/sbin/firehol helpme >/tmp/firehol.conf

Building list of known services.
Please wait…
Press RETURN to start. [continue] >

— snip — snip — snip — snip —


This will result in file firehol.conf with estimation of your services and rules they probably need.
As Firehol is primarily intended to be on router the result will be much different than expected.

# Date: Sun Apr 19 15:45:46 CEST 2009 on host charon
# The TODOs bellow, are YOUR to-dos!

### DEBUG: Processing interface ‘eth0’
### DEBUG: Processing IP of interface ‘eth0’
### DEBUG: Is part of network yes

# Interface No 1.
# The purpose of this interface is to control the traffic
# on the eth0 interface with IP (net: “”).
# TODO: Change “interface1” to something with meaning to you.
# TODO: Check the optional rule parameters (src/dst).
# TODO: Remove ‘dst’ if this is dynamically assigned.
interface eth0 interface1 src “” dst

# The default policy is DROP. You can be more polite with REJECT.
# Prefer to be polite on your own clients to prevent timeouts.
policy drop

# If you don’t trust the clients behind eth0 (net “”),
# add something like this.
# > protection strong

# Here are the services listening on eth0.
# TODO: Normally, you will have to remove those not needed.
server https accept
server ICMP accept
server ident accept
server ssh accept
server sunrpc accept

# The following eth0 server ports are not known by FireHOL:
# tcp/2222 tcp/44854 tcp/6998 udp/59836 udp/939
# TODO: If you need any of them, you should define new services.
# (see Adding Services at the web site –

# The following means that this machine can REQUEST anything via eth0.
# TODO: On production servers, avoid this and allow only the
# client services you really need.
client all accept

# The above 2 interfaces were found active at this moment.
# Add more interfaces that can potentially be activated in the future.
# FireHOL will not complain if you setup a firewall on an interface that is
# not active when you activate the firewall.
# If you don’t setup an interface, FireHOL will drop all traffic from or to
# this interface, if and when it becomes available.
# Also, if an interface name dynamically changes (i.e. ppp0 may become ppp1)
# you can use the plus (+) character to match all of them (i.e. ppp+).

# No router statements have been produced, because your server
# is not configured for forwarding traffic.

This output is the best you can get. Sometimes (especially when you have more NICs or you run in bit more complicated environment you can also get seconf interface (even hough it is assigned the same IP and is the same eth device) with ${UNROUTABLE_IPS} option. This option is to avoid routing to IANA reserved adress space. As in my config these all options are irrelevant I can stick to just one interface (as the setup is not intendet to route anything anywhere). After stripping the unnecessary comments and removind the src and dst parameter (which will only mean I have no trusted and untrusted network and everyone is untrusted). I will end up with the following config.

interface eth0 Netowrk_access

# default is DROP,polite is REJECT (no timeouts).
policy reject

protection strong

# Here are the services listening on eth0.
server https accept
server ICMP accept
#server ident accept
server ssh accept
#server sunrpc accept
# The following eth0 server ports are not known by FireHOL:
# tcp/2222 tcp/57004 udp/56542 udp/766

# The following means that this machine can REQUEST anything via eth0.
client all accept

Now you can notice that FireHOL was able to locate some services but was unable to create rules for them (as for myalternate port for ssh 2222). So how you add them. You have to define every single service on the begining of the conf file. I will use my fawourite rtorrent as an example.

#new service definition

Adding service is very straight-forward as you can see above – just defina name,protocol, server port range and client ports. If you need this  explained in detail have a look at this FireHOL page.

The last thing that can be bit confusing is the server/client explanation. Server stands for any service running and accepting connections on certain ports (e.g. http:80). Whereas client is a term for connections started from the box itself therefore using “any” is definitely a good idea unless you have defined all source ports for any service you would like to use.

There is one more security tweak I found somewhere on the internet

policy drop
protection strong 10/sec 10

This 10/sec 10 option is not explained anywhere I loked but my guess is that this is some sort of packet/timer ratio. Anyway it has amazing results.

So after finishing the config just issue “firehol try” and if everything seems to work (especially ssh) just type in “commit” and basic securing of the server is done.

And what will be the result? Beneath is nMap scan of a server that is not running firehol and under that the same server running it.

Without FireHOL (nMap – no parameters)

Not shown: 1695 closed ports
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
143/tcp open imap
179/tcp filtered bgp
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
993/tcp open imaps
1720/tcp filtered H.323/Q.931
1723/tcp filtered pptp
1935/tcp open rtmp
8080/tcp open http-proxy
8443/tcp open https-alt
9999/tcp open abyss

And with FireHOL (nMap -A -v)

21/tcp open ftp ProFTPD 1.3.1
25/tcp open smtp Postfix smtpd
80/tcp open http Apache httpd
993/tcp open ssl/imap Dovecot imapd

S you can see the results most of the services are hidden to common scan. Hope this will help to secure your stations.

Screen and rTorrent

tuxAfter some serious stuff about networking there is going to be a small article about some useful Linux thingies.

First of all small reminder about programmes and background processes.  If you want to run programme in background there is a very easy way how to do it. Just add & sign after the command. Like in this example with top.

tnk@charon:~$ top &
[1] 7440

[1]+ Stopped top

If you then need to return to this programme (i.e. run it in active shell again) you have to use the job number (in this case signed as [1]) as an argument for fg utility. If you don’t remember the job number just run “jobs” command for the list.

tnk@charon:~$ fg 1

After displaying the name of the job it will re-enter the programme. But there is one small problem. Quite big number of programmes (like the one used as an example) will stop working after being put to background and this is where screen utility comes to play. This utility will enable you to “detach” the running application so it will run in background and even after you log off. Which provides nice possibilities of running some apps remotely.

So how to use screen – it is quite easy. For running an application you want to run at the background just type the following (I am using top as an example).

tnk@charon:~$ screen  top

That’s all.  Now your application is running and you can work with it as you wish until the time will come to put it into the background when you have to press ctrl+a+d After that you will see following output.

tnk@charon:~$ screen top

Which will say to you that the app is running successfully in the background. OK that’s what we wanted. Now you can do whatever you want until the time will came to return to the app. Then you just hit the following command

tnk@charon:~$ screen -r

If you were running just one programme you will return immediately. If you put more to the background using screen the fallowing output will be shown.

tnk@charon:~$ screen -r
There are several suitable screens on:
7444.pts-0.charon (04/05/2009 11:59:38 PM) (Detached)
7327.pts-0.charon (04/05/2009 09:59:27 PM) (Detached)
Type “screen [-d] -r [pid.]” to resume one of them.

So it is obvious what you have to do you have to select the right one. Unfortunately I did not find any way how to identify the processes except for the time and date. So the command will look like this :

tnk@charon:~$ screen -r 7444.pts-0.charon

Update: There is a simple way how to change the the session name so you can get oriented in your detached sessions. The syntax is as in following example using -S parameter is for naming the sessions. So -S top names the session as top and then just type in the program name. The actual commands are below.

tnk@charon:~$ screen -S rtorrent rtorrent
tnk@charon:~$ screen -S top top

Now you have your detached sessions running and named so you can list them again with the same command as before but you will see the difference.

tnk@charon:~$ screen -r
There are several suitable screens on: (04/06/2009 04:00:00 PM) (Detached)
8763.rtorrent (04/06/2009 03:59:47 PM) (Detached)
Type “screen [-d] -r [pid.]” to resume one of them.

So for return to the right session just use the adequate command

tnk@charon:~$ screen -r 8763.rtorrent



This being said I’d like to proceed to why  did I bother to do all this.
And the answer is rTorrent – the cli BitTorrent client for Linux.

This client is one of the best in my opinion as I like light-weight functional stuff with rather simple user interface. If you know and like uTorrent from windows this client will be almost as good but not like uTorrent this can be run from bash.

So how to run rTorrent. Just download your favourite torrent and run command

tnk@charon:~$ rtorrent whatever_your_torent_is.torrent

This will add the torrent into the queue and open the main “window” of the app. There are few controls you would like to change/use.

main operations:
ctr+q                   exits the app
ctr+q ctr+q      forces the app to exit
ctrl+d                 on active torrent will stop the activity on it
ctrl+d ctrl+d   on active torrent will remove the torrent from queue
<enter>             adds new torrent – you can use for path completion

Speed throttling
asd/ASD            adds 1,5,10 KB to the limit in up/down direction
zxc/ZXC            removes 1,5,10 KB from the limit in up/down direction

for details and queue browsing use arrow keys
right arrow torrents details
left arrow main screen

These are just the basic controls but what makes the rTorrent such a powerful client is that it can be configured in way you are used to from clients like Azureus or uTorrent but in text file. What all you can set read on the developer’s pages (where is also a sample of the config so you do not need to reinvent the wheel)  or here. But things like scheduled check for new torrents in selected directories, port settings or various limits are there.

There is one minor warning the current version of rTorrent which is included in Debian Lenny is not supporting DHT. So you have to leave this part of rTorrent’s config commented.

So screen together with rTorrent is quite powerful and handy combination for downloads on a remote machines. If there will be some reason I will write more about this topic.

As a last thing I’d like to mention is that all these programmes are in standard Debian Lenny distribution so no need for compiling or packaging.

Update: Just recently I have found that very extensive article about this topic is on arch-linux wiki so if you are interested in more options look there

Mysql and utf8

mysql_logoAs time passed I encountered an very strange behaviour of phomyadmin – all tables were created in Swedish language by default which is not very useful when all your application are written to use utf8. I made some digging around the web and found following information

  1. My first thoughts were that the problem with misinterpreted characters in phpmyadmin were only problem of the web-interface setting (but even after several dozens minutes of playing with this I had no results)
  2. So after this fruitless operation I realized there is something wrong with the underlying layer – with the mysql itself. So the next step was to check up on the database. The only valid thing I was able to get from the mysql docs was a command ” SET NAMES” which does a small miracle it sets everything client, server etc. to communicate in whatever charset you want, BUT it is temporary. Whenever you restart your mysqld this setting is gone and the one from /etc/mysql/ is loaded again.
  3. So my step number three was to edit directly (actually I did that at the beginning but it was not working due to my misconfiguration). After editing the I was actually able to set all the new databases and client communications to utf8.

And how this miraculous piece of code looks like ?





As far as I know this is the only solution and it is not mentioned anywhere on the web. The only useful link I did find and is also very close to the truth is this site about utf8 in mysql and php connection to it. You can find there more detailed information about this stuff.