Spionierenden LG TV blockieren

[Benares]

:mrgreen: Apropos Proxy: fritz.box:8181 :mrgreen:

Was möchtest du uns/mir damit sagen? Bei mir kommt da

 

[koyaanisqatsi]

Es ist mit Smilies eingerammt, weil nicht ERNST gemeint.
Wenn du diese IPORT Adresse richtig als Proxyserver einträgst, kommt diese Meldung bei jeden Host.

Hab auch einen...

 

[PeterPawn]

Ja, mir. Ich hab grad versucht Google mittels der nicht angehakten erlaubten IPs auszusperren.

Das weißt Du besser ...

Ich würde auch nicht versuchen, die heranstürmende Flut am Strand mit Schippchen und Eimer aufzuhalten, um meine Sandburg zu verteidigen.

Wobei ... www.google.de löst bei mir derzeit auf 4 IPv4- und eine IPv6-Adresse auf. Wenn Du die blockierst, dann ist das zwar ein riesiger Aufwand, aber es sollte doch eigentlich funktionieren. Oder ist das wirklich so heftiges DNS-Round-Robin im Einsatz, daß man die Adressen gar nicht vorhersagen kann ? Ist halt immer auch die Frage, wie/wo der Anbieter - wenn überhaupt - ein Load-Balancing eingebaut hat.

Bei LG ist das offenbar alles (bei meinem Modell) unter einem einzigen Domain-Namen (DE.lgtvsdp.com) erreichbar, der auf eine einzelne IP (193.67.216.51) auflöst. Da das bei der anzunehmenden Anzahl von verkauften Geräten sicherlich nicht nur ein einzelner Server ist (obwohl ich auch einen Server pro Land/Sprache nicht grundsätzlich ausschließen würde, sooo häufig findet da auch keine Kommunikation statt), findet das SLB wohl dahinter statt. Ich habe jedenfalls (schon vor einiger Zeit, ist also etwas her) bei DNS-Abfragen von verschiedenen Standorten/Providern im deutschsprachigen Raum kein Round Robin bei der DNS-Auflösung gefunden.

Was ich bisher aber immer noch nicht ausdrücklich gelesen habe: Läßt die Box denn nun TCP-Verbindungen zu "blacklisted" IP-Adressen durch, oder nicht ? Wirkt die Listung auf Protokoll- oder auf Adressebene ?

Da ist mir DNS und/oder ein Proxy (mit Filter) lieber. ... Apropos Proxy: fritz.box:8181

Das stelle ich mir nun wirklich kompliziert vor. Gibt es wirklich einen LG-TV, bei dem man für den Internet-Zugriff einen Proxy (egal ob SOCKS oder gezielt HTTP(S)) einstellen kann ? Der Fernseher ist eines der wenigen Geräte, wo ich an einer Kommandozeile bisher noch kein echtes Interesse hatte (auch wenn das System Linux-basiert ist und ich bei LG schon mal die Quellen für eine ältere Version gefunden hatte).
Edit: Ok, das habe ich - trotz des breiten Grinsens - auch mißverstanden. Ich dachte beim ersten Lesen wirklich, daß Du da: "Das gibt es doch schon." meintest.

Ich hatte bei meiner Einschränkung (des praktikablen Einsatzes eines Adressfilters) auch in erster Linie an das Hosting mehrerer SSL-Server unter einer gemeinsamen IP-Adresse und die Unterscheidung durch SNI gedacht. Da *könnte* die Box zwar anhand des Servernamens im "Client Hello" filtern (es ist ja noch unverschlüsselt), macht sie aber wohl auch nicht ... selbst wenn heutzutage eigentlich jeder HTTPS-Client auch die SNI sendet (mein LG-TV auch). Wenn sie dann die komplette Adresse blockiert, sind alle anderen HTTPS-Dienste unter der Adresse auch nicht erreichbar. Das funktioniert ja auch spätestens dann nicht mehr, wenn mehrere Dienste unter einem gemeinsamen Servernamen und unterschiedlichen URLs erreichbar sind (da gab es ja gerade in England mit dem obligatorischen Filter entsprechende Probleme).

Da man aber (wieder bezogen auf mein Gerät) beim Fernseher den DNS-Server (unabhängig von sonstigen DHCP-Einstellungen) auch manuell festlegen kann, braucht man für das "Abstellen" der Kommunikation des LG-TV nicht unbedingt den Service für alle Geräte im LAN zu verbiegen. Es geht - bei ohnehin vorhandenem DNS-Server mit ACLs, wie bind - auch sehr selektiv.

 

