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.