Next Previous Contents

6. Configuration under Linux

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.

Unfortunately there are no drivers (at this moment) for SkyStar2 (Netsystem card) for Linux!

6.1 Drivers installation

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".

6.2 Setting up /etc/dvbd.conf

/etc/dvbd.conf file is used to setup data-link parameters for your DVB card. Here main settings:

  • "power", which indicates the power to LNB, 1=ON, 0=OFF. Usually you should set it to 1, unless you do some kind of cascade between more than 1 LNB.
  • "symbolrate", this is the symbol rate per seconds, for example 22.000.000.
  • "frequency", at which receiving datas, like 12.640.000.
  • "ttk", the 22 kHz signal, almost always to 1.
  • "diseqc", used to control the diseq, (it means only when you have a diseq controlling 2 or more converters) 0 if none.
  • "AFC", usually set to 1.
  • "polarization", 1 for horizontal or 0 for vertical one.
  • "filter_n <PID> <MAC> <BITFILTER>", where n is intended 0 for Unicast and 1-9 for Multicast; PID is expressed in decimal form, MAC is the MAC address only valid for Multicast filter and BITFILTER is a number which bits represent bytes to mask (for example 10 = 2 (bit 1) + 8 (bit 3), so mask will be 00 00 FF 00 FF 00).

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

6.3 Dvbd daemon

Once your /etc/dvbd.conf is ok, you can launch dvbd application, which, if executed without -d option, write to stdout signal quality level:

  • Sync MUST be 127 or near it
  • Vber MUST be 0

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.

6.4 How to config EON service

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

6.5 How to use Netsystem service

Netsystem service is a little more complicated than EON under Linux, cause, in addition, you need to setup:

  1. VPN connection
  2. patch for pppd (needed only if using pppd <= 2.4.0)
  3. routing settings with simple scripts
  4. patch for dvbd.c
  5. Test it
  6. Get performance better
  7. Sharing Netsystem with many clients

VPN connection

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.

Patch for pppd

As described at PPTP description, you need to patch your pppd daemon to support connection with Netsystem VPN server (Linux server).

Warning: using pppd version >= 2.4.0 you don't need pppd patch.

So you have to:

  1. download a recent pppd version
  2. download and gunzip the correspondent patch for pppd from Here
  3. untar pppd in a directory
  4. type "patch -p0 < patch_name"
  5. enter pppd directory
  6. type "make", "make install"

Routing settings

Now your pppd will be able to working 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:

  1. type "ifconfig ppp1" and find the IP address (I will call IP) on the right of "P-t-P:" string.
  2. delete it from routing table with "route del IP"
  3. add it to ppp0 interface with "route add IP dev ppp0"
  4. delete default gateway from ppp0 with "route del default"
  5. add default gateway to ppp1 with "route add default dev ppp1"

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.

Patch for dvbd.c

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).

For example, using the address 00:d0:d0:d0:d0:d0 we'll have:

dvbcfg[0].filter.data[1] = (0xd0 << 8) | 0x00ff ;

dvbcfg[0].filter.data[2] = (0xd0 << 8) | 0x00ff;

dvbcfg[0].filter.data[6] = (0xd0 << 8) | 0x00ff ;

dvbcfg[0].filter.data[7] = (0xd0 << 8) | 0x00ff ;

dvbcfg[0].filter.data[8] = (0xd0 << 8) | 0x00ff ;

dvbcfg[0].filter.data[9] = (0x00 << 8) | 0x00ff ;

notice hexadecimal notation 0x??

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.

Test it

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:

  1. open your preferred network sniffer (for example Ethereal) and starts to analyze "ppp0" interface (ppp0, not ppp1!!)
  2. make a ping

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.

Get performance better

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.

Sharing Netsystem with many clients

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:

  1. be sure of have installed "iproute2" commands (for example type "ip" on shell and control if it tells you something), for more see Linux 2.4 Advanced Routing HOWTO.
  2. be sure of have started Netsystem service and annotate ppp1 interface IP address, we'll call it LOCALIP.
  3. type: "echo "210 sat" >> /etc/iproute2/rt_tables", to more comfortable call "sat" rule 210
  4. type: "ip rule add from LOCALIP table sat", to create table "sat" relative to all requests coming from LOCALIP IP address.
  5. type: "ip route add default dev ppp1 table sat", to send all "sat" requests (see above) to ppp1 interface.
  6. if you use Socks proxy be sure to set, in sockd.conf file, "external" to LOCALIP.
  7. if you use Squid proxy be sure to set, in squid.conf file, "tcp_outgoing_address" to LOCALIP.

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).

6.6 How to use Sat Node service

You have to follow all instructions as for Netsystem.

Before enabling VPN connection, you need to type:

  • ''route del default'', we delete default route
  • ''route add 212.56.224.36 dev ppp0'', we tell it that it has to reach the vpn server just through ppp0
  • ''pptp 212.56.224.36 user user-name'', we create VPN
  • ''route add default dev ppp1'', we tell it that it must use this route to reach every place.

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.

6.7 OpenSky service under Linux

  1. You need to register at Opensky Registration site. You'll receive a confirming email with login and password in few days.
  2. After you have to go to https://sdr.eutelsat.net and enter login and password data to connect.
  3. Set the proxy: ''proxy.eutelsat.net:8080''.

It is strongly suggested to use downloader applications (see Appendix A for more) to get performance better.

OpenSky is the latest satellite service and it offers 300 MB at month (for free).

Configuration is pretty like EON service, you have to use 0.8.2 siemens drivers you download from LinuxTV, then you NEED to patch dvbd applications.

To apply the patch and to test OpenSky you can find useful infos at:

Next Previous Contents
Copyright © 2010-2024 Platon Technologies, s.r.o.           Home | Man pages | tLDP | Documents | Utilities | About
Design by styleshout