[koyaanisqatsi]

Google

Nur eine IPv6? Ich glaub nicht...

2a00:1450:4001:801::1017 	fra07s28-in-x17.1e100.net 	684 	411 	1,095 	5 mins, 59 secs
2a00:1450:4001:80a::1018 	fra02s21-in-x18.1e100.net 	548 	308 	856 	6 mins, 11 secs
2a00:1450:4001:80a::1009 	fra02s21-in-x09.1e100.net 	4,916 	3,530 	8,446 	9 mins, 47 secs
2a00:1450:4001:80a::101a 	fra02s21-in-x1a.1e100.net 	3,293 	15,385 	18,678 	10 mins, 13 secs

...wenn das so weiter geht, müssen wir wohl eine freie IPv6 von Google abkaufen.
Bei denen macht echt nur ein URL oder DNS Filter Sinn.

 

[PeterPawn]

...wenn das so weiter geht, müssen wir wohl eine freie IPv6 von Google abkaufen.

Mist, werden die auch schon wieder knapp ?

Bei mir

dig @ns4.google.com www.google.de any
...
;; QUESTION SECTION:
;www.google.de.                 IN      ANY

;; ANSWER SECTION:
www.google.de.          300     IN      A       173.194.113.23
www.google.de.          300     IN      A       173.194.113.31
www.google.de.          300     IN      A       173.194.113.24
www.google.de.          300     IN      A       173.194.113.15
www.google.de.          300     IN      AAAA    2a00:1450:4001:808::101f

;; Query time: 40 msec
;; SERVER: 216.239.38.10#53(216.239.38.10)
;; WHEN: Sat Jun 21 11:19:15 CEST 2014
;; MSG SIZE  rcvd: 123

und selbst bei Abfrage mit AAAA kommt nur eine einzelne IPv6 zurück.

Woraus speist sich Deine Auslistung ? Wenn ich mir die TTL in den Antworten von Google so ansehe, kann die letzte Spalte ja eigentlich kein age oder ttl sein.

 

[koyaanisqatsi]

1&1 Anschluss mit DualStack.
DNSServer: 2003:180:2::53 (aktuell genutzt für Standardanfragen)
Einfach im Firefox auf die Googlesuchfunktion geklickt.
Trace mit: darkstat (MIPS/MIPSEL Binary gibts hier im Forum)
Die letzte Spalte nennt sich: Last seen

 

[PeterPawn]

Einfach im Firefox auf die Googlesuchfunktion geklickt.
Trace mit: darkstat

Bei mir - wie aus dem letzten Beitrag ja schon zu sehen - direkte Abfrage des SOA-Servers - (vermutlich) über einen Dualstack-Anschluß von KDG.

Aber daß Google Lastverteilung anhand der Quelladresse einer DNS-Abfrage macht, ist ja bekannt ...

Und so ergibt dieselbe Abfrage über einen T-DSL-Anschluß

central:~ # dig @ns4.google.com www.google.de any

; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> @ns4.google.com www.google.de any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18947
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.google.de.                 IN      ANY

;; ANSWER SECTION:
www.google.de.          300     IN      A       173.194.116.191
www.google.de.          300     IN      A       173.194.116.184
www.google.de.          300     IN      A       173.194.116.175
www.google.de.          300     IN      A       173.194.116.183
www.google.de.          300     IN      AAAA    2a00:1450:4001:80e::1017

;; Query time: 66 msec
;; SERVER: 216.239.38.10#53(216.239.38.10)
;; WHEN: Sat Jun 21 11:49:53 CEST 2014
;; MSG SIZE  rcvd: 123

damit ist das "vermutlich" oben hinfällig, es muß vorher KDG gewesen sein.

Für das erfolgreiche Blockieren der Auflösung würde wohl schon das Blacklisting der am jeweiligen Anschluß für www.google.de gelieferten Serveradressen ausreichen (wir reden ja nicht von einem Menschen, der sich dann eben andere Wege suchen würde). Auch alles andere, was bei einer Google-Suche da noch mit GA, Advertising usw. passiert (damit dürften einige Deiner Adressen zusammenhängen), setzt ja zumindest die erfolgreiche Auflösung der Suchmaschinen-Adresse voraus, damit die Suche überhaupt gestartet werden kann.

