..:: seize the day ::..

Bagian ini adalah bagian terakhir dari penjelasan traffic shaping. Kita akan mendiskusikan sedikit mengenai ingress qdisc. Traffic shaping yang kita bicarakan pada dua tulisan sebelumnya merupakan implementasi egress qdisc, dimana kita men-shape traffic yang meninggalkan eth1 (trafik upload). Untuk trafik yang menuju eth1 (trafik incoming) kita menerapkan ingress qdisc (lihat diagram dari jengelh untuk mendapatkan gambaran mengenai ingress dan egress). Untuk trafik incoming kita tidak dapat melakukan shaping, tetapi yang kita lakukan adalah membuat policy, implementasi di tc adalah police. Yang akan kita lakukan adalah membuat policy untuk melambatkan trafik yang masuk agar tidak terjadi kongesti di server kita.

Perhatikan bagian:

        # attach ingress policer;
        # ngelambatin download sedikit
        tc qdisc add dev eth1 handle ffff: ingress

        # lambatin semua paket yang datang terlalu cepat
        tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src \
           0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

Arti dari baris tc qdisc add dev eth1 handle ffff: ingress adalah meng-attach ingress qdisc pada eth 1 dengan nama handle ffff: . Hal ini sama halnya dengan ketika mengattach egress qdisc dan membuat root class untuk trafik upload, hanya ingress qdisc berfungsi untuk klasifikasi trafik download.

Selanjutnya pada baris berikutnya ada u32 classifier, yang merupakan salah satu filter classifier yang sangat powerful dalam implementasi tc. u32 akan memfilter paket berdasarkan field dari paket ip (source ip address) yang dianalisa adalah 32 bit header dari paket. Apabila ada kondisi yang sesuai (match) dengan selector maka suatu tindakan (action) akan dilakukan. u32 selector berisi definisi yang akan ditemui pada suatu paket yang sedang diproses berupa informasi bit mana yang harus match di dalam header paket. Metode sederhana ini ternyata sangat powerful.

Dalam script di atas ada juga hal baru yang ditemui yaitu police dan burst. Police merupakan filter yang membatasi rate bandwidth sampai kecepatan tertentu. Burst atau buffer adalah ukuran dari bucket (HTB = hierarchical tocken bucket, atau kadang-kadang disebut juga TBF = tocken bucket filter) dalam byte (1 byte = 8 bit), sebagai patokan untuk kecepatan 10mbit/s dibutuhkan setidaknya ukuran buffer 10 kbyte.

Maksud dari baris

                    tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src \
                        0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

adalah membuat class ingress dari class ffff: untuk protokol ip dengan prioritas 50 dengan source ip dari internet dengan membatasi  kecepatan paket sebesar kecepatan DOWNLINK kbit/s dengan buffer sebesar 10 kbytes, paket yang kecepatannya lebih dari DOWNLINK akan di drop.

Beberapa Contoh Lain

Kombinasi iptables, ip, tc dapat digunakan untuk beberapa hal lain yang sangat menarik, di bawah ini beberapa contohnya.

Anda mempunyai beberapa koneksi internet ke beberapa ISP. Anda menginginkan agar trafik smtp melalui jalur salah satu ISP saja. Anda dapat mengkombinasi iptables dengan ip. Buat perintah untuk script iptables seperti dibawah ini

# iptables -A PREROUTING -i eth0 -t mangle -p tcp –dport 25 \
    -j MARK –set-mark 1

# echo 201 mail.out >> /etc/iproute2/rt_tables
# ip rule add fwmark 1 table mail.out
# ip rule ls
0: from all lookup local
32764: from all fwmark          1 lookup mail.out
32766: from all lookup main
32767: from all lookup default

Lalu kita jalankan perintah:

#/sbin/ip route add default via 202.172.43.171 dev eth0 table mail.out

Maka semua email trafik akan melalui eth0 di mesin router kita menuju ISP tertentu.

Contoh lain adalah untuk selector u32 classifier, misalnya kita ingin agar trafik ICMP masuk ke qdisc tertentu kita dapat membuat misalnya:

# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip protocol 1 0xFF flowid 10:100

Mudah-mudahan penjelasan singkat ini bisa dipahami, dan jangan takut untuk mencoba-coba sendiri. Apa yang saya coba share di sini memang masih kurang lengkap tapi setidaknya bisa menjadi awal bagi anda yang tertarik network dan quality of service di linux.

Have a lot of fun.

