In questa sezione assumeremo di usare una scheda DVB compatibile Siemens, come la Hauppage WinTV DVB, i cui drivers sotto Linux sono disponibili su LinuxTV o su DVB-s PCI cards under Linux .
Purtroppo per la scheda Netsystem (SkyStar2, B2C2inc.) non esistono drivers sotto Linux.
Una volta scaricati, basta scompattarli (tar zxvf file.tgz) su una directory, entrarvi e digitare " make " e " make insmod" : per fare ciò é necessario avere i sorgenti del kernel di Linux su /usr/src/linux (altrimenti, bisognerà scaricarli da http://www.kernel.org e recompilarli).
Dopo aver digitato " make insmod" , il nostro sistema dovrebbe avere i moduli attivi e funzionanti (si controlli con " lsmod" ). Per scaricare i drivers basta digitare " make rmmod" .
Il file /etc/dvbd.conf viene usato per configurare i parametri a livello data-link (livello 2 ISO OSI) della scheda DVB. Seguono i settaggi principali:
Esempio
------------------------------------------
# DVB receiver configuration file, (c) 2000 data planet international
# standard location in /etc
# LNB power on=1/off=0
power 1
# symbol rate [symbol/sec]
symbolrate 22000000
# ASTRA TR 114
frequency 12640000
# 22 kHz signal on=1/off=0
ttk 1
# diseqc on=1/off=0
diseqc 0
# AFC on=1/off=0
AFC 1
# polarisation H=1/V=0
polarisation 1
# settings for MPE filter, PID and MAC filtering, valid MAC bytes
filter_0 512
filter_1 785 00:D0:5C:1E:96:01 48
filter_2 786 00:D0:5C:1E:96:01 48
filter_3 1041 00:D0:5C:1E:96:01 48
-----------------------------------------
filter_0 non ha ne' MAC ne' BITFILTER perché il MAC é già calcolato dall'indirizzo IP dinamico (si veda la solita Appendice A). Vedremo che questo settaggio andrà bene per alcuni ISP, mentre per altri dovremo apportare delle modifiche sul file dvbd.c.
Una volta configurato correttamente il file /etc/dvbd.conf, si può lanciare il programma dvbd, che, se eseguito senza l'opzione " -d" , scriverà sullo stdout il livello del segnale:
altrimenti vorrà dire che non si stà ricevendo segnale (si consiglia di controllare il cavo e/o il puntamento della parabola).
Nota:
E' possibile che ci sia da cambiare, nel file dvbd.h, la linea:
#define network_device "eth0"
in
#define network_device "ppp0"
a seconda dell'interfaccia con cui ci si connette ad Internet, eth0 o ppp0: si digiti " make" per aggiornare il file binario e si rilanci dvbd.
Adesso che si ha un buon segnale, possiamo finalmente provare il servizio Satellitare.
Per EON, si vada nei settaggi del " proxy" nelle preferenze di Netscape e si imposti, sotto proxy HTTP and FTP:
proxy.xxx.europeonline.net
dove xxx é il numero del transponder usato (103,113,114 or 115, si veda l'Appendice B).
e, su " port" 8080 relativamente ad HTTP e 8090 per FTP
Adesso dovrebbe essere possibile usare il browser. Buona navigazione!!
Per condividere EON tra più utenti si può utilizzare il proxy Squid abilitando la cascata verso il proxy EON.
Per una configurazione più complessa di EON si veda il link EON Linux Masquering FAQ Page
Netsystem é un pò più complesso da configurare rispetto a EON, sotto Linux. Seguono i passi principali:
Prima di tutto bisogna scaricare il client VPN PPTP .
Dopo averlo scompattato, compilato e installato, si aggiunge una riga sui files /etc/ppp/pap-secrets e /etc/ppp/chap-secrets, con la seguente sintassi:
" login" * " password" *
dove " login" e " password" sono le stesse della registrazione Netsystem .
Come descritto sulla pagina PPTP , é necessario applicare la patch per il pppd per farlo funzionare con alcuni VPN server, tra cui quello di Netsystem.
Bisogna quindi:
Adesso il pppd sarà compatibile con il server VPN Netsystem e potremo collaudarlo dando:
" pptp vpn.netsystem.com debug user <login>"
dove <login> é la login dell'account di Netsystem: nel file di log (/var/log/messages) dovrebbe comparire il debug dell'interfaccia VPN
Se tutto é andato per il verso giusto dovrebbe essere visibile l'interfaccia ppp1 (tramite comando " ifconfig" ).
In caso di problemi sull'autenticazione si consiglia di aggiungere la seguente riga:
" noauth"
in fondo al file /etc/ppp/options.
Una volta che l'interfaccia é stata caricata bisogna ancora:
I punti 1,2,3 sono necessari in quanto, le connessioni punto-punto sotto Linux tendono ad aggiungere il gateway sull'interfaccia stessa (cosa non corretta nel nostro caso): senza questi comandi si avrebbe un ciclo in cui il pacchetto spedito si incapsula su se stesso all'infinito.
I punti 4,5 sono usati per dirigere tutte le richieste Internet sull'interfaccia ppp1 e in definitiva sulla connessione VPN: questo potrebbe non essere ottimale, per esempio nel casi di richieste DNS, che verrebbero spedite inutilmente (senza miglioramenti, anzi con un peggioramento delle prestazioni) via VPN.
Dopo aver risolto i problemi relativi alla VPN bisognerà cambiare alcune linee nel file dvbd.c, attorno alla fine:
if (strcmp (v, "filter_0") == 0) { if (s != NULL) { unsigned char ip[4];
dvbcfg[0].status = ON ;
dvbcfg[0].filter.data[0] = 0x3eff ;
dvbcfg[0].filter.pid = (__u16) atoi (s) ;
dvbcfg[0].filter.mode = 0x0c ;
if (ipget (ip, network_device)) { fprintf(stderr,"Can't get local ip address. Stop.\n") ; return -1 ; }
syslog (LOG_NOTICE, "Local ip is %u:%u:%u:%u\n", ip[0], ip[1], ip[2], ip[3]);
dvbcfg[0].filter.data[1] = (ip[3] << 8) | 0x00ff ;
dvbcfg[0].filter.data[2] = (ip[2] << 8) | 0x00ff ;
dvbcfg[0].filter.data[6] = (ip[1] << 8) | 0x00ff ;
dvbcfg[0].filter.data[7] = (ip[0] << 8) | 0x00ff ;
dvbcfg[0].filter.data[8] = (0x02 << 8) | 0x00ff ;
dvbcfg[0].filter.data[9] = (0x00 << 8) | 0x00ff ;
setmac (ip) ; }
else { dvbcfg[1].status = OFF ; } }
Le linee seguenti:
dvbcfg[0].filter.data[1] = (ip[3] << 8) | 0x00ff ;
dvbcfg[0].filter.data[2] = (ip[2] << 8) | 0x00ff ;
dvbcfg[0].filter.data[6] = (ip[1] << 8) | 0x00ff ;
dvbcfg[0].filter.data[7] = (ip[0] << 8) | 0x00ff ;
dvbcfg[0].filter.data[8] = (0x02 << 8) | 0x00ff ;
dvbcfg[0].filter.data[9] = (0x00 << 8) | 0x00ff ;
diventano:
dvbcfg[0].filter.data[1] = (MAC[5] << 8) | 0x00ff ;
dvbcfg[0].filter.data[2] = (MAC[4] << 8) | 0x00ff;
dvbcfg[0].filter.data[6] = (MAC[3] << 8) | 0x00ff ;
dvbcfg[0].filter.data[7] = (MAC[2] << 8) | 0x00ff ;
dvbcfg[0].filter.data[8] = (MAC[1] << 8) | 0x00ff ;
dvbcfg[0].filter.data[9] = (MAC[0] << 8) | 0x00ff ;
Dove MAC[0]:MAC[1]:MAC[2]:MAC[3]:MAC[4]:MAC[5] é il nostro indirizzo MAC (nativo) relativo alla registrazione Netsystem.
Dopo, basterà digitare make e utilizzare il nuovo file dvbd così aggiornato.
Nota: perché tale patch abbia successo, é necessario che la versione del driver DVB (nel caso Hauppage) sia >= 0.8.2: le versioni più vecchie hanno problemi di stabilità.
Finalmente, possiamo testare Netsystem sotto Linux. Diamo un " ping www.somehostpingable.com" e controlliamo il tempo di risposta: dovrebbe aggirarsi intorno ai 400-2000 ms e rimanere stabile.
Se i problemi persistono conviene controllare l'interfaccia VPN:
Se la VPN é settata correttamente dovremmo vedere 2 (o 1) pacchetti di tipo GRE-Encapsulated ogni secondo, in modo ininterrotto. Se non appare nulla allora bisognerà rivedere la configurazione della VPN, provando a rilanciarla.
Una volta seguite tutte le istruzioni é ancora NECESSARIO usare (particolarmente con Netsystem) uno qualunque dei " download accelerator"
per migliorare le prestazioni: si veda l'Appendice A a riguardo.
Per condividere Netsystem tra più utenti bisogna prima di tutto attivare l'" IP Masquering" , permettendo agli utenti in rete di utilizzare la VPN come una normale interfaccia Internet per la navigazione; il problema principale però è che la connessione Satellitare risulta essere molto buona per i downloads, mentre per la " semplice navigazione"
è piuttosto scadente (a causa dei tempi d'accesso).
Si potrebbe pensare di utilizzare un proxy come Squid o Socks , ma le cose non migliorerebbero, poiché TUTTE le richieste verrebbero comunque inoltrate all'interfaccia VPN.
La soluzione allora consiste nell'utilizzare 2 tabelle d'instradamento, una connessa direttamente ad Internet, mentre l'altra in grado di attraversare l'interfaccia VPN. Bisogna, quindi:
Una volta fatto tutto ciò, si avranno 2 tipi di funzionamento: senza nessun proxy i clients della LAN chiederanno direttamente ad Internet, mentre utilizzando il proxy prescelto (squid o sockd) le richieste verranno instradate sull'interfaccia VPN, e in definitiva, via Satellite.
Si noti, infine, che sarebbe meglio usare sockd al posto di squid, in quanto le richieste Satellitari sono tipicamente convenienti in download (mentre squid é normalmente utilizzato per la navigazione).
Quel che succede con i comandi iproute2 é che, quando si chiede un sito al proxy, questo (che utilizza l'indirizzo LOCALIP per fare la richiesta) entra nello stack TCP/IP dove il kernel lo manda (grazie al punto 4 di prima) alla tabella " sat" e, quindi (in base al punto 5) sull'interfaccia ppp1. Tutte le altre richieste verranno instradate con la classica " default route" (quindi direttamente su Internet senza Sat, sia essa su ppp0 o su qualunque altra interfaccia che porta sulla grande rete).
Per la maggiorparte della configurazione basta seguire le istruzioni relative a Netsystem.
Prima di attivare la connessione VPN bisogna dare:
* ''route del default'', per cancellare la vecchia default route
* ''route add 212.56.224.36 dev ppp0'', per far raggiungere il server VPN attraverso l'interfaccia ppp0
* ''pptp 212.56.224.36 user user-name'', per creare la VPN
* ''route add default dev ppp1'', per instradare tutto verso l'interfaccia ppp1.
Quello che cambia dalla configurazione di Netsystem e' che non forziamo il gateway VPN (212.56.224.34, che si puo' leggere a destra di ''P-t-P'' nell'interfaccia ppp1) sull'interfaccia ppp0, ma forziamo l'indirizzo 212.56.224.36. Tutto il resto dovrebbe rimanere uguale.
Rigraziamenti a Ricardo Santiago Mozos e Norberto Garcia Prieto.