Hast Du die Adressen schon mal über mehrere Tage an einem bestimmten Anschluß verfolgt ? Wenn ich das Query-Log meines Bind-Servers "grep"pe, ist offenbar der Google-DNS für einen bestimmten Provider (solange WAN-seitig halbwegs dasselbe Netzwerk-Segment bei der Adressierung verwendet wird, bei KDG gibt es da bei IPv4 sehr heftige Streuungen) relativ statisch und reagiert wahrscheinlich nicht auf eine konkrete Lastsituation bei den Suchmaschinen-Servern.

Vielleicht sollten wir uns in ein eigenes Thema verziehen, wenn wir das fortsetzen wollen ...

Aber ich bin ja auch kein Freund von IP-Blacklists, sie haben - schon geschrieben - diverse Nachteile. Das einzige, wo sie richtig gut funktionieren, ist ein IPS, was Stück um Stück die Adressen blockiert, von denen Angriffe erfolgen. Insofern helfen sie - für mich - eher beim Blockieren von eingehendem als von ausgehendem Verkehr, was ja das Problem des TE war.

 

[alis]

Bei mir wird es jetzt wohl auf einen lokalen DNS Server hinauslaufen, mit dem ich gleich noch andere Werbung filtere. Macht so etwas auf der Fritzbox Sinn oder sollte man da einen separaten Server für benutzen?
Auch wenn es nur einzelne IPs sind, es ist doch schon eher nervig, dort auf Änderungen zu reagieren.

 

[koyaanisqatsi]

Schade das dem LG wohl nicht ein Proxy zugewiesen werden kann.
Denn auch einen Proxy muss HTTPS die URL bekanntgeben.
Beim OpenELEC XBMC Mediacenter der einen alten PHILIPS LED FlatTV in ein Smart verwandelt, geht sowas.
Ich lass als filternden Proxy den hier auf der Box laufen: tinyproxy
Wenn der lokal benutzt wird, dann ist erstmal die Fritz!Box der Nameserver, bevor ein anderer befragt wird.
So ist es sogar möglch, die Fritz!Box hosts als Umleitung gegen Hartnäckige Namen einzusetzen.
Eine Beispielfilterliste gefällig?

googleadservices.[a-z]{2,4}
google-analytics.[a-z]{2,4}
googlesyndication.[a-z]{2,4}

...sieht komisch aus, weil der letzte Part ein reulärer Ausdruck ist.
(Ihr merkt bestimmt, ich mag Google nicht sonderlich.)

Und so sieht ein IPv4 Nummernfilter aus...

[h,f]{1,1}[t]{1,2}[p]{1,1}[s]{0,1}[:]{1,1}[/]{2,2}[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}