Pada bagian ini kita akan mendiskusikan bagaimana mengklasifikasikan paket dan kemudian melakukan penandaan paket (packet marking) berdasarkan TOS field paket di linux kernel. Jadi kita akan menyerahkan klasifikasi paket untuk dilakukan oleh iptables selanjutnya HTB akan melakukan queueing berdasarkan penandaan oleh iptables. Secara singkat TOS (Type of Service, kudu dimengerti oleh pengguna linux yang berminat pada networking dan Quality of Service) merupakan bagian dari paket yang menentukan prioritas dari paket. TOS terdiri dari 8 bit (octet), bit 0, 1, 2 adalah precedence, bit 3, 4, 5, 6 adalah TOS, dan bit 7 adalah bit MBZ (Must Be Zero).

Secara default nilai dari TOS bits adalah sebagai berikut:

• 1000 (binary)      8 (decimal)       Minimize delay (md)
• 0100 (binary)      4 (decimal)       Maximize throughput (mt)
• 0010 (binary)      2 (decimal)       Maximize reliability (mr)
• 0001 (binary)      1 (decimal)       Minimize monetary cost (mmc)
• 0000 (binary)      0 (decimal)       Normal service 

Untuk mengetahui lebih jauh tentang TOS silakan membaca RFC1349 dan RFC2474.

Dengan iptables kita dapat melakukan penandaan paket (packet marking) berdasarkan TOS bits dan inilah yang akan kita lakukan dengan script yang kita buat. Header dari paket akan dibongkar (mangle) oleh iptables dan disisipi tanda (mark) sesuai keinginan kita. (Thanks to Rusty Russel, Harald Welte, Patrick McHardy etc to make iptables as a nice userland for linux communites. Sekitar 2 tahun lalu kebetulan saya pernah kerja bareng dengan salah satu kontributor iptables/netfilter Fabrice Marie, dia salah satu pembuat howto nya netfilter, orangnya sangat down to earth, ramah dan mau berbagi ilmu. Saat itu saya gak tahu kalau dia salah satu kontributornya……..)

Pada script yang saya berikan perhatikan bagian

        tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
        tc filter add dev eth1 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
        tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
        tc filter add dev eth1 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
        tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
        tc filter add dev eth1 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

Pada tulisan sebelumnya kita sudah membuat 6 class htb qdisc tetapi belum melakukan klasifikasi paket, sehingga seluruh paket upload dari network kita akan melalui class 1:15 (kita mendefinisikan tc qdisc add dev eth1 root handle 1: htb default 15). Sekarang kita harus mengklasifikasikan paket agar paket tertentu akan masuk kedalam class htb qdisc tertentu pula. Script di atas adalah filter yang akan membagi paket kedalam class tertentu berdasarkan klasifikasi paket oleh iptables. Penggunaan iptables sangat dianjurkan karena sangat fleksibel, menghitung paket untuk setiap rule dengan cepat, dan juga dengan adanya RETURN target paket tidak perlu menjelajah ke semua rule.

Perintah yang dilakukan pada script di atas adalah memberitahu kernel bahwa paket dengan nilai spesifik FWMARK (handle x fw) harus masuk ke class tertentu (classid x:xy). 

Bagi anda yang belum memahami cara kerja iptables silakan download howtonya di sini, atau setidaknya pahami diagram dari Jan Engelhardt (jengelh adalah pengguna openSUSE, dia salah satu kontributor di openSUSE Build Service. rt-kernel dari dia dipakai untuk Jacklab Audio Distribution).

Misalkan ip lokal anda 192.168.0.0/24 dan ip public anda 202.170.1.2, maka jalankan NAT dengan iptables (untuk pengguna SuSEfirewall tidak perlu menjalankan perintah iptables ini, tetapi ikuti langkah untuk SuSEfirewall di paragraf berikutnya. Saya pengguna SuSEfirewall juga).

•  ech0 1 > /proc/sys/net/ipv4/ip_forward
•  iptables - t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o eth1 -j SNAT –to-source 202.170.1.2

FW_DEV_EXT=’eth1′       ——> sesuaikan dengan eth ip publik
FW_DEV_INT=’eth2′        ——> sesuaikan dengan eth ip lokal
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="zone:ext"
FW_MASQ_NETS="192.168.0.0/24"
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"

Kemudian mulailah menambahkan rule untuk PREROUTING chain pada tabel mangle:

iptables -t mangle -A PREROUTING -p icmp -j MARK –set-mark 0x1
iptables -t mangle -A PREROUTING -p icmp -j RETURN

iptables -t mangle -A PREROUTING -m tos –tos Minimize-Delay -j MARK –set-mark 0x1
iptables -t mangle -A PREROUTING -m tos –tos Minimize-Delay -j RETURN

