After booting openwrt in the yesterday post, i found some problems with openwrt in routerboard 450g. The three more important and evident issues are:

• OpenWRT don’t see the NAND flash at all
• OpenWRT see only 128 MB of RAM instead of 256 MB
• OpenWRT don’t see the five Ethernet ports

After asking by email and fax mikrotik to release the kernel patches for this board, they send to me this patch against the 2.6.27 kernel: Mikrotik patches

WARNING: Mikrotik send me another mail saying that the yesterday patch has an issue, so, they send me a new one fixed. Thit is the Mikrotik kernel patch fixed

linux, mikrotik, openwrt, routerboard

Recently Mikrotik has released a new board, the routerboard 450G, something like an upgraded version of the 450 more powerfull and cheap.

It is an atheros 7161 @680 Mhz based board, with 256 megs of RAM, 512 megs of NAND storage, 5 ethernet ports (3 10/100/1000 and 2 10/100) with POE and a microsd slot. It costs around 150€ complete with enclosure and power adapter, and it is shipped with RouterOS 3.21 preinstalled.

RouterOS is a good linux based OS with a proprietary userland, and it work great as i can see searching on the web. But for my personal needs, it isn’t the right choice cause i love linux and freedom, and cause i need to put some scripts and software developed by me for my use. So, i’m investigating on how to use a “real” linux on it. My final goal will be to run debian or emdebian, but for initial testing openwrt seem to be more adapt cause it support (or at least some work is done) for other routerboard systems.

First Try: boot OpenWRT kamikaze

To start working on it with linux, my choice is to boot openwrt kamikaze svn trunk from tftp. This is a step by step chronicle of the status of my tests.

Pass 1: get and compile kamikaze.

dedalo|/home/nextime$ svn co svn://svn.openwrt.org/openwrt/trunk kamikaze
[...]
Updated to revision 15208.
dedalo|~$ cd kamikaze
dedalo|~/kamikaze$ make menuconfig

This command will start the ncurses interface to generate a .config file.
Select “Atheros AR71xx [2.6]” as the target system:

Select Exit and save the config, and start to build openwrt:

*** End of OpenWrt configuration.
*** Execute 'make' to build the OpenWrt or try 'make help'.
dedalo|~/kamikaze$ make
Checking 'working-make'... ok.
Checking 'case-sensitive-fs'... ok.
[...]
 make[2] target/install
 make[3] -C target/linux install
 make[2] package/index
 dedalo|~/kamikaze$

I assume you know how to install and you already have a dhcpd and a tftpd servers installed. This is a piece of my dhcpd.conf:

host routerboard1 {
        hardware ethernet 00:0c:42:3e:58:98;
        option domain-name-servers 192.168.5.8;
        option domain-name "nexlab.thc";
        option routers 192.168.2.254;
        option broadcast-address 192.168.2.255;
        next-server 192.168.2.2;
        fixed-address 192.168.2.76;
        filename "routerboardlinux";
}

Move the openwrt image created to the tftp server root and rename it:

dedalo|~/kamikaze$ mv bin/openwrt-ar71xx-vmlinux.elf /tftproot/routerboardlinux
dedalo|~/kamikaze$

Now is time to boot our rb450g. Attach it on the serial port with a null modem cable, and start minicom with those settings:

Boot the routerboard, and when it say to do it, press any key to enter in the bootloader configuration menu

Press “o” and “e” to change the boot device to “network”, and press x to exit setup

   t - do memory testing
   x - exit setup
your choice: x - exit setup                                                     

RouterBOOT booter 2.20                                                          

RouterBoard 450G                                                                

CPU frequency: 680 MHz
  Memory size: 256 MB                                                           

Press any key within 2 seconds to enter setup..
trying bootp protocol... OK
Got IP address: 192.168.2.76
resolved mac address 00:13:8F:98:13:2B
Gateway: 192.168.2.254
transfer started .......................... transfer ok, time=9.25s
setting up elf image... OK
jumping to kernel code
Linux version 2.6.28.9 (nextime@dedalo) (gcc version 4.1.2) #1 Sun Apr 12 01:209
console [early0] enabled
      CPU revision is: 00019374 (MIPS 24Kc)
Atheros AR7161 rev 2 (id:0xaa), CPU:680.000 MHz, AHB:170.000 MHz, DDR:340.000 Mz
Determined physical RAM map:
 memory: 08000000 @ 00000000 (usable)
[...]
BusyBox v1.11.3 (2009-04-12 00:57:05 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.                                   

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r15208) -------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/#