(http:// ftp:// https:// ftps://)
Für IPv6 bin ich noch am knobeln.


Warnung: Ohne Filter für alle möglichen lokalen Geräte nicht fürs Internet freigeben.
Ein Proxyuser aus dem Internet käme sonst in dein Heimnetz.
Dem kann einfach mit den erlaubten Hosts entgegengewirkt werden...
tinyproxy.conf

Allow 85.183.32.244
Allow 192.168.178.0/24

Alle anderen werden dann abgewiesen.

 

[PeterPawn]

Bei mir wird es jetzt wohl auf einen lokalen DNS Server hinauslaufen, mit dem ich gleich noch andere Werbung filtere.

Du schreibst ja am Anfang, daß Du eine solche Filterung bereits in Verwendung hattest ... da wirst Du dann wissen, wie weit Du gehen kannst/darfst.

Ich hatte bei mir mit der Holzhammer-Methode keinen bzw. nicht den erwarteten Erfolg.

Wenn ich blind alles filtere, was zu de.lgtvsdp.com gehen soll, fallen auch solche Konversationen unter den Tisch:

GET /rest/sdp/v2.0/c1.0/authentication.xml HTTP/1.1
Host: DE.lgtvsdp.com
Accept: */*
Content-Length:0
X-Device-ID:UFv...
X-Device-Product:BROADBAND DTV 3
...
User-Agent:Mozila/4.0

HTTP/1.1 200 OK
Date: Fri, 20 Jun 2014 17:20:20 GMT
Server: Apache
X-Powered-By: Servlet 2.4; JBoss-4.3.0.GA_CP06 (build: SVNTag=JBPAPP_4_3_0_GA_CP06 date=200907141446)/JBossWeb-2.0
X-Server-Time: 140...
Set-Cookie: JSESSIONID=D2B...node_sdp17; Path=/
Content-Length: 320
Connection: close
Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><authentication><deviceSecret>sxa...fA==</deviceSecret><sessionID>VR...XM=</sessionID></authentication>

(man beachte den User-Agent beim Request )

Wenn dieser Aufruf (kurz nach dem Einschalten) nicht erfolgreich abgeschlossen werden kann, verhält sich mein Gerät so, als hätte es gar keine funktionierende Internet-Anbindung (nicht mal HbbTV geht dann).

Da muß man also eine - mehr oder weniger "stateful" - Filterung bauen ... wie gesagt, bei meinem Gerät.

 

[PeterPawn]

(Ihr merkt bestimmt, ich mag Google nicht sonderlich.)

Nicht mehr lange, dann "tricksen" sie den Filter doch noch aus ...

Ich vermute mal, schon aus "marken- und/oder wettbewerbsrechtlichen" Gründen hat wohl niemand anders als Google Anspruch auf "google.berlin" und wie die "new gTLDs" alle heißen. Da mußt Du wohl - prophylaktisch - noch nachbessern ... 2-4 Buchstaben dürften nicht mehr in jedem Falle ausreichend sein.

Ich kenne auch den tinyproxy nicht ... macht der seinerseits vor der Anwendung des regexp eine Konvertierung von UC nach LC ?

Edit:

Und so sieht ein IPv4 Nummernfilter aus...

Hat der wirklich eine so verdrehte Syntax ('{0,1}', '{1,1}', '{n,n}' lassen sich sicherlich übersichtlicher darstellen, braucht er das so wg. eines eigenen Parsers ?) oder wolltest Du bloss im selben Schema bleiben ?

 

[koyaanisqatsi]

Erwischt, denn ich habe keine Ahnung was du mit UC und LC meinst.
Achso: groß/kleinschreibung
tinyproxy.conf

Filter "/var/media/NEW_LINK/mips/tinyproxy.filter"
FilterURLs On
FilterExtended On
FilterCaseSensitive Off
FilterDefaultDeny No

Ich kann dir den Filter zeigen und die Ausgabe im tinyproxy.log.
Filter

beeg.[a-z]{2,4}

tinyproxy.log

Jun 21 13:30:58 deepbase daemon.info tinyproxy[3845]: Connect (file descriptor 1): viento.fritz.box [192.168.178.9]
Jun 21 13:30:58 deepbase daemon.info tinyproxy[3845]: Request (file descriptor 1): CONNECT beeg.com:443 HTTP/1.1
Jun 21 13:30:58 deepbase daemon.notice tinyproxy[3845]: Proxying refused on filtered url "beeg.com:443"

BPjM:
Das BPjM Modul kennt zwar die HTTP Seite kann aber HTTPS nicht filtern.

 

[alis]

Du schreibst ja am Anfang, daß Du eine solche Filterung bereits in Verwendung hattest ... da wirst Du dann wissen, wie weit Du gehen kannst/darfst.

Ich hatte bei mir mit der Holzhammer-Methode keinen bzw. nicht den erwarteten Erfolg.

Wenn ich blind alles filtere, was zu de.lgtvsdp.com gehen soll, fallen auch solche Konversationen unter den Tisch:

GET /rest/sdp/v2.0/c1.0/authentication.xml HTTP/1.1
Host: DE.lgtvsdp.com
Accept: */*
Content-Length:0
X-Device-ID:UFv...
X-Device-Product:BROADBAND DTV 3
...
User-Agent:Mozila/4.0

HTTP/1.1 200 OK
Date: Fri, 20 Jun 2014 17:20:20 GMT
Server: Apache
X-Powered-By: Servlet 2.4; JBoss-4.3.0.GA_CP06 (build: SVNTag=JBPAPP_4_3_0_GA_CP06 date=200907141446)/JBossWeb-2.0
X-Server-Time: 140...
Set-Cookie: JSESSIONID=D2B...node_sdp17; Path=/
Content-Length: 320
Connection: close
Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><authentication><deviceSecret>sxa...fA==</deviceSecret><sessionID>VR...XM=</sessionID></authentication>

(man beachte den User-Agent beim Request )

Wenn dieser Aufruf (kurz nach dem Einschalten) nicht erfolgreich abgeschlossen werden kann, verhält sich mein Gerät so, als hätte es gar keine funktionierende Internet-Anbindung (nicht mal HbbTV geht dann).

Da muß man also eine - mehr oder weniger "stateful" - Filterung bauen ... wie gesagt, bei meinem Gerät.

Um ehrlich zu sein, ist das gerade mein Problem. Ich habe testweise mal den DNS Server von meinem Fernseher auf einen lokalen umgebogen. de.lgtvsdp.com darf scheinbar nicht blockiert werden, sonst geht nichts mehr. Dann kann ich wohl nur die anderen Werbenetzwerke blockieren. Alles ziemlich unzufriedenstellend, leider.

 

[PeterPawn]

Filter "/var/media/NEW_LINK/mips/tinyproxy.filter"
FilterURLs On
FilterExtended On
FilterCaseSensitive Off
FilterDefaultDeny No

Das "FilterCaseSensitive Off" dürfte der Grund sein, wenn das sowohl für "DE.lgtvsdp.com" als auch "de.lgtvsdp.com" funktioniert.

Vorher hast Du etwas davon geschrieben, daß mit tinyproxy auch DNS-Abfragen über den Proxy gehen ... dann sollte es also ein "echter" SOCKS-Proxy sein. Wenn der jetzt auch noch DNS-Abfragen durch eigene Antworten ersetzen kann (quasi als DNS-Spoofing), dann sehe ich mir den für "box only"-Installationen tatsächlich noch einmal an ... manchmal hilft ja auch ein Proxy.

Wobei ich z.B. beim iPhone zwar wüßte, wo/wie ich einen HTTP-Proxy automatisch/manuell konfiguriere ... aber die komplette Kommunikation über einen Proxy umzuleiten, klappt m.W. auf einem "non jailbroken" Gerät nicht. Da relativiert sich dann der Sinn beim Vergleich der Fritz!Box-Filterung vs. tinyproxy vs. "große" Lösung (mit Kombination mehrerer Verfahren) leider immer wieder.

Wenn ich schon einem iOS-Gerät (wobei die "Schuld" für mich da eher beim iOS liegt) nicht beibringen kann, daß die Fritz!Box - auch wenn sie anderes in ihren IPv6-RAs behauptet - eigentlich nicht direkt als IPv6-Gateway ins Internet zu betrachten ist, dann kommuniziert am Ende jedes Gerät auf seinem eigenen Weg mit dem Internet und man kommt mit der Pflege der verschiedenen Filter überhaupt nicht mehr hinterher.

Das BPjM Modul kennt zwar die HTTP Seite kann aber HTTPS nicht filtern.

Ist halt ein schmaler Grat zwischen der Blockade "jugendgefährdender Medien" und einer "Zensur" des Internets. Da muß man Kompromisse machen.

Ich fände es persönlich nur besser, wenn AVM zusammen mit der "Kindersicherung" (egal welche Komponenten man davon verwendet) auch immer noch darauf aufmerksam machen würde, daß diese durchaus ihre Schwächen hat und Eltern nicht nach dem Motto "Ich habe doch die KiSi eingeschaltet, da kann nichts passieren." ihre ureigenste Verantwortung an eine Software-Lösung delegieren sollten (leider zu oft schon erlebt).

So, jetzt sind wir aber meilenweit vom eigentlichen Thema weg ... und dem TE kann man offenbar doch nur mit einer eher komplexen Konfiguration aus mehreren Filtern inkl. DNS-Spoofing und einer speziellen iptables-Chain, dynamisiert mit ipset-Tables, helfen.

Bei mir läuft das alles auf einem kleinen Server und der Fernseher kommuniziert immer nur mit diesem - das gibt dann bei der Konfiguration der LG-Fernbedienungs-App für Tablet/Smartphone noch richtig Probleme, wenn die in unterschiedlichen VLANs stecken.

Ansonsten variiert es sicherlich von Modell zu Modell und mit den persönlichen Anforderungen/Interessen, wonach man jeweils filtern muß und will ... ich gebe mich hier dann geschlagen. Ohne langwierige Analyse von (fremden) Netzwerk-Mitschnitten findet man so und so nicht alles bzw. kann man nicht helfen ... und das ist mir zu viel, solange keine konkrete Fragestellung vorliegt.

 

[koyaanisqatsi]

Es ist tatsächlich so, dass mich tinyproxy davon abhält VPN zu benutzen.
Vorallem deswegen, weil sich das so anfühlt als wenn ich im lokalen Netz unterwegs bin.
Allerdings unverschlüsselt, aber über einen nicht üblichen Port.
Das meiste von den Infos zur Konfiguration kommt hier aus dem Forum.
Allerdings nicht diese Info:

ftp_proxy='http://192.168.178.1:8088'
http_proxy='http://192.168.178.1:8088'

Sind diese Umgebungsvariablen auf der Box gesetzt (z.B. ~/.profile), benutzen auch wget, curl und Co den Proxy.
(Wenn auf der Box gestartet)
Das sieht man z.B. wenn curl auf den tinyproxy Namen losgelassen wird...
tinyproxy.conf

StatHost "proxy.in"

...dann wolln wir mal...

curl proxy.in
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head><title>tinyproxy version 1.8.3 run-time statistics</title></head>
<body>
<h1>tinyproxy version 1.8.3 run-time statistics</h1>
<p>
Number of open connections: 4294967277<br />
Number of requests: 25680<br />
Number of bad connections: 4229<br />
Number of denied connections: 1809<br />
Number of refused connections due to high load: 0
</p>
<hr />
<p><em>Generated by tinyproxy version 1.8.3.</em></p>
</body>
</html>

...Number of open connections? Das glaub ich aber nicht. Bug!
Wenn der Proxy gestoppt wurde, meckern die sofort...

wget http://localhost
Connecting to 192.168.178.1:8088 (192.168.178.1:8088)
wget: can't connect to remote host (192.168.178.1): Connection refused

Würden eth0 - eth3 oder lan sich auch daran halten, wäre die Angabe der Proxies bestimmt auch nicht mehr nötig.
(Als System oder Browserproxy auf den Klients)

Gretchenfrage:
Können die Proxyumgebungsvariablen so ins Fritz!Box Environment eingeimpft werden, dass sie auch auf Systemebene benutzt werden/können?
Wenn ja, wie? (/var/flash/featovl.cfg, /etc/init.d/rc.conf)
/var/flash/featovl.cfg

ftp_proxy=http://192.168.178.1:8088
http_proxy=http://192.168.178.1:8088
no_proxy=localhost

rc.conf (betreffender Auschnitt)

##########################################################################################
## ovl
##########################################################################################
if ! checkempty /var/flash/featovl.cfg 2>/dev/null ; then
for featovl in `cat /var/flash/featovl.cfg`; do
echo "overwrite feature ${featovl}"
export ${featovl}
done
fi

Ausgabe beim einloggen (telnet/ssh)

BusyBox v1.19.3 (2012-08-07 18:33:02 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

overwrite feature ftp_proxy=http://192.168.178.1:8088
overwrite feature http_proxy=http://192.168.178.1:8088
overwrite feature no_proxy=localhost
ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt

Ok, schade nur, die Klienten interessiert das leider nicht.

 

[alis]

Ansonsten variiert es sicherlich von Modell zu Modell und mit den persönlichen Anforderungen/Interessen, wonach man jeweils filtern muß und will ... ich gebe mich hier dann geschlagen. Ohne langwierige Analyse von (fremden) Netzwerk-Mitschnitten findet man so und so nicht alles bzw. kann man nicht helfen ... und das ist mir zu viel, solange keine konkrete Fragestellung vorliegt.

Ich gebe mich hier auch geschlagen Ihr habt mir noch eine Menge Inspiration für einen ruhigen Sonntag gegeben, aber derzeit ist mir der Aufwand zu hoch. Die SmartTV Funktionen sind sowieso langsam und schlecht, da blockiere ich lieber gleich alles und nutze nur meinen AppleTV. Vielen Dank für die Hilfe!

 

[GokuSS4]

und meinst du dein AppleTV telefoniert nicht?

 

[alis]

Zumindest überträgt er nicht, was ich gerade im Fernsehen schaue und welche Dateien ich so in meinem Heimnetzwerk rumliegen habe. Wenn ich über den AppleTV einen Film ausleihe oder dort eine App benutze, wird es logischerweise gespeichert, alleine schon für die Rechnung. Das wäre für mich beim Fernseher auch in Ordnung.

 

[GokuSS4]

Sei dir da mal nicht so sicher

 

[HabNeFritzbox]

Bei iTunes, Maxdome und co wird natürlich geloggt was man schaut da man ja Lizenzen erwirbt bei Abruf.