iptables -t mangle -A PREROUTING -m tos –tos Minimize-Cost -j MARK –set-mark 0x5
iptables -t mangle -A PREROUTING -m tos –tos Minimize-Cost -j RETURN

iptables -t mangle -A PREROUTING -m tos –tos Maximize-Throughput -j MARK –set-mark 0x6
iptables -t mangle -A PREROUTING -m tos –tos Maximize-Throughput -j RETURN

iptables -t mangle -A PREROUTING -p tcp -m tcp –sport 22 -j MARK –set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp –sport 22 -j RETURN

iptables -t mangle -A PREROUTING -p tcp -m tcp –dport 22 -j MARK –set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m tcp –dport 22 -j RETURN

iptables -t mangle -I PREROUTING -p tcp -m tcp –tcp-flags SYN,RST,ACK SYN -j MARK –set-mark 0x1
iptables -t mangle -I PREROUTING -p tcp -m tcp –tcp-flags SYN,RST,ACK SYN -j RETURN

iptables -t mangle -A PREROUTING -p tcp -m tcp –dport 587 -j MARK –set-mark 0x5
iptables -t mangle -A PREROUTING -p tcp -m tcp –dport 587 -j RETURN

iptables -t mangle -A PREROUTING -p tcp -m tcp –dport 993 -j MARK –set-mark 0x5
iptables -t mangle -A PREROUTING -p tcp -m tcp –dport 993 -j RETURN

iptables -t mangle -A PREROUTING -j MARK –set-mark 0x6

1. menandai traffic ICMP dengan FWMARK 0x1
2. -j RETURN untuk trafik ICMP dimana ICMP tidak akan masuk ke rule lain dibawahnya
3. menandai semua trafik TOS minimize delay sebagai FWMARK 0x1
4. -j RETURN untuk trafik TOS minimize delay, dimana trafik TOS minimize delay tidak akan masuk ke rule lain dibawahnya
5. menandai semua trafik TOS minimize cost sebagai FWMARK 0x5
6. -j RETURN untuk trafik TOS minimize cost, dimana trafik TOS minimize cost tidak akan masuk ke rule lain dibawahnya
7. menandai semua trafik TOS maximize throughput sebagai FWMARK 0x6
8. -j RETURN untuk trafik TOS maximize throughput, dimana trafik TOS maximize throughput tidak akan masuk ke rule lain dibawahnya
9. menandai trafik yang berasal dari port SSH dengan FWMARK  0x1
10. -j RETURN untuk trafik yang berasal dari port SSH dimana trafik yang berasal dari port SSH tidak akan masuk ke rule lain dibawahnya
11. menandai trafik yang menuju port SSH dengan FWMARK  0x1
12. -j RETURN untuk trafik yang menuju port SSH dimana trafik yang menuju port SSH tidak akan masuk ke rule lain dibawahnya
13. menandai trafik yang memiliki SYN flag dengan FWMARK  0x1
14. -j RETURN untuk trafik yang memilik SYN flag dimana trafik yang memiliki SYN flag tidak akan masuk ke rule lain dibawahnya
15. menandai trafik yang menuju port 587 dengan FWMARK 0x5
16. -j RETURN untuk trafik yang menuju port 587 dimana trafik yang menuju port 587 tidak akan masuk ke rule lain dibawahnya
17. menandai trafik yang menuju port 993 dengan FWMARK 0x5
18. -j RETURN untuk trafik yang menuju port 993 dimana trafik yang menuju port 993 tidak akan masuk ke rule lain dibawahnya
19. trafik yang tidak termasuk dalam klasifikasi sebelumnya akan ditandai dengan FWMARK 0x6 dan akan masuk ke class 1:15

Kemudian lakukan hal yang sama untuk OUTPUT chain. Ulangi script tabel mangle untuk PREROUTING, dan ganti semua kata PREROUTING dengan OUTPUT. Kegunaannya adalah agar semua trafik yang dihasilkan secara lokal di server tempat script ini terletak juga akan diklasifikasi. Tetapi bagian paling akhir dari script diganti dengan: iptables -t mangle -A OUTPUT -j MARK –set-mark 0x3. Hal ini membuat lokal trafik akan mempunyai prioritas lebih tinggi dan akan masuk ke class 1:12.

