The MAC address and other parameters are indeed right.
Actually, I found out that the problem was not coming from the driver but really the
routing table/ the application.
The application, videolan, was trying to send IGMP subscriptions on the wrong
interface [although it was not outputing any error message]
Simply adding a route, like
ip route add 224.2.4.6 via 192.168.3.245
this permits to look on the proper DVB interface for multicast contents.
I now use only one pid (2111) where I encapsulate both unicast and multicast data.
Using dvb0_0, with 192.168.3.242/physical MAC address of the card, the videolan client
can properly receive the multicast streams while unicast (pings for instance) still
work at the same time.
Thanks for your help.
Bertrand
>>> Johannes Stezenbach <[EMAIL PROTECTED]> 12/08/2003 20:13:12 >>>
Bertrand Mazieres wrote:
>
> The workaround for e.g. dvb-20020408 driver consists in deleting the following line
> in driver/dvb_net.c:
> dvb->set_multicast_list = dvb_net_set_multi;
>
> Running "tests_sections 2119" yields:
>
> 3e b5 4d 06 04 c1 00 00 02 5e 00 01 >.M......^..E..@
section_syntax_indicator is 1
Section len is 0x54d
unscrambled, LLC/SNAP is 0
MAC := 01:00:5e:02:04:06
> 45 00 05 40 >.M......^..E..@
> 43 28 40 00 7e 11 0c 8b c0 a8 03 49 e0 02 04 06 C(@.~......I....
> 80 02 04 d2 05 2c 9b a3 47 00 44 16 66 e5 c5 e6 .....,..G.D.f...
The remainder are IP datagram bytes according to rfc760/rfc768,
plus a 32bit CRC.
Is that what you expect? (it doesn't look like multicast to me).
Johannes
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
