Year: 2004

Entenent l’opció -d del tcpdump

Reading time: 2 – 3 minutes

[ Original ] Segons el man el tcpdump -d diu:

-d Dump the compiled packet-matching code in a human readable form to standard output and stop.

Imagineu-vos que volem veure els paquets que venen de 162.129.225.192 tan del tipus TCP com UDP. L’ordre tcp per fer això seria la que escric a continuació i a més gràcies a l’article citat, us descrit la interpretació del BPF filter (codi que genera el tcpdump per aplicar el que li hem demanat a la comanda).

# tcpdump -d src host centernet.jhuccp.org and \( ip proto \\tcp or \\udp \)
(000) ldh [12]
(001) jeq #0x800 jt 2 jf 8
(002) ld [26]
(003) jeq #0xa281e1c0 jt 4 jf 8
(004) ldb [23]
(005) jeq #0x6 jt 7 jf 6
(006) jeq #0x11 jt 7 jf 8
(007) ret #96
(008) ret #0

Interpretació del codi:

Carreguem els 2 bytes de més pes (big-endian) amb un offset de 12 bytes des de l’inici del paquet. En un paquet de tipus ethernet això correspont al camp de la capçalera on s’indica el tipus i la mida. Un cop tenim aquests bytes els comparem amb 0x0800, que és el codi dels paquets de tipus IPv4. Si és igual saltem a la instrucció 8, que retorna 0 ( reject this packet ).

Seguidament carreguem els 4 bytes de més pes amb un offset de 26bytes des de l’inici del paquet IPv4 en sobre ethernet, aquests 4 bytes corresponen a la IP origien i després els comparem amb 0xa281e1c0 (o sigui, 162.129.225.192). Si no és igual, saltem a la instrucció 8 ( reject this packet).

Ara carreguem 1 byte amb un offset de 23 bytes des de l’origen del paquet, el qual correspon al tipus de transport que conté el paquet IPv4. Si aquest byte és igual a 6 és un paquet TCP, si és igual a 7 saltem a la instrucció 7, la qual retorna 96, que vol dir accepta aquest paquet i agafa els primers 96bytes (accept this packet ang get its first 96 bytes). Si no és igual a 6, fem la mateixa comprobació que no sigui igual a 17, que correspon al codi de transport UDP.

El que he comentat en aquest post, que consti que no ho he deduït jo, sinó que ho he tret de la font citada. Però per la gent que treballa amb xarxes i entorns Linux, com jo, pot ser molt interessant així que aquí queda per si pot ajudar a algú.

Netwox – eines de xarxa

Reading time: < 1 minute

[ Via Caballe.com ] Netwox és una col·lecció d’eines (més de 150) per detectar i solucionar problemes de xarxa. Per exemple: sniffers, generadors de paquets, clients i servidors de diferents protocols, detecció de configuracions, PINGs (TCP, ICMP, UDP, ARP) i traceroute, escanejadors, eines SNMP. Disponible per Linux, Mac OS X, OpenBSD, Solaris i Windows. Si voleu veure un screenshot.

Doing things periodically – Using CRON

Reading time: 5 – 8 minutes

Em vaig trobar un article sobre una eina molt bàsica per tots els que usem Linux, el crontab, una eina que tothom es pensa que domina i sovint ens trobem que no sabem programar algunes tasques que són ben fàcils d’automatitzar. Adjunto aquest article des de migraineheartache. M’agrada l’article perquè no és llarg i és molt pràctic. O sigui, que malgrat estar en anglès crec que és molt útil com a eina de consulta o d’instroducció/formació sobre aquest tema.

On a UNIX system there is always some things that should be done periodically, for example backups, locatedb updates and such things. This makes life easier, as you don’t have to keep all the things you should do in your head, or on silly little notes on your desk. Not to mention the fact that you don’t want to sit up all night doing backups.

The CRON daemon

The nice program that makes this possible is the cron daemon. It runs all the time the system is up and every minute it wakes up to see if there is something that should be done. If there is, it spawns a shell that executes some command. I’ll describe the most used cron package on Linux systems, Vixie Cron. Check out http://www.vix.com for some more interesting software.

Crontab’s

To instruct the crond when to do what, you use crontabs. Like many other programs, cron has a system and a per user crontab. They both have a similar format, with some small differences. What you do in the crontab is to give the minute, hour, day of month and/or day of week a specific command should be run.

