Hi, I'm still having truoble understanding what is not working.
The problem could be could be: 1) The vpn isn't set up correctly; in fact ifconfig ppp1 reports RX bytes:126 (126.0 b) TX bytes:1782125497 (1699.5 Mb) after some minutes. ppp1 goes trought my 56k modem!!!! 2) The filters on the skystar2 (IP and MAC) are not set up as should. The MAC addres I use in ifconfig is the same as the HW one. The IP address... This is my big doubt! My manual tells to set up 192.168.238.238. But using tcpdump I cannot see ANY packet going toward that address. How can I find the right one? On windows 192.168.238.238 works, but I'm not sure the "auto install cd" does some hidden setup (I had to guess vpn settings becouse the windows custom dialer disables Proprties button!). I have done an experiment to find the correct IP... (maybe it is stupid): I tried po ping google and look at icmp packets coming from dvb0_0. But It didn't help. Thank you again. I'm going to write an HOWTO when I manage to fix this! Il gio, 2004-01-29 alle 23:13, Vincenzo Di Massa ha scritto: > Thanks Johannes, > you did help me a lot! > > Now I recieve a lot of packets. But I still can't use them... > Using tcpdump I can see there is traffic on dvb0_0, but it is not > generated from my requests! I can see many packets caming from lot of > sources and directed to various destinations. > > I suppose things work like this: > 1) Packets enter kernel > 2) They are mac-filtered > 3) They are ip-filtered > > So I should only see packets sent to me. > Now... What is worong? > > At first I tought it could be mppe (I disable it, like windows seems to > do), but dumping packets from dvb0_0 I can see some plain text like > "HTTP/1.1 200 OK" into the dump-file. > > [EMAIL PROTECTED] test]# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 212.31.242.131 0.0.0.0 255.255.255.255 UH 0 0 0 > ppp0 > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > 172.30.0.0 0.0.0.0 255.255.0.0 U 0 0 0 > dvb0_0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 > lo > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 > ppp1 > > [EMAIL PROTECTED] test]# ifconfig > dvb0_0 Link encap:Ethernet HWaddr 00:D0:D7:05:78:FD > inet addr:172.30.2.82 Bcast:172.30.255.255 Mask:255.255.0.0 > UP BROADCAST RUNNING NOARP ALLMULTI MULTICAST MTU:4096 > Metric:1 > RX packets:2436763 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:1986677387 (1894.6 Mb) TX bytes:0 (0.0 b) > Base address:0x5ab > > eth0 Link encap:Ethernet HWaddr 00:20:ED:78:BE:5C > inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:17487 errors:0 dropped:0 overruns:0 frame:0 > TX packets:8621 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:17273489 (16.4 Mb) TX bytes:2458377 (2.3 Mb) > Interrupt:20 Base address:0xa400 Memory:fa011000-fa011038 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:232 errors:0 dropped:0 overruns:0 frame:0 > TX packets:232 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:16656 (16.2 Kb) TX bytes:16656 (16.2 Kb) > > ppp0 Link encap:Point-to-Point Protocol > inet addr:80.182.178.4 P-t-P:151.99.26.43 > Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > RX packets:2041 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1337 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:246451 (240.6 Kb) TX bytes:96561 (94.2 Kb) > > ppp1 Link encap:Point-to-Point Protocol > inet addr:172.30.2.82 P-t-P:212.31.242.131 > Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > RX packets:4 errors:0 dropped:0 overruns:0 frame:0 > TX packets:116189771 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:126 (126.0 b) TX bytes:1782125497 (1699.5 Mb) > > Il mer, 2004-01-28 alle 18:38, Johannes Stezenbach ha scritto: > > Vincenzo Di Massa wrote: > > > 2) Load dvb modules. I use dvb_shutdown_timeout=0 option to whatch TV. > > > Is it ok for data? > > > > Yes and no. It means the kernel thread which normally monitors the > > frontend will be stopped as soon as the frontend is closed. If your > > signal is stable this might be OK. > > > > > 3) Use szap to tune to the right transponder and set the pid I need. Do > > > I need to let it run? Shall I tell szap the same pid twice? Shall I use 8192? Do > > > I need -r option? > > > > Don't set any pids at all (use 1fff in channels.conf, no -r). > > > > > 4) Use dvbnet to bring up dvb0_0. I need to set mac and IP address using > > > ifconfig, right? > > > > Yes. > > > > > 5) Use pptp (I have upgraded kernel and pppd already): pptp > > > vpn.alicesat.it user <user> > > > 6) Set up routing. I must send all packets trught ppp1(vpn) and its > > > gateway. > > > > > > Now I should be able to use my sat internet account but... I just don't > > > recieve a bit into dvb0_0. > > > Is this procedure right? > > > All kernel messages "sound" like there is no problem. > > > > - use test_sections or dvbsnoop on the PID you pass to dvb_net to see > > if there are any packets at all; compare with ETSI EN 301 192 > > (chapter "MPE - Multi Protocol Encapsulation") > > - look at dvb_net_sec() and possibly add a printk for debugging > > - check /proc/sys/net/ipv4/conf/*/rp_filter > > - try tcpdump -i dvb0_0 > > > > > Anyway it just crashes on 2.6.1 when using dvbnet. But it works with > > > 2.4.22. (both kernels are using 2 days old cvs dvb-kernel) > > > > Hm, I didn't test dvb_net with 2.6 so far... > > I don't have any test account so I can only passively monitor > > some MPE service, which isn't much fun ;-( > > > > Johannes > -- > Vincenzo Di Massa <[EMAIL PROTECTED]> -- Vincenzo Di Massa <[EMAIL PROTECTED]> -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
