Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - bringha

Pages: [1] 2 3

22.7 Legacy Series / ipv6: Interface Identifier equal on LAN and WAN

« on: August 19, 2022, 10:54:59 am »

Hi all,

A while ago I changed my config and use a Draytek Vigor 167 directly connected to my opnsense. My provider ist Deutsche Telekom and I have a SuperVectoring connection. I configured a pppoe interface on vlan7 on WAN. Moreover, I created another interface on WAN called Modem to access the Vigor if needed. I get a ipv6 prefix from my supplier and the sense builds the corresponding ipv6 interface identifier (IID) out of the MAC addresses for the full ipv6 address. I have my LAN assigned to igb0 (Mac address Xc:XX:XX:XX:21:ce) and my WAN assigned to igb1 (Mac address Xc:XX:XX:XX:21:cf). So far all is fine and running.

However when looking into the dashboard and the interface overview, it is since then obvious that my LAN and WAN interface have an identical IID. Both IIDs are derived from the LAN MAC address. As a consequence, LAN and WAN have:

the same link local address: fe80:XeXX:efff:XXXX:21ce
the same IID for the public ipv6 address: 2003:<prefix_WAN>:XeXX:efff:XXXX:21ce resp 2003:<prefix_LAN>:XeXX:efff:XXXX:21ce

This looks weird to me. Is there an intention for this ipv6 address building logic? If not is there a need to get this corrected and if so I am wondering whether something could be wrong in my config? Is opnsense supporting privacy extensions for ipv6 meanwhile?

Looking forward to your reply.

Br br

22.1 Legacy Series / [SOLVED] 22.1.9 no access to logs from GUI for some services

« on: June 25, 2022, 04:52:05 pm »

Hi there,

after upgrading from 22.1.8_1 to 22.1.9 there is no access to the log files from GUI for some services. This affects in my case

dhcpd, unbound, system (backend), ACME,

The usual tricks (rebooting again manually, manual store config again , ...) did not change the situation. The GUI pages of the logs stay empty. NTP, system (general), system (webgui), firewall, routing can be viewed fine.

The log files as such are there an get updates as expected

Any idea how to analyse this further?

Looking forward to your reply

BR br

22.1 Legacy Series / ipv6 address generation when using SLACC

« on: February 03, 2022, 04:17:24 pm »

High there,

I upgraded just yesterday to 22.1 and everything went well and smooth, which once again make me very grateful for the excellent work the OPNSense team since years to make this possible. Thank you very much for that

More or less randomly I observed an issue now on the ipv6 address generation which I am not sure whether this is new or was already in the versions before:

My ISP is Telekom and I access my VDSL Dual Stack Super Vectoring access via Modem and PPPoE with configured VLAN 7 on the Sense. IPv6 Prefixes are generated out of WAN capturing with prefix IDs. With SLACC, the address (lower 64 Bits) part then is generated out of the MAC address as being specified in the RFC accordingly. So far so good.

I now observe, that in this configuration my WAN ipv6 address and my LAN IP v6 address differentiate indeed in the prefix, but the address parts are exactly the same on both interfaces. In Interfaces->Overview, the WAN MAC address ist shown as 00:00:..00; LAN MAC address corresponds to the physical one of my Hardware.

However, it seems now to be that the WAN ipv6 address generation on igb1 is using the MAC address of the LAN interface on igb0.

I am wondering whether this is intended as I consider this potentially as a security risk.

Does anyone has a similar observation?

Looking forward to your reply.

Br br

21.7 Legacy Series / [SOLVED] OPNsense VOIP for Gigaset GO Box 100

« on: October 28, 2021, 10:21:09 am »

Hi,

I am going to rebuild my OPNsense installation using

Draytek 167<-->Opnsense 21.7.4<-->(LAN) Gigaset GO Box 100; Provider is Telekom

