In this section I will assume to use a Siemens compatible card, like an Hauppage WinTV DVB card, for such cards you can download drivers from LinuxTV or DVB-s PCI cards under Linux .
Once downloaded drivers, you have to untar them to a directory, enter it and type " make" and " make insmod" . To do this you need to have actual kernel sources under /usr/src/linux (unless, download them from http://www.kernel.org and recompile them).
After made " make insmod" , your system should have DVB modules loaded. To unload them type simply " make rmmod" .
/etc/dvbd.conf file is used to setup data-link parameters for your DVB card. Here main settings:
Example
------------------------------------------
# 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 has no MAC and no bitfilter values cause the right MAC address is calculated from IP address (see Appendix A). We will see this setting is OK only for some ISP, for others we'll have to change dvbd.c
Once your /etc/dvbd.conf is ok, you can launch dvbd application, which, if executed without -d option, write to stdout signal quality level:
unless you are not well receiving from Sat (check cable and/or dish pointing).
Note:
Maybe you have to change, in dvbd.h this line
#define network_device "eth0"
to
#define network_device "ppp0"
depending on which interface you use to reach Internet, eth0 or ppp0: type " make" to update binary file and restart dvbd.
Now you have a good signal, you can try to use some sat service.
For EON go at " proxy" setting in Netscape preferences and set under HTTP and FTP:
proxy.xxx.europeonline.net
and, in " port" 8080 and FTP proxy with " port" 8090.
where xxx is the transponder number (103,113,114 or 115) you are using (see Appendix B for more).
Now you should be able to navigate wherever you want.... Good navigation.
To share EON service with many clients you can use Squid proxy application, enabling cascade to EON proxy.
For a more complex use of EON, like more complex cascade proxy or sharing users, see EON Linux Masquering FAQ Page
Netsystem service is a little more complicated than EON under Linux, cause, in addition, you need to setup:
First you need to download VPN PPTP client application .
After untared, compiled and installed it, you should add an entry to your /etc/ppp/pap-secrets and /etc/ppp/chap-secrets files, like that:
" login" * " password" *
where " login" and " password" are the same according to Netsystem registration .
As described at PPTP description , you need to patch your pppd daemon to support connection with Netsystem VPN server (Linux server).
So you have to:
Now your pppd will be able to working with Netsystem VPN; you can try with
" pptp vpn.netsystem.com debug user <login>"
where <login> is your login account from Netsystem: you should see, in log file (/var/log/messages) ppp1 connection debug info.
If all is ok you should see ppp1 interface with " ifconfig" command.
If you still have problems on authentication, please add a " noauth"
line to your /etc/ppp/options file.
Once ppp1 interface is up, you should do the following:
Points 1-3 are requested cause point-to-point interface are managed, under Linux, adding the gateway to the new interface (which is not a good idea in this case): unless it you will have a endless loop, cause your packet will be continuously encapsulated on itself.
Points 4,5 are used to make " all internet requests" to ppp1 interface, so we'll reach the " world" by using VPN connection: this could be not optimal in some condition, for example for DNS queries, which could be sent directly to avoid useless Sat delay time.
Instead of manually setup routing configuration you can try using these little scripts:
" netsystem.on" script
route add IP_DNS1 dev ppp0 route add IP_DNS2 dev ppp0 route add -net 212.31.242.0 netmask 255.255.255.0 dev ppp0 pptp vpn.netsystem.com user <login> /bin/sleep 5 route add default dev ppp1
" netsystem.off" script
route del IP_DNS1 dev ppp0 route del IP_DNS2 dev ppp0 route del -net 212.31.242.0 netmask 255.255.255.0 dev ppp0 kill -9 `ps x|grep "pppd"|grep "<login>"|grep -v "ps"|tr " " "\n"|head -n 2` rm --force /var/lock/LCK..tty* rm --force /var/run/pptp/* rm --force /var/run/ppp1.pid killall -9 pptp
IP_DNS1 and IP_DNS2 are ip addresses of your dns servers (primary and secondary). <login> is the login name of your Netsystem account. I tried it out under kernel 2.4.6 RedHat 7.1 and it works very well (without any problems about ppp1 endless loop or similar).
This line:
kill -9 `ps x|grep "pppd"|grep "<login>"|grep -v "ps"|tr " " "\n"|head -n 2`
is used to find PID of pppd process talking with VPN server (ppp1 interface): notice that you cannot just only type " killall pppd"
cause your ppp0 interface also would go down.
After solved problems about PPTP you have to change some line in dvbd.c, near the end of it:
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 ; } }
Now following lines:
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 ;
will be changed to
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 ;
Where MAC[0]:MAC[1]:MAC[2]:MAC[3]:MAC[4]:MAC[5] is our MAC address (according to Netsystem registration).
After, you have to type " make" and use the new dvbd created.
Note: to successfully patch the dvbd.c you need to use dvb driver version >= 0.8.2, cause older versions have some instability problems.
Finally, we can test Netsystem under Linux. We can make a " ping www.somehostpingable.com" and check the response time: it should be between 400 and 2000 ms.
If you still have problems, you should control if all is OK with VPN interface:
If VPN is ok you should see 2 (or maybe 1) GRE-Encapsulated packets each second, endless. If you cannot view anything your VPN is not correctly working: stop it and restart it.
Once you setup all things you NEED to use (particularly with Netsystem service) some " download accelerator" to get performance better: please see Appendix A for more.
To do this you can enable " IP Masquering" , allowing your client to use VPN like a normal Internet interface; main problem is that our satellite connection is very good for download while it has bad performance for just browsing web pages (or other service more interactive than downloading).
You can think to use Squid proxy or Socks proxy , but you don't solve your problems, cause even now ALL your request would be forwarded to same interface, VPN.
The solution is to use 2 routing tables, one using direct line interface and the other using VPN one. So you can do like this:
Once done all that, you will notice to have 2 kind of working: without any proxy your clients will ask to direct line, while by using proxy (squid or sockd) the request will be forwarded to VPN interface and, definitely, toward satellite.
Notice that maybe you wish to use sockd instead of squid, cause satellite requests are typically used for download (while squid is typically used for browsing...).
What happens with iproute2 commands is that, when you ask for an address to sockd or squid, relative proxy (using IPLOCAL IP address, bound at run-time by proxy network daemon) request enters the TCP/IP stack where kernel will forward it (thanks to point 4 above) to sat table and, definitely (by using point 5) to ppp1 interface. All other rules will be forwarded to classical default route (I mean across ppp0 interface or whatever other interface for direct Internet).
You have to follow all instructions as for Netsystem.
Before enabling VPN connection, you need to type:
What really changes from Netsystem is that, we don't force VPN gateway (212.56.224.34, IP on the right of ''P-t-P'' in ppp1 interface) on ppp0 interface, but we force another IP (212.56.224.36). All other things should not change.
Thanks to Ricardo Santiago Mozos and Norberto Garcia Prieto.