Masukan script OUTPUT chain dan PREROUTING chain dalam iptables script yang selama ini anda gunakan. Untuk pengguna SuSEfirewall, edit file /etc/sysconfig/scripts/SuSEfirewall2-custom, dan masukkan script tersebut pada bagian before antispoofing seperti dibawah ini

      fw_custom_before_antispoofing(){

            iptables -t mangle -A PREROUTING -p icmp -j MARK –set-mark 0x1
            iptables -t mangle -A PREROUTING -p icmp -j RETURN
            …….. dan seterusnya
            iptables -t mangle -A PREROUTING -j MARK –set-mark 0x6

            iptables -t mangle -A  OUTPUT -p icmp -j MARK –set-mark 0x1
            iptables -t mangle -A OUTPUT -p icmp -j RETURN
            …….. dan seterusnya
            iptables -t mangle -A OUTPUT -j MARK –set-mark 0x3

        true
        }

Jalankan script yang saya berikan dan restart SuSEfirewall atau iptables, dan coba jalankan perintah :

       tc -s class show dev eth1

Sekarang perhatikan bahwa jumlah paket akan meningkat di setiap class. Jika ada class yang kosong berarti anda musti mengatur ulang priority atau FWMARK yang diberikan, karena hal ini berbeda disetiap network tergantung dari karakteristik pengunaan network oleh user. Selain itu sekiranya ada class yang penuh terus, maka perlu ditambahkan queuing dicipline lain supaya pembagian bandwidth lebih fair. Hal ini dilakukan dengan sfq (stochastic fairness queueing). Pada contoh script saya tambahkan class sebagai berikut:

        tc qdisc add dev eth1 parent 1:12 handle 120: sfq perturb 10
        tc qdisc add dev eth1 parent 1:13 handle 130: sfq perturb 10
        tc qdisc add dev eth1 parent 1:14 handle 140: sfq perturb 10
        tc qdisc add dev eth1 parent 1:15 handle 150: sfq perturb 10

Maksudnya adalah menambahkan queueing disc sfq pada class 1:12 (dan seterusnya) dengan nama handle 120 (dan seterusnya) dengan hashing dilakukan setiap 10 detik. SFQ akan mengatur bandwidth dibagi secara fair untuk setiap paket trafik. Untuk kasus di tempat anda mungkin berbeda tetapi script ini dapat dijadikan dasar untuk anda mengkonfigurasi di network anda.

Mudah-mudahan penjelasan singkat ini bisa dimengerti.  Pada tulisan berikutnya akan saya jelaskan bagian script yang lain.

Pertanyaan paling mendasar adalah mengapa perlu pengaturan trafik atau traffic shaping?

1. Anda pakai speedy office di rumah anda untuk 3 komputer. Anda tidak butuh traffic shapping.
2. Anda pakai fastnet 384 kbps di rumah untuk 3 komputer. Anda tidak butuh traffic shapping.
3. Kalau user anda sedikit dan bandwidth anda besar, katakan user anda 100, bandwidth anda 8 Mbps symmetris, anda sepertinya gak butuh traffic shaping (debatable juga sih apalagi kalau dipakai voip atau video conference).
4. Kalau user anda hanya 1 sampai 5 orang bisa dikatakan anda tidak perlu traffic shaping, karena bandwidth anda masih memadai untuk melayani user anda. Tapi bagaimana kalau user anda lebih dari 15 orang dan masing-masing melakukan koneksi remote ssh, selain tentunya browsing dan download. Bisa dikatakan anda akan mengalami masalah, kalau anda tidak men-shape trafik upload dan membuat policy untuk downlink anda. Saya mengalaminya sendiri dengan sekitar 60 user yang haus bandwidth.
5. Menjaga low latency untuk trafik interaktif. Artinya proses download dan upload harus tidak mengganggu SSH, telnet dan sejenisnya. Hal ini yang paling penting. Dengan latency 200ms cukup membuat bekerja dengan SSH sangat tidak nyaman.
6. Menjaga agar user dapat tetap membrowse internet dengan kecepatan yang nyaman sementara melakukan proses upload atau download.
7. Memastikan bahwa proses upload tidak mengorbankan proses download dan sebaliknya. Perlu dipahami bahwa adanya queue yang besar di device seperti modem ADSL atau kabel modem akan membuat upload, download dan trafik interaktif akan saling bertanding satu sama lain.

Pada tulisan saya sebelumnya, saya sudah memberikan script untuk melakukan traffic shaping di openSUSE (well, juga untuk distribusi linux lain). Sekarang saya akan menjelaskan apa maksud dari script tersebut. Ketika dulu pertama kali mempelajari tc, ip, dan HTB saya menyadari bahwa hal inilah yang paling susah.

#
#
# /etc/init.d/mebwshaper_eth1
#
### BEGIN INIT INFO
# Provides:          mebwshaper_eth1
# Required-Start:    $network
# Should-Start:
# Required-Stop:
# Should-Stop:
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: Custom bandwidth shaping by medwinz@gmail.com
# Description:       Custom bandwidth shaping by medwinz@gmail.com
### END INIT INFO
#

