Vita Da Zazu

A seguito di un aggiornamento di Asterisk e qui sono stato stupido per non aver prima fatto un backup :roll:, ricordate bambini, il backup è una cosa importante, più delle forbici dalla punta arrotondata!

Insomma, mi sono ritrovato con il mio centralino casalingo che non effettuava più chiamate uscenti da nessun account VOIP;

dato che prima funzionava, poi ha smesso, 2+2=3,5… la colpa è dell’aggiornamento!

Quindi, armato di pazienza e anche di tempo, perché ho perso 4 o 5 giorni dietro al problema bestemmiofero, sono giunto a riscrivere una configurazione funzionante anche nell’ultima relase di asterisk…

vado qui ad illustrare:

per completezza questo è quanto serve dentro extensions.conf affinché quanto scritto sopra funzioni:

[incoming]

exten => cheapnet,1,Dial(SIP/INTERNO)
exten => messagenet,1,Dial(SIP/INTERNO)

[outgoing]

exten => _53.,1,Dial(SIP/${EXTEN}@messagenet)
exten => _XXX.,1,Macro(dial-failover,SIP/${EXTEN}@messagenet,SIP/${EXTEN}@cheapnet)

[macro-dial-failover]

exten => s,1,Dial(${ARG1})
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-CONGESTION,1,Dial(${ARG2})

Quando ci serve?

Se si hanno nella stessa rete due tipologie di apparati che si vuol tenere “separati”… diciamo così.

la situazione si è verificata passando dalla telefonia analogica al voip;

questo ha comportato l’introduzione di tanti telefoni IP, e per più motivi è bene che stiano su una classe a sé.

Si dovranno quindi gestire due tipologie di apparati:

i PC e i telefoni Grandstream, impossibile gestire i telefoni con ip fisso, sono troppi, per ogni eventuale modifica servirebbe uno schiavo per editarli tutti, quindi, dato che gli schiavi sono proibiti, bisogna fare tutto con DHCP :D.

La configurazione è più semplice del previsto:

DHCPD3 che già veniva usato per gestire la rete, prevede la possibilità di analizzare alcune informazioni fornite dai client quando richiedono un IP, nello specifico io ho focalizzato il mio interesse sul “vendor class identifier” che generalmente identifica il produttore/modello dell’apparecchio

tutti i telefoni Grandstream hanno come vendor class identifier una stringa del genere:  Grandstream [MODEL NAME]

da questa quindi si può facilmente operare una “discriminazione” rispetto ad un qualunque PC

nel file /etc/dhcp3/dhcpd.conf andranno definiti i pattern di controllo che a seconda del caso assegneranno un IP di pool differenti, in questo modo:

dhcpd.conf

ddns-update-style none;
authoritative;
log-facility local7;
option ntp-servers it.pool.ntp.org;

#matching classes
class “ip_phones” {

match if substring (option vendor-class-identifier, 0, 11) = “Grandstream”;
}

class “computers” {

match if not (substring (option vendor-class-identifier, 0, 11) = “Grandstream”);
}

shared-network exemple.local {

subnet 172.16.150.0 netmask 255.255.254.0

{
pool {

allow members of “ip_phones”;
option domain-name “phones.exemple.it”;
option domain-name-servers 208.67.222.222, 208.67.220.220;
range 172.16.150.21 172.16.150.200;
option subnet-mask 255.255.254.0;
option broadcast-address 172.16.151.255;
option routers 172.16.151.254;
default-lease-time 1440;
max-lease-time 7200;
}

}

subnet 10.10.20.0 netmask 255.255.255.0

{
pool {

allow members of “computers”;
option domain-name “computers.exemple.it”;
option domain-name-servers 208.67.222.222, 208.67.220.220;
range 10.10.20.21 10.10.20.190;
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.20.255;
option routers 10.10.20.254;
default-lease-time 1440;
max-lease-time 7200;
}

}

}

Con la direttiva “allow members” possiamo gestire perfettamente tutto il traffico, questo ci permette di avere anche più di due pool, possiamo inoltre definire più pattern di verifica e accettare in un pool più tipologie:

se un giorno verranno introdotti dei telefoni Snom, potranno essere comunque assegnati alla LAN telefonica verificando sempre il loro vendor class identifier

Ok, se sei arrivato qui hai tentato di aggiornare il firmware di un GXP-2000 e qualcosa è andato storto.

Non è detto che un aggiornamento fallito comporti l’aver “brickato” definitivamente il telefono…

come capire se il nostro telefono è recuperabile?

i sintomi di un brick reversibile sono:

• led tutti accesi e luce MWI lampeggiante;
• una scritta sullo schermo ci informa che sta tentando il recovery del firmware via TFTP.

In queste condizioni il nostro telefono può essere resuscitato;

armati di buona volontà iniziamo ad allestire la sala operatoria:

personalmente uso OpenSUSE come sistema operativo, quindi alcuni dei comandi usati saranno prettamente validi solo su questa distribuzione.

Ci occorrerà un server TFTP:

# zypper in atftp

ora dobbiamo configurare ed attivare il server TFTP;

per prima cosa occorre creare la cartella “root” del nostro server (per comodità io l’ho creata sul mio desktop):

$ mkdir /home/zazu/Scrivania/tftp

ora scarichiamo dal sito della Granstream l’ultimo firmware disponibile per il GXP2000 e scompattiamo il tutto dentro la nostra cartella “tftp”, i files strettamente necessari sono: “boot55.bin” e “gxp2000.bin” ma per sicurezza meglio metterli tutti 😉

adesso dobbiamo avviare il server, lo facciamo molto semplicemente con questo comando:

# atftpd --daemon /home/zazu/Scrivania/tftp/

per verificarne il funzionamento, con “netstat -natup | grep 69″ possiamo verificare l’esistenza del server tftp in ascolto.

PASSO 2

Configuriamo la rete e abbassiamo SuSEfirewall.

Consiglio di mettere uno switch tra noi e il telefono per evitare di perdere le configurazioni della nostra scheda di rete;

i parametri da impostare sono i seguenti:

# rcSuSEfirewall2 stop
# ifconfig eth0 168.75.215.188 netmask 0.0.0.0 up
# route add default gw 168.75.215.188

Adesso accendiamo il nostro Grandstream (collegato allo switch) e se tutto è corretto questo inizierà il recovery  TFTP  e sarà in grado di recuperare il firmware dal nostro computer

quando avrà finito sarà diventato nuovamente funzionante