The system crontab

The system wide crontab is most often called /etc/crontab. This file should have only important jobs, the file is only writable by root. Mine looks something like this:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file.
# This file also has a username field, that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/etc/ppp
# m h dom mon dow user command
44 5 * * * root run-parts /etc/cron.daily
07 5 * * 7 root run-parts /etc/cron.weekly
00 5 1 * * root run-parts /etc/cron.monthly

As you can see, there is seven fields with information. They are, in correct order: minute, hour, day-of-month, month, day-of-week, user and command. Some of the fields contain stars (*) which means any value will fit. The first line of my file tells cron that every day (the fields day-of-month, month and day-of-week have stars, so cron doesn’t care about them) at 05:44 in the morning I want the command “run-parts /etc/cron.daily” to be run. The command run-parts checks a directory for files that are executable by the user specified in the user field. It runs all of them, in some kind of order 🙂 This is a good way of getting a lot of small things done without writing a big script. Makes it a lot easier maintaining the jobs. My /etc/cron.daily have the following files:

calendar* standard* sysklogd* find* man* netbase* smail* tetex-bin*

So every morning at 05:44 my computer starts doing things like rotating my logs, updating the manual index files, updating the updatedb database and other things that is quite good if you do once a day. At 05:44 I usually don’t use my computer anyway (I do actually sleep sometimes ! 😉 ) so these jobs don’t use any CPU – time I could need. The other lines work just as the first, executing things every week and every month. There is a user field, if you put another user than root there, it will run the command with other rights than root. That is often recommendable by security reasons.

The per – user crontab

Every user on the system may write his own crontab. The job will be executed even though the user is not logged on. The format is similar to the system crontab, though there is not user field, since a user’s cron commands will always be executed as that user. My personal crontab looks like this:

    10 5 * * 0 futility tool "+delete" "keep+1300" ; futility pack
    5 3 * * * /home/erik/bin/mirroring
    15 0-23/1 * * * /usr/bin/fscan

As you can see, it has three jobs. The first one goes every Sunday (Day of week field has the value 0, which is Sunday. I could write ‘Sun’ there too) and does some packing of my fidonet message base. The second goes every day at 5 minutes past 3 in the morning and mirrors some ftp archives. The third executes 5 minutes past every hour 24 hours a day. The syntax 0-23/1 tells cron it should do it once an hour from hour 0 to hour 23. 0-14/2 would mean twice an hour from 00:00 to 14:00 in the afternoon.

The crontab command

When a user wants his own crontab, he has to install it. This is done with the command crontab. The syntax is quite simple, crontab name-of-crontab will install the file you specified as your new crontab. The command crontab has some other switches, to list, edit or remove crontabs, but the basic syntax is actually all you need to know – If you want to edit you crontab, do so and reinstall it with a new crontab command.

Environment variables and file rights.

There are a few things one should think of when trying to master cron. First cron doesn’t read your login files to set the path you’re used to, so a command that executes just fine when you test it may not run at all because cron can’t find some file. There are two solutions to this problem, the first is to use only absolute filenames (ie give the whole path to the files), the second to include something like this:

    PATH = /usr/local/bin:/home/foo/bar

That way you set the environment variable PATH, so your scripts will find the files. Another environment variable of interest is MAILTO. If you set that variable (the same way as you set PATH) cron will mail the output of your commands to the address specified. Cron will by default mail the output to the user the crontab belongs to, but if you want the mail to go somewhere else you may specify it in the variable. You may also give an empty MAILTO variable (by writing “MAILTO=” in your crontab). Cron won’t mail any mails to an empty address. File rights can sometimes be a problem. If cron doesn’t want to execute your scripts or programs, try giving the group or world execution rights to the file. That may solve the problem. The irritating thing is cron won’t tell you it can’t execute, it just sits there doing nothing.

dir2ogg de MP3,MP4 i WAV a OGG

Reading time: < 1 minute

dir2ogg: Un script fet en python que ens permet convertir formats d’audio de: MP3, M4A, i WAV a OGG. És important destacar que manté els ID3 tags que puguin tenir els fitxers. Requereix oggenc (part of the vorbis-tools package) i mpg123 (or mpg321 with the appropriate symlink).