No Fritz!Box, no sipproxd, the GO Box is directly connected to LAN. Everything is running so far, I implemented the outbound NAT rules (yes static ports is set

, Portforwardings (UDP) SIP and (UDP) RTP, WAN and LAN Firewall rules.

When you configure the GO Box, you have to this with the config wizard, select the Telekom profile and the Box is then configured. After that, the box registers and I can make calls, voice path OK. So far so good.

The problem is now that some time (between 10 and 60 min.), the box looses registration und can be brought back ro re-register only by deleting the complete connection setup and restart the config wizard. Then the device works for 10-60 min again.

Searching through different forum contribs, I have optimized:

- setting firewall optimization to conservative (ie NAT refresh) and set it on the Box to 10 sec
- setting SIP refresh from the suggested Telekom value of 600 to 300 sec
- exactly use the configured SIP port range from the Telekom profile also in NAT/FW rules (5060-5076)
- Reset all states when IP address changes is set

Has someone perhaps an advice for me what else to check?

Looking forward to any suggestions

Br br

21.7 Legacy Series / ACME client gui: Miss staging environment switch

« on: October 24, 2021, 07:51:08 pm »

Hi there,

I just wanted to expand a new domain with letsencrypt certificates via acme plugin (version 3.2) and noted that in acme client->settings->settings there is no switch anymore to change between staging and prod environment of letsencrypt for testing.

Has someone a recommendation how to change the environments now? Did I miss a fundamental change in logic for letsencrypt?

Looking forward to your reply..

Br br

20.7 Legacy Series / unbound - DoT Servers with ipv6 address

« on: December 29, 2020, 09:02:17 pm »

High there,

I have a question around unbound and ipv6 based DNS servers:

I am running my sense behind a fritzbox with Telekom as ISP. The fritzbox acts as a gateway and is talking in ipv6 via Link local addresses (fe80: XXX ....) with the WAN interface of the Sense. I have configured DoT with unbound and from the sense itself, I can query directly the ipv6 addresses of the configured DoT servers. Also all ipv4 queries work fine.

Not so from LAN: when running unbound on debug level 4, I get the following error messages:

Code: [Select]

unbound[99672]: [99672:1] debug: iter_handle processing q with state QUERY TARGETS STATE
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1111 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1001 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip6 2620:fe::11 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip4 9.9.9.11 port 853 (len 16)
unbound[99672]: [99672:1] debug: servselect ip4 1.1.1.1 port 853 (len 16)
unbound[99672]: [99672:1] debug:    rtt=2494
unbound[99672]: [99672:1] debug:    rtt=2915
unbound[99672]: [99672:1] info: sending query: apple-dns.net. DS IN
unbound[99672]: [99672:1] debug: dnssec status: not expected
--> unbound[99672]: [99672:1] error: outgoing tcp: bind: Can't assign requested address
unbound[99672]: [99672:1] debug:    ip4 1.0.0.1 port 853 (len 16)
unbound[99672]: [99672:1] debug: attempt to get extra 3 targets
unbound[99672]: [99672:1] debug:    rtt=275
unbound[99672]: [99672:1] debug:    rtt=376
unbound[99672]: [99672:1] debug:    rtt=376
unbound[99672]: [99672:1] debug:    rtt=2494
unbound[99672]: [99672:1] debug: servselect ip4 1.0.0.1 port 853 (len 16)
unbound[99672]: [99672:1] debug: selrtt 275
unbound[99672]: [99672:1] debug: sending to target: <.> 2606:4700:4700::1001#853
--> unbound[99672]: [99672:1] error: outgoing tcp: bind: Can't assign requested address
unbound[99672]: [99672:1] debug:    ip6 2606:4700:4700::1111 port 853 (len 28)
unbound[99672]: [99672:1] debug:    ip4 1.1.1.1 port 853 (len 16)
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1111 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1001 port 853 (len 28)

When I delete all ipv6 addresses from the DoT list, there is no error message. Obviously, unbound can not contact the ipv6 DNS server from LAN via the gateway (see marked line) - but why ?

I could imagine that this might be a config issue. Does anyone has an advice for me where to look into?

Thank you very much for your advice

BR br

20.7 Legacy Series / DNS Servers with ipv6 addresses not usable with LL ipv6 gateway addresses

« on: October 24, 2020, 01:28:05 pm »

Hi there,

after successfully upgrade to 20.7.4 I digged again into an issue which I notified in 20.7.3 already. It seems to be that neither for dnsmask nor for unbound, DNS Servers with ipv6 addresses (as eg configured in System->Einstellungen->Allgemein) can be used as the static host routes for those DNS Servers are not configured properly when the resolve.conf is rebuild.

Reason seems to be that IF the ipv6 gateway address is link local, the route command is misconfigured in /usr/local/etc/inc/system.inc: function system_resolvconf_generate($verbose = false).

There is an error message generated in system.log

Code: [Select]

Oct 24 12:15:43 OPNsense.zuhause.xx opnsense[9135]: /usr/local/etc/rc.newwanipv6: The command '/sbin/route add -host -'inet6' '2001:470:20::2' 'fe80::3ea6:2fff:fe15:9055%'' returned exit code '71', the output was
 'route: fe80::3ea6:2fff:fe15:9055%: Name does not resolve'

Note the '%' sign in the 'fe80 ....' gateway address which is either obsolete or (perhaps even better) needs a Zone ID like the WAN interface name which would make the address look like 'fe80::3ea6:2fff:fe15:9055%igb1' as an example.

Such an error message is contained for all configured DNS Servers with ipv6 addresses

Adding a proper zone ID or removing the '%' make these error messages disappear and the ipv6 DNS servers are started to be used (however there may be configs where missing zone IDs are not appropriate)

Not sure whether this is appropriate to be fixed in system.inc here:

Code: [Select]

 Line 202 ff
            (...)
            $gwname = $syscfg[$dnsgw];
            if (($gwname != '') && ($gwname != 'none')) {
                $gatewayip = $gateways->getAddress($gwname);
                if (is_ipaddrv4($gatewayip)) {
                    /* dns server array starts at 0 */
                    $dnscountermo = $dnscounter - 1;
                    system_host_route($syscfg['dnsserver'][$dnscountermo], $gatewayip);
                }
                if (is_ipaddrv6($gatewayip)) {
                    /* dns server array starts at 0 */
                                       <--- check/add Zone ID if $gatewayip is LL, similar as eg in system_default_route()
                    $dnscountermo = $dnscounter - 1;
                    system_host_route($syscfg['dnsserver'][$dnscountermo], $gatewayip);
                }

Please let me know whether it is appropriate to open a bug for this on GitHub

br br

20.7 Legacy Series / DNS over TLS with ipv6 forward-addresses - can't get it working

« on: October 17, 2020, 11:08:15 am »

Good morning,

I am on 20.7.3. and I am trying to get DNS over TLS working with unbound. Everything works fine as long as I use IPv4 forwarder addresses in the Services->Unbound TLS->Misc which I put eg in the form 9.9.9.9@853.

When I am adding an ipv6 address like eg 2a05:fc84::42@853 and I restart unbound, the ipv4 forward-addresses are still used/working properly, but my /var/log/resolver/resolver.log gets flooded with

Code: [Select]

Oct 17 10:54:33 OPNsense.zuhause.xx unbound[37717]: [37717:2] error: outgoing tcp: bind: Can't assign requested addressNo request to the ipv6 server is then sent indeed. Removing the address and restarting unbound make the error message disappear again.

My resulting /var/unbound/etc/dot.conf looks like

Code: [Select]

server:
  tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 9.9.9.9@853
  forward-addr: 149.112.112.112@853
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2a05:fc84::42@853

which looks correct to me

There has been an (pretty much) earlier thread on that error message and DoT
https://forum.opnsense.org/index.php?topic=12301.0
after which the DoT (GUI) functionality has been substantially expanded/refactored, however I use recommended forward addresses for my region.

ipv6 Gateway and Wan addresses are both LL. When I run unbound in debug mode, all queries which try to use

Code: [Select]

outgoing-interface: fe80::XXX:YYY:ZZZ:a21dcreate the error message above.

Has someone an idea what could be wrong here or how to debug this further?

Thanks a lot

Br br

20.7 Legacy Series / unbound - ipv6 static route error - zone ID missing ?!

« on: October 14, 2020, 07:46:48 pm »

Hi all,

I am just trying to get up DoT with unbound and when I restart unbound after a config change I get the following error message

Code: [Select]

Oct 14 18:44:10 OPNsense.zuhause.xx opnsense[99771]: /services_unbound.php: The command '/sbin/route add -host -'inet6' '2001:470:20::2' 'fe80::3ea6:2fff:fe15:9055%''
 returned exit code '71', the output was 'route: fe80::3ea6:2fff:fe15:9055%: Name does not resolve'

2001:470 ....is one of my ipv6 DNS Servers configured in system->general, while the fe80 address is my ipv6 gateway. I have these lines in the system log file for each ipv6 dns server.

It seems that there is the Zone ID of my WAN interface missing/incomplete.

Any idea how to correct ?

Looking forward to your reply

Br br

20.7 Legacy Series / syslog-ng: logging reduced/incomplete

« on: September 28, 2020, 02:24:12 pm »

Hi there,

I updated yesterday finally to 20.7.3 from 20.1.9_1, which ran very smooth on my X11-SBA LN4F Supermicro System. All services came up again, there is one thing left which is syslog-ng.

After the restart I had both syslog and syslog-ng running which I solved by deactivating circular logs. Since then, syslog-ng runs stable. However, not all relevant running services are being logged. According to /usr/local/etc/syslog-ng.conf.d/syslog-ng-local.conf, I should see dedicated directories in /var/log/ for

configd +
dhcpd +
dnsmasq
filter +
gateways *
ipsec
lighttpd +
ntpd *
openvpn
pkg *
portalauth +
ppp
haproxy/relayd
routing +
squid
suricata
system +
syslog-ng +

and some more, containing timestamped log files for the individual services. I assume, that indeed loggers are created only if the corresponding service is running.

Service Logs in table above having a '+' are created and contain logs, lines having a '*' have a running service but no logs are created, no tag in the table means that the corresponding service is not active. Saving the config and restart of the service did not help.

Any idea how to get the missing logs for the running services up?

Br br

19.1 Legacy Series / [SOLVED] Upgrade to 19.1.1 - no ipv6 gateway

« on: February 17, 2019, 02:02:02 pm »

Hi,

after upgrading to 19.1.1 from 18.7, the ipv6 gateway is shown as offline and cannot be started from GUI anymore. The issue is that there is no rtsold process anymore pickup the prefix from WAN and also dhcp6d can not be started.

The logs do not show any hint except that they state that there is no ipv6 default route possible to be set;

Code: [Select]

Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: The command '/bin/pkill -'HUP' 'php-cgi'' returned exit code '1', the output was ''
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: entering configure using defaults
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: IPv6 default gateway set to wan
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.2.1
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: keeping current default gateway '192.168.2.1'
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: entering configure using 'wan'
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: IPv6 default gateway set to wan
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.2.1
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: removing /tmp/igb1_defaultgw
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: creating /tmp/igb1_defaultgw using '192.168.2.1'
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb2
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb0
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb3

dpinger can not be started as well (clear if there is no ipv6 gateway ....)

Any idea where to look after?

Br br

18.7 Legacy Series / Upgrade to 18.7.4: telegraf plugin broken?

« on: September 28, 2018, 10:19:08 pm »

Hi there,

after I upgraded to 18.7.4. I noticed that the telegraph plugin seems to be broken, mainly due to the input.systems module; I have no suddenly two log files, one in /var/log/telegraf/telegraf.log and one in /var/log/telegraf.log. Although the config says

Code: [Select]

[global_tags]

[agent]
  interval = "10s"
  round_interval = false
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_jitter = "0s"
  precision = ""
  debug = false
  quiet = true
  logfile = "/var/log/telegraf.log"
  hostname = "opnsense"
  omit_hostname = false

[[outputs.influxdb]]
  urls = ["http://192.168.1.205:8086"]
  database = "telegraf"
  retention_policy = ""
  write_consistency = "any"
  timeout = "5s"
  username = "influx"
  password = "XXXXXXXXXX"




[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false

[[inputs.disk]]
  mount_points = ["/"]

[[inputs.diskio]]

[[inputs.mem]]

[[inputs.processes]]


[[inputs.system]]

[[inputs.net]]

that /var/log/telegraf.log shall be used, it uses the other one and writes tons of messages like

Code: [Select]

2018-09-28T19:20:23Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:20:33Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:20:43Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:20:53Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:03Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:13Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:23Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:33Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:43Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:53Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:22:03Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
E! Unable to append to /var/log/telegraf.log (open /var/log/telegraf.log: permission denied), using stderr

/var/log/telegraf.log belongs now root:root but should root:telegraf (?),

The non-nice side effect is that opnsense throughput in downlink drops to <5% of the normal performance.

Br br

18.1 Legacy Series / 18.1.10: dpinger activation -how to replace apinger

« on: June 21, 2018, 07:46:36 pm »

Hi there,

with pleasure i noticed that now a package for dpinger is provided with 18.1.10. Do I assume right that for now no GUI support for dpinger is provided?

If so is there a safe recommendation how to replace apinger with dpinger via console?

Looking forward to your reply

Br br

18.1 Legacy Series / [SOLVED] Error when installing 18.1.9

« on: May 31, 2018, 09:06:20 pm »

Hi there

Get an error when installing 18.1.9. Installation screen hangs with extracting opnsense-18.1.9 and the following error message appears:

Code: [Select]

[31-May-2018 20:58:01 Europe/Berlin] PHP Fatal error:  Uncaught Error: Class 'OPNsense\Core\Routing' not found in /usr/local/opnsense/mvc/app/config/services_api.php:87
Stack trace:
#0 [internal function]: Closure->{closure}()
#1 [internal function]: Phalcon\Di\Service->resolve(NULL, Object(Phalcon\Di\FactoryDefault))
#2 [internal function]: Phalcon\Di->get('router', NULL)
#3 [internal function]: Phalcon\Di->getShared('router')
#4 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#5 {main}
  thrown in /usr/local/opnsense/mvc/app/config/services_api.php on line 87

Any idea how to fix that?

Br br

17.7 Legacy Series / igmpproxy and Telekom Entertain behind Fritzbox - now working

« on: January 02, 2018, 05:58:24 pm »

Hi all,

the same procedure as every year - but this time with progress: igmpproxy in 17.7 now working with Telekom Entertain and Opnsense behind a Fritzbox as Router. Several topics dealt with that over the last 18 months eg https://forum.opnsense.org/index.php?topic=1968.0,https://forum.opnsense.org/index.php?topic=5295.0.

Over the last year there has been some updates of igmpproxy coming from pfsense space and fed back to freebsd ports, eg https://redmine.pfsense.org/issues/6099. Also, the problems with the correct aging of mcast routes in the table seems to be fixed now. Although not knowing whether all of them are fully reflected in the igmpproxy plugin of the current Opnsense release 17.7.11, I could make it work at least for Telekom Entertain 1.0 (NOT yet proven for the new Telekom Entertain TV 2.0) at least for the following configuration:

----
+-+ S +------> DMZ <-----> Client
| | W |
Telekom ISP <--> Fritzbox 3490 <--> Opnsense <--+-+ I +------> LAN <-----> Client
| | T |
+-+ C +------> WLAN <-----> Client
| H |
----
The switch supports IGMPv3 snooping and provides separated networks for DMZ, LAN, WLAN via untagged VLANs

After installation of the igmpproxy plugin, the following upstream networks should be configured:

193.158.0.0/15
87.140.0.0/15
224.0.0.0/4

The downstream networks should contain the networks of the LAN side interfaces accordingly.

The resulting /usr/local/etc/igmpproxy.conf should look like eg

Code: [Select]

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igb1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4
altnet 87.140.0.0/15

phyint igb0 downstream ratelimit 0 threshold 1
altnet 192.168.X.0/24

phyint igb2 disabled
phyint igb3 disabled

Indeed you can also configure more downstream interfaces (in my case disabled here) important is to have ONE single upstream interface with the shown networks .... At the moment, I don't have yet a BNG network connection (migration announced for Q1), might be that then the upstream networks needs to be adapted.

Then, some firewall rules need to be configured:
On WAN interface:

IPv4 IGMP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension
IPv4 UDP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension

On LAN

activate also extensions on all general rules

Then, very important, under Interfaces->WAN, the box 'block private networks' may NOT be ticked. Otherwise, Opnsense igmpproxy does not see the IGMP Queries from the Fritzbox anymore which prevents in time answers with member reports from the Opnsense and the Fritzbox stops the UDP stream after 2-3 mins.

In my config, TV can be seen stable on all devices in my LAN and WLAN with the vlc player. Thanks to IGMPV3 snooping capable switch, the additional traffic load on the LAN is neglectible ....

I will go for testing of direct connected Opnsense to Draytec Modem (leave out fritzbox) in the next step; as well I am currently working on a full igmpv3 implementation on the downstream side (this seems to be a prerequisite to make Entertain TV 2.0 work)...

Br br

Pages: [1] 2 3