test -s /etc/rc.status && . /etc/rc.status && rc_reset

case "$1" in
start )
        # script bandwidth shaping for openSUSE by medwinz@gmail.com
        # silakan dicopy atau diubah-ubah
        #

        echo -n "Starting bandwidth shaping HTB qdiscs in eth1"

        DOWNLINK=968
        UPLINK=110

        # hapus existing downlink and uplink qdiscs, umpetin errors
        tc qdisc del dev eth1 root    2> /dev/null > /dev/null
        sleep 2
        tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
        sleep 1

        # ngebuat qdisc
        tc qdisc add dev eth1 root handle 1: htb default 15
        tc class add dev eth1 parent 1: classid 1:1 htb rate ${UPLINK}kbit ceil ${UPLINK}kbit
        tc class add dev eth1 parent 1:1 classid 1:10 htb rate 36kbit ceil 36kbit prio 0
        tc class add dev eth1 parent 1:1 classid 1:11 htb rate 36kbit ceil ${UPLINK}kbit prio 1
        tc class add dev eth1 parent 1:1 classid 1:12 htb rate 9kbit ceil ${UPLINK}kbit prio 2
        tc class add dev eth1 parent 1:1 classid 1:13 htb rate 9kbit ceil ${UPLINK}kbit prio 2
        tc class add dev eth1 parent 1:1 classid 1:14 htb rate 11kbit ceil ${UPLINK}kbit prio 3
        tc class add dev eth1 parent 1:1 classid 1:15 htb rate 9kbit ceil ${UPLINK}kbit prio 3
        tc qdisc add dev eth1 parent 1:12 handle 120: sfq perturb 10
        tc qdisc add dev eth1 parent 1:13 handle 130: sfq perturb 10
        tc qdisc add dev eth1 parent 1:14 handle 140: sfq perturb 10
        tc qdisc add dev eth1 parent 1:15 handle 150: sfq perturb 10

        tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
        tc filter add dev eth1 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
        tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
        tc filter add dev eth1 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
        tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
        tc filter add dev eth1 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

        # attach ingress policer;
        # ngelambatin download sedikit
        tc qdisc add dev eth1 handle ffff: ingress

        # lambatin semua paket yang datang terlalu cepat
        tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src \
           0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

        rc_status -v
        ;;

stop)
        # hapus existing downlink and uplink qdiscs, umpetin errors

        echo -n "Delete all HTB qdiscs on eth1"

        tc qdisc del dev eth1 root    2> /dev/null > /dev/null
        sleep 3
        tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
        sleep 2
        rc_status -v
        ;;

restart)
        ## Berhentiin service dan tanpa perduli dia jalan atau nggak
        ## Start lagi.
        $0 stop
        $0 start

        # inget status dan tenang aja
        rc_status
        ;;

    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
        ;;

esac
rc_exit

Maksud dari script diatas akan saya coba jelaskan dalam tulisan sederhana ini.

Penjelasan

             DOWNLINK=968       

Ini adalah kecepatan download. ISP mengatakan 1024 kbps, tapi saya kecilkan menjadi sekitar 94% saja. Hal ini perlu agar tidak terjadi kongesti.

             UPLINK=110

Demikian pula dengan upload. ISP menyatakan sebesar 128 kbps, tapi  hanya 86% yang saya alokasikan.

Anda harus mencari dengan trial and error sampai didapatkan angka maksimum untuk DOWNLINK dan UPLINK dimana traffic tidak menyebabkan kongesti pada sambungan ADSL anda. Perlu untuk diketahui bahwa ISP menerapkan queueing pada banyak sekali server mereka, kita tidak dapat mengkontrol queueing di sisi ISP. Karena itu tujuan utama dari traffic shapping ini adalah memindahkan queueing pada server kita agar kita bisa mengaturnya. Sehingga traffic yang mencapai ISP tidak di queuing lagi oleh ISP (idealnya seperti itu). Pada setting di tempat saya, saya menggunakan angka UPLINK 110 kbit/s. Angka ini adalah angka maksimum sebelum latency mulai meningkat (walaupun Speedy mengatakan uploadnya 128 kbit/s) yang disebabkan mulai penuhnya buffer pada router atau modem (whatever..) antara server saya dengan remote host.

        tc qdisc del dev eth1 root    2> /dev/null > /dev/null
        sleep 2

Baris di atas merupakan perintah tc untuk menghapus semua root qdisc downlink yang mungkin ada sebelumnya di device eth1, selanjutnya menunggu selama 2 detik. 

        tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
        sleep 1

Baris ini merupakan perintah tc untuk menghapus semua ingress qdisc uplink yang mungkin ada sebelumnya di device eth1, selanjutnya menunggu selama 1 detik. Baris-baris berikutnya adalah inti dari script ini yaitu membuat beberapa qdisc baru untuk mengatur trafik upload,

        tc qdisc add dev eth1 root handle 1: htb default 15
        tc class add dev eth1 parent 1: classid 1:1 htb rate ${UPLINK}kbit ceil ${UPLINK}kbit
        tc class add dev eth1 parent 1:1 classid 1:10 htb rate 36kbit ceil 36kbit prio 0
        tc class add dev eth1 parent 1:1 classid 1:11 htb rate 36kbit ceil ${UPLINK}kbit prio 1
        tc class add dev eth1 parent 1:1 classid 1:12 htb rate 9kbit ceil ${UPLINK}kbit prio 2
        tc class add dev eth1 parent 1:1 classid 1:13 htb rate 9kbit ceil ${UPLINK}kbit prio 2
        tc class add dev eth1 parent 1:1 classid 1:14 htb rate 11kbit ceil ${UPLINK}kbit prio 3
        tc class add dev eth1 parent 1:1 classid 1:15 htb rate 9kbit ceil ${UPLINK}kbit prio 3

Hal di atas adalah membuat beberapa qdisc dimana trafik akan diklasifikasikan. ada 6 htb qdisc yang dibuat dengan prioritas tertinggi pada class 1:10 dan terendah pada class 1:15. Secara default semua trafik akan masuk ke class 1:15 ( tc qdisc add dev eth1 root handle 1: htb default 15). Maksud dari baris-baris di atas adalah membagi root class 1: upload menjadi 6 class 1:10, 1:11, 1:12, 1:13, 1:14 dan 1:15 dengan rate minimal masing-masing 36 kbit, 36 kbit, 9 kbit, 9 kbit, 11 kbit dan 9 kbit. Setiap class dapat menggunakan bandwidth yang tidak terpakai oleh class lainnya. Class dengan priority yang lebih tinggi (prio 1 prioritasnya lebih tinggi dari prio 3) akan mendapatkan alokasi bandwidth lebih dulu.

classid 1:10 htb rate 36kbit ceil 36kbit prio 0

Ini adalah class dengan prioritas tertinggi. Paket dalam class ini akan memiliki delay terkecil dan akan mendapatkan excess bandwidth pertama kali, sehingga saya membatasinya sampai angka 36 kbit/s. Paket yang akan dikirimkan melalui class ini adalah paket yang membutuhkan delay yang kecil, seperti trafik interaktif yaitu: ssh, telnet, dns, irc, dan paket dengan SYN flag.

 classid 1:11 htb rate 36kbit ceil ${UPLINK}kbit prio 1

Kelas ini adalah kelas pertama dimana sebagian besar trafik (bulk traffic) akan diletakkan. Trafik di sini sebagian besar adalah web trafik dari lokal web server (web server di mesin lokal) serta trafik web keluar: source port 80 dan destination port 80.

 classid 1:12 htb rate 9kbit ceil ${UPLINK}kbit prio 2

Dalam kelas ini saya letakkan trafik dengan nilai bit TOS Maximize-Throughput dan trafik lain yang berasal dari proses lokal (trafik yang sumbernya dari server) ke internet. Class ini hanya akan berisi trafik yang di-route melalui server (tempat script ini di jalankan).

classid 1:13 htb rate 9kbit ceil ${UPLINK}kbit prio 2

Class ini diperuntukkan bagi trafik untuk mesin-mesin yang di- NAT, yang membutuhkan prioritas bagi trafik bulk-nya.

classid 1:14 htb rate 11kbit ceil ${UPLINK}kbit prio 3

Class ini untuk trafik email (SMTP, POP3, IMAP, dll) serta paket dengan nilai bit TOS Minimize-Cost.

classid 1:15 htb rate 9kbit ceil ${UPLINK}kbit prio 3

Class terakhir ini adalah class default dimana bulk traffic dari mesin-mesin yang di NAT akan dimasukkan. Trafik yang masuk di sini seperti kazaa, edonkey, dan yang sejenisnya.

Penjelasan singkat ini silakan dicerna dulu. Dibaca, dimengerti dan dibawa mimpi. Saya akan lanjutkan pada tulisan berikutnya bagaimana menghubungkan script ini dengan iptables.

The title is a bit intriguing. But it is true you can use your linux machine to expand your ability to play your favorite musical instrument. This story is based on my experience. In Windows world you have programs like GuitarPro and PowerTab to make musical transcription for guitar. In Linux there are many alternatives you can use, I should mentioned here KGuitar, DGuitar, and TuxGuitar.

I use TuxGuitar to make transcription, open gp3, gp4 and gp5 files from GuitarPro, and practice my guitar playing with it. The format of file produce by TuxGuitar is .tg. I also use it to export the result to midi files, and try to play it with the midi player for linux,  TiMidity++. TuxGuitar by far is the most advance and complete linux software for guitar player and can be compared with GuitarPro. Sometimes I use DGuitar to open gp3, gp4, gp5 files from my friend. I use DGuitar just to hear the sound.

The other thing I needed to get the decent sound for TuxGuitar is FluidSynth and its GUI wrapper Qsynth. FluidSynth is a command line software synthesiser based on the soundfont specification, and Qsynth is a fluidsynth GUI front-end application written in C++ around the Qt4 toolkit using Qt Designer. After Qsynth installation we need several free soundfont that can be download from the web. Of course to be able to hear all the sound, we sholud make sure that the sound card in PC is working, and it supports ALSA.

To make your system a little bit complete you can add TiMidity++ as your midi player. TiMidity++ is a software synthesizer. It can play MIDI files by converting them into PCM waveform data; give it a MIDI data along with digital instrument data files, then it synthesizes them in real-time, and plays. It can not only play sounds, but also can save the generated waveforms into hard disks as various audio file formats.

All the setup above is enough for hobbyist like me, I just play the guitar for hobby and play a gig once in while just for fun. For you who need more (maybe you’re professional) you can add Rosegarden and NoteEdit. Rosegarden is a well-rounded audio and MIDI sequencer, score editor, and general-purpose music composition and editing environment. NoteEdit is a free music score editor for Linux, it supports an unlimited number and length of staffs, polyphony, a MIDI playback of written notes, chord markings, lyrics, a number of import and export filters to many formats like MIDI, MusicXML, ABC Music, MUP, PMX, MusiXTeX and LilyPond and other.

If still not enough, openSUSE, my prefer distribution, go further with the JAD (Jacklab Audio Distribution). It is based on openSUSE 10.2, and apply a special real time kernel. It implements JACK, it can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. JACK is a low-latency audio server, that’s why JAD use the special real time kernel that have low latency. JAD also already include several packages that I mentioned above.

Installation (tested in my openSUSE 11.0 installation) 

In this section I give you step-by-step installation of TuxGuitar for openSUSE11.0, mainly using 1-click install from webpin. Other distribution please search your repositories or use the tarball from the respective website.

1. Make sure your soundcard is working.
2. Install TuxGuitar with 1-click install from webpin. If you want to install it by yourself please download it from here.
3. Install Qsynth with 1-click install from webpin. If you want to build it by yourself please download it from here. If you build it don’t forget to install Qt4 and fluidsynth. This is not the case for 1-click install because it will install the dependencies. After installation click Setup and select Audi Tab, and make sure you select alsa as Audio Driver (you can also Install jack and use jack as Audio Driver)
4. Download SGM-V2.01 soundfont from here (actually I don’t know the license for this soundfont, but because it is on the net I assume it is free. If someone, or you perhaps, know that it is violating the license please drop me an email and I will remove this line). Most of the time this soundfont is enough for me. It maps almost all the midi sount from GuitarPro files correctly. But if you need to experiment a bit you can also download some free soundfons from here. I use FluidR3, StevesLesPaul-R5 and JV1080 from this site. You should load the soundfont to Qsynth from setup - soundfont. You need a tool to extract the SGM-V2.01and FluidR3 .sfark files to be a .sf2 file so it can be readed by Qsytnh. For this task, you can use a windows program from here and run it from wine.
5. As an optional, install TiMidity++ with 1-click install from webpin. 

Try the software

User experience is something that hard to be explained. You should make yourself to get use with the software, before you can say any comment about that. According to my experience there are several thing we should take care

1. Always run the Qsynth before opening TuxGuitar. And set the TuxGuitar sound on Tools-Sound with Midi Sequencer set to TuxGuitar Sequencer and Midi Port set to Synth input port (which Qsynth reside).
2. Most of the time I can play correctly .gp* files with SGM-V2.01 soundfont, but sometimes the musical instrument doesn’t sound correctly. If so, we should do trial and error by assigning the right instrument to the midi channel by setting it in Qsynth  Channels.
3. It is good to check the result of midi with TiMidity++. Export the file you created in TuxGuitar and play it with TiMidity++ and hear the result.

Don’t be afraid to try different sound and experimenting a bit.

OK. That’s all folks. Happy playing with your guitar and do experiment with the TuxGuitar and Qsynth. Have fun.

This post is the final chapter of Disaster Management Project 2007 (anyway there are some interesting story behind the project maybe I should also write a post about that). This post will talk about the implementation of project in Padang (capital city of West Sumatera Province - Indonesia), as well as the testing in Padang and Banda Aceh. Learn from the experience in Banda Aceh, I let the interior contractor do the job first. I don’t want to go there just to wait their work to finish. The provincial government of West Sumatera actually don’t have enough budget to make the room as complete as Banda Aceh. So I know from the beginning that there will be some handicap here and there, but it’s OK for me. We sometimes work like MacGayver so we’re not so worry . We also already sent all the goods to Padang before hands, and all the stuff already arrive one week before.

I went with Darma to Padang on November 30, 2007, two days earlier before Astrium and Infoterra team. In three days all PC and other peripherals are configure, the only problem is that (again, like in Banda Aceh) we should take an internet connection from another building. We put UTP cable around 70 m to get to the switch. For the server we need aproximately one week to configure, check the connection between Padang and Jakarta, and test the RiskFrame application. This time me and Darma are working fast. Meanwhile Hilarion and Karine from Astrium team go to Banda Aceh to install some modification for recorder server. They’re there 3 days and then join with me and Darma in Padang on December 2, 2007.

For you who don’t know where the Padang is, click here to get some info from wikipedia. Also here is the place in Padang where we put all the equipment from google earth.

Padang is located in the west coast of Sumatera, one of active area of ring of fire. When we get there Padang just severe from 6SR earth quake 1 month before, and while we’re there we also get the opportunity to feel  the shake of earth quake. I was configure the server at 2nd floor at that time when a 5 SR earth quake shake the building, we are running out of the building and wait for about 10 minutes outside. We are lucky this earth quake is not long though

The first two days in Padang we are busy unpacking all the PC, server, rack and all the peripherals. We also setup the network, connect the cable to another building to get the internet access. Here are some picture back then,

During this project, it is in Padang where almost all the team member is present. From me and Darma from NSI; Hilarion Raobadia, Patrice Pessah, and Frederick Cathignol and Karine de Ponteves from EADS Astrium; Eric Joe and Marc Boulbess from Infoterra. From Civipol there is B. Neuville who will lead Site Acceptance Test (SAT). Eric Brossouloux from IGN FI will join in Banda Aceh on December 14 - 17, 2007 to follow the final SAT for Banda Aceh site.

There is one change in PABX/Asterisk server - recorder server configuration. In the design we will record all the conversation from Asterisk server to recorder server. We set the time 5 minutes before the recording file will be transfer from PABX server to the recorder. Means that we should wait for 5 minutes before we can playback the conversation from the PC in the center. Civipol ask us to add additional capability to directly access the recording conversation file after the telephone hang up, and they will include it on SAT. Antoher problem we have is the broken of one Digium card. I should ask our office in Jakarta to buy one and send it to Padang immediately. Meanwhile Darma facing no difficulties to configure all the PC, VHF radio, Printer, Satellite Telephone and Satelitte TV.

SAT is running smoothly in Padang. It makes me happy. We’re running out of time because the delay from civil work. In Padang everything is doing in one take, from implementation, testing and site acceptance it takes only 13 days. I’m really proud of it. Here are some pictures of that period (well, you see everybody smile. It is sign of mission accomplished, isn’t it?)

On December 11, 2007 SAT on Padang is finished. Civipol can accept the site. It’s time to move to Banda Aceh. The French team go first to Banda Aceh, actually several hours before me. I should send some tools back to Jakarta, we don’t need that in Banda Aceh. The schedule in Banda Aceh is only for SAT so I don’t need that. Darma go back to Jakarta. He works so hard in the last two weeks, so I decided to let him take the vacation. Then I go to Banda Aceh. 

The flight is delay more than 2 hours. In the ticket it is schedule for 11.00, but actually I take off on 13.30. I should change the plane in Medan. At 17.50 December 11, 2007 I once again arrive in Banda Aceh.

On December 12, 2007, me, Eric Joe and Eric Brossouloux meet with person from Aceh GIS center. One of my friend work there under GTZ, and we need to gather the information whether we can use their map considering it might be more accurate than what RiskFrame has.

Bruno Maestracci from Civipol join with us in Banda Aceh on Friday night. He come with Paul Delavenne and Feni Rani. During that night finally every party accept our result and Civipol sign the Site Acceptance Test. This the end of this project, of course we should do maintenance it in one year.

OK let stop this story. I hope I can tell you other experience in another project.

‘Til then keep safe and stop global warming.