Now we have openwrt running. Next time i will analyze what work and what don’t work.

linux, mikrotik, openwrt, routerboard

Oggi e’ stata rilasciata una nuova release di Medianix base, la 0.7, oltre che il nuovo modulo FreePBX. Dal trac di medianix:

Changes in FreePBX 0.3 module:

* asterisk upgraded to 1.4.4

* asterisk-gui upgraded to svn trunk 20070520

* zaptel upgraded to 1.4.2.1

Changes in medianix 0.7 base:

* zaptel modules upgraded to 1.4.2.1

* base system upgraded to latest debian sid

* some minor bugfix

Maggiori dettagli al link http://trac.medianix.org

asterisk, medianix, VoIP

Oggi mi sono svegliato presto, con un pensiero che mi ronzava nella testa. Si, ho risolto il problema con fastweb, e il mio SIP server ora funziona alla perfezione. Pero’ i “tecnici” di fastweb hanno qualcosa come 15 tickets chiusi in un giorno dove sta scritto che le cose non funzionano a causa mia, della mia configurazione, e questo proprio non riuscivo a farmelo andare giu’.

Inizio a pensare a come convincerli del fatto che il problema e’ loro mentre faccio colazione, e un pensiero si fa sempre piu insistente nella mia testa. In fondo, ora il loro “GAD” e’ staccato, e quindi se fanno una verifica a loro risulta che la mia connessione sia “down”.

Decido quindi di tornare a Milano sulla scena del crimine, e di ingannare fastweb al fine di dimostrare quanto siano incompetenti. Non so se riusciranno a risolvere il problema, ma questo in fondo poco importa, tanto so come risolverlo da me, l’importante e’ che capiscano che il problema e’ loro, non mio!.

Prendo la macchina e mi butto in autostrada, e, durante il tragitto, telefono a fastweb annunciando che siamo senza connessione e che probabilmente il loro GAD e’ morto, non da’ piu segni di vita. L’operatrice ovviamente mi rivolge le domande di rito, tipo “avete provato a riavviare il GAD togliendo e rimettendo la spina?”, e ancora “le linee telefoniche invece funzionano?” e cosi’ via. Ma io insisto che ho fatto tutto, che nulla funziona, che devono fare uscire un tecnico. Detto fatto, mi annuncia che ha aperto la segnalazione e che verro’ richiamato a breve per prendere un appuntamento da parte del tecnico che verra’ a sistemare il problema.

Passano 2 ore, io sono in ufficio che aspetto ( con il GAD staccato ma con la connessione che funziona a meraviglia ), quando finalmente suona il cellulare. E’ lui, il tecnico di fastweb, mi annuncia che verra’ presso la nostra sede alle 14:30 ( ho chiamato alle 9… se avessi davvero un guasto avrei perso mezza giornata di lavoro minimo! ah, che assistenza! ).

Arrivamo le 14:30, una telefonata mi annuncia che il tecnico arrivera’ un po’ in ritardo ma di stare tranquillo che sta arrivando. In effetti oggi piove che quel tizio lassu’ la manda, quindi non mi stupisco piu di tanto pensando ai possibili ingorghi da pioggia nel traffico milanese, mi metto il cuore in pace e aspetto.

Arrivano le 15 e finalmente il tecnico suona il campanello. E’ arrivato. gli vado incontro per accompagnarlo nel piccolo NOC dell’ufficio esordendo con un bel “buongiorno, le svelo un segreto, il nostro GAD funziona benissimo, e’ stato un problema simulato, ora le spiego il vero problema…”, e gli spiego tutta la pappardella di cio’ che e’ successo il giorno prima, di quale sia il vero problema, di quali siano le soluzioni che ho provato (si, compreso il fatto di staccare quel cesso di GAD).

Il tecnico porello e’ un dipendende di una azienda esterna in appalto, e piu di tanto non ne capisce, e’ anzi preoccupato di come giustificare la sua uscita. Ma io lo incalzo e lo invito a chiamare qualcuno che possa davvero capire il mio problema, e lui, gentilissimo e assolutamente senza colpa in tutto questo, mi asseconda. Chiama un suo contatto all’interno di fastweb dicendomi “questo e’ un ragazzo davvero in gamba, se c’e’ qualcuno che puo’ aiutarti e’ lui”. E in effetti ammetto che la persona dall’altra parte del telefono e’ competente. Con la sua guida e le password del tecnico ( che ovviamente non mi ha rivelato ) entriamo nel GAD dal terminale seriale.

Il GAD e’ una macchina ARM con un Linux embedded (kernel montavista), busybox e una cavolo di shell che emula in tutto e per tutto una CLI di Cisco IOS ( che fantasia quelli di telsey ). inizio a guardare la configurazione, e subito mi accorgo di una cosa. Non ci sono filtri apparentemente, ma c’e’ un limite di banda e di connessioni sulla porta udp 5060, ebbravi fastwebbari!.

Ranzo via il filtro con il permesso del tecnico al telefono, e giro un po’ nella cli alla ricerca di altri eventuali filtri. Il nulla, non c’e’ nulla. Decido per un “reload” del firmware, giusto per vedere se torna per caso il limite di prima, e nel frattempo ho sempre il mio hping che viaggia da una macchina esterna e il mio tcpdump che sniffa la eth0 della mia linuxbox.

La regola di limit non torna su, bene, ma una cosa mi salta all’occhio. Mentre il GAD fa il riavvio, durante lo shutdown per un attimo arrivano i pacchetti che sto inviando con hping2 (circa 10 pacchetti, giusto giusto prima del termine dello shutdown), e mentre il GAD si riavvia, altri 4 pacchetti arrivano da quando viene su la scheda di rete a quando appare la scritta “starting configuration” al terminale. Strano, sembra proprio il comportamento tipico di regole di iptables applicate durante il boot in uno script di init!. Ma dalla cli invece il nulla, non risultano filtri di alcun genere.

Morale della storia, non siamo riusciti a risolvere il problema, ma i tecnici hanno dovuto ammettere ( anche per iscritto, mi sono fatto firmare una dichiarazione, non si sa mai potrebbe servirmi ) che il problema sta sul loro GAD, suggerendomi di attendere il cambio di contratto che ho in corso e che a breve mi fara’ cambiare il GAD con un router cisco, sperando che con quello il problema non si verifichi piu’.

Una cosa e’ comunque certa, nel firmware del GAD fastweb effettivamente FILTRA i pacchetti in ingresso sulla 5060 UDP!

A questo punto ringrazio il tecnico, lo lascio andare via, e appena uscito dalla porta spengo il gad, lo metto da parte, e rimetto la mia bella macchina linux davanti a tutto, e vivo felice con la mia bella rete che funziona. Per ora va bene cosi’, ne riparliamo quando mi cambieranno il router…

To be continued…

asterisk, fastweb, VoIP

Cercando un poco su google si incappa facilmente in post di utenti di Fastweb che dichiarano di sospettare che quest’ultima filtri il protocollo SIP, rendendo di fatto difficile l’utilizzo di tanti provider VoIP che stanno nascendo in questi ultimi anni.

Io devo dire che sinceramente non ho trovato questi problemi, e, nat a parte con i suoi casini, un client SIP dentro la rete fastweb mi ha sempre funzionato egregiamente.

Oggi pero’ mi sono scontrato con un fatto sconcertante con il suddetto ISP.

Prima spieghiamo la situazione: un mio cliente, che possiede in ufficio un contratto “small businness”, decide di piazzare un Asterisk server sul quale ricevere delle chiamate via SIP. Per fare questo, essendo fastweb un grande NAT, compra il servizio “IP Pubblico”, e si fa assegnare 4 indirizzi ip pubblici, routati verso una macchina interna alla propria LAN (badate, non nattati o in pat, routati!)

Detto fatto, ci assegnano 4 indirizzi, rediretti verso la nostra macchina interna con ip 192.168.0.7, macchina linux che funge da router e redirige gli ip pubblici a 4 macchine dietro di essa. Tutto sembra funzionare a meraviglia, impostati gli ip alias sulle macchine che dovevano essere raggiungibili dall’esterno, queste ultime sono effettivamente raggiungibili, ci entro in ssh, mi apro apache, faccio tante cosine e tutto funziona.

Allora installo asterisk, mi chiamo via IAX2, funziona.

Configuro asterisk per stare in ascolto con chan_sip sulla porta udp 5060 (la porta standard per SIP) provo a registrarmi con un client dall’esterno e… uhmm… nulla, non si registra. Strano, funziona tutto… perche’ non si registra?

Decido quindi di tracciare un po’ il traffico, mi piazzo sul router, avvio tcpdump, entro in una mia macchina esterna a fastweb, e avvio un hping2 -2 -p 5060 . Niente, non c’e’ traccia di pacchetti che arrivino al mio router. Strano. Magari e’ il firewalling. Cancello TUTTE le regole di iptables, tanto per essere sicuri. Nulla, non arriva nulla.

Cambio porta ad hping2, provo la 5061, e i pacchetti arrivano. Provo un po’ di porte random, e i pacchetti arrivano. Riprovo la 5060, il nulla. Decido quindi che il problema e’ in Fastweb, e quindi chiamero’ l’assistenza domani. Domani e’ oggi.

Siamo quindi arrivati a questa giornata infame. Stamattina, appena arrivato in ufficio, chiamo il 192194, servizio clienti di fastweb per le aziende. Spiego il problema all’operatore del call center, che apre un ticket e mi fa lasciare il numero di telefono, dicendomi che mi fara’ richiamare da un tecnico.

Dopo 2 ore non mi ha chiamato nessuno, quindi richiamo il 192194. Di nuovo mi dicono che un tecnico mi chiamera’ a breve, ed effettivamente dopo circa 10 minuti ricevo una telefonata.

Spiego il problema, il tecnico mi mette in attesa mentre controlla la configurazione del “GAD”, ovvero il loro piccolo router telsey con linux che mettono con questo genere di contratti. Dopo un po’ l’attesa finisce e il tecnico mi dice “non c’e’ nessun filtro sul gad, e’ sicuro che dal suo lato e’ tutto a posto?”

A questo punto io spiego che sto sniffando con tcpdump, che solo quella porta da problemi, che sono collegato diretto al gad e quindi non c’e’ ne firewall ne altro in mezzo. Sembra convincersi, e mi rimette in attesa. Attendo… attendo… passano 16 minuti in attesa, e cade la chiamata.

Richiamo il 192194, risponde un altro operatore, rispiego il problema. Mi conferma che non ci sono filtri sul gad e mi dice che mi richiameranno.

Dopo un’ora mi richiama un altro tecnico, rispiego nuovamente il problema, mi mette in attesa e dopo un po’ mi dice “non ci sono filtri sul gad, non e’ un suo problema?”. Io inizio ad irritarmi, ma gentilmente rispiego nuovamente il tutto, sottolineando che o i pacchetti si perdono a meta’ del cavo di rete di 50 cm tra il gad e il mio router, oppure i pacchetti si fermano da loro, sul gad o prima. Il tecnico a quel punto mi dice “forse e’ la sua scheda di rete rotta, ha provato a cambiare scheda di rete?”.

Ora mi incazzo sul serio, e inizio a spiegargli, bestemmiando allegramente, che dovrebbe provare a tracciare i pacchetti dumpando il traffico sulle sue fottute schede di rete, oppure che facciano uscire un tecnico a verificare di persona il problema, e smetterla di dire che e’ un problema dal mio lato, perche’ semplicemente NON e’ cosi’.

Il tecnico mi risponde “capisco, ok attenda un attimo, la richiamo io” e riaggancia. Dopo 10 minuti di richiama, e mi conferma che non ci sono problemi, e che quindi secondo lui il problema e’ da me. Non piu’ tanto gentilmente gli spiego qualcosa sulle reti e su quello che sto provando sperando di dimostrare che il problema non e’ mio. Dopo un po’ mi rimette in attesa, cade la linea e finisce li.

Irritato chiamo nuovamente il call center, dove mi viene detto che il ticket e’ stato chiuso con motivazione “problema di competenza del cliente”. Mi incazzo, chiedo di parlare con un responsabile, mi passano uno pseudotale, che riapre un nuovo ticket.

Ora senza tirarla ulteriormente per le lunghe, andiamo avanti tutta la giornata, fino alle 19 circa in questo modo. Ho chiamato il call center almeno altre 14/15 volte, tutte le volte mi confermavano che il ticket precedente era stato chiuso con la stessa motivazione, e mi dicevano che mi avrebbero fatto richiamare da un tecnico. Nessun tecnico mi richiamava, io richiamavo e il ciclo ricominciava.

Alla fine mi sono decisamente rotto, ho staccato fisicamente il loro “gad”, ho attaccato la mia macchina linux diretta al media converter, ho spoofato il mac-address del gad e mi sono preso il suo indirizzo IP interno a fastweb. Tutto magicamente ha iniziato a funzionare, e i pacchetti udp 5060 arrivano senza problemi, riesco a registrarmi al server senza problemi e le chiamate via SIP funzionano alla perfezione. Ma come, non mi avevano detto che non c’era nessun filtro e che il problema era mio?

Sono senza parole.

asterisk, fastweb, VoIP