Posts Tagged ‘Flooding’

Montag, 16. Dezember 2019

Netflix mit zehntausenden DNS-Queries pro Tag von meinem Sony KD-55AF8

Link zu diesem Artikel

Seit ein paar Monaten steht in unserer Wohnung der erste richtig „smarte“ TV, ein Sony KD-55AF8, auf welchem mittlerweile Android TV 8.0 installiert ist.

Seit gestern analysiere ich die DNS-Queries, die von Netzwerkgeräten im LAN an den lokalen DNS-Forwarder gestellt werden sowohl quantitativ (welche Domains werden am meisten aufgelöst, welches Gerät setzt die meisten Queries ab und in welcher Stunde des Tages gibt es die meisten Queries) sowie qualitativ (werden von SANS als Suspicious eingestufte Domains aufgelöst, was ein Zeichen für Malware-Befall sein könnte). Ich war nicht schlecht überrascht, dass ein TV-Gerät, welches allerhöchsten zwei von 24 Stunden im Tag „läuft“, der Spitzenreiter aller Queries ist. Ich zählte innerhalb von 24 Stunden sage und schreibe 90’498 Queries. Gefolgt wurde der TV vom Server selber, auf welchem der DNS-Server läuft mit 72’411 Queries. Auf Platz drei dann ein Client mit noch 7’162 Queries.

Heute nun nahm mich Wunder, was zum Teufel der TV ständig abzufragen hat. Hier das Resultat der Analyse der named-Logs vom Vortag (10.1.2.3 ist die (fiktive) IPs meines TVs):

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
   1284 clients3.google.com
   1220 connectivitycheck.gstatic.com
   1196 www.google.com
   1195 mtalk.google.com
    994 nrdp52-appboot.netflix.com
    324 events.cid.samba.tv
    162 us.edge.bamgrid.com
    142 watch.product.api.espn.com
    118 clients4.google.com
    109 androidtvchannels-pa.googleapis.com
    105 footprints-pa.googleapis.com
     91 fling.cid.samba.tv
     83 www.youtube.com
     52 mdh-pa.googleapis.com
     41 clientservices.googleapis.com
     37 www.googleapis.com
     35 play.googleapis.com
     34 platform.cid.samba.tv
     28 android.googleapis.com
     13 www.gstatic.com
     12 youtubei.googleapis.com
     10 static.doubleclick.net
      7 www.netflix.com
      7 android.clients.google.com
      6 api-cdn.arte.tv
      5 lh3.googleusercontent.com
      5 antv-26-sony-bravia4kgbatv3-414000300.api.amazonvideo.com
      4 sdk.hockeyapp.net
      4 middleware.7tv.de
      4 devices.ted.com
      4 cdn-gl.imrworldwide.com
      4 android.googleapis.com
      3 zdf-cdn.live.cellular.de
      3 geoloc.arte.tv
      3 geocheck.sim-technik.de
      3 config.ioam.de
      3 cdn.meta.ndmdhs.com
      3 bam-sdk-configs.bamgrid.com
      2 sdk.imrworldwide.com
      2 api.meta.ndmdhs.com
      1 www.sony.net
      1 www.sony-asia.com
      1 voledevice-pa.googleapis.com
      1 update.biv.sony.tv
      1 time.android.com
      1 static-cdn.arte.tv
      1 sportscenter.api.espn.com
      1 secure.espncdn.com
      1 safebrowsing.googleapis.com
      1 r4---sn-1gieen7e.gvt1.com
      1 people-pa.googleapis.com
      1 ocsp.int-x3.letsencrypt.org
      1 metadata.erabu.sony.tv
      1 log.core.cloud.vewd.com
      1 isrg.trustid.ocsp.identrust.com
      1 images.erabu.sony.tv
      1 fls-na.amazon.com
      1 cloudfront.xp-assets.aiv-cdn.net
      1 cert-cdn.meta.ndmdhs.com
      1 cdn.espn.com
      1 browserjs-legacy.core.cloud.vewd.com
      1 broadband.espn.com
      1 bravia-cfgdst-ore-pro.bda.ndmdhs.com
      1 bdcore-apr-lb.bda.ndmdhs.com
      1 app-measurement.com
      1 api.erabu.sony.tv
      1 api.auth.adobe.com
      1 ajax.googleapis.com

Netflix führt die Statistik unangefochten an:

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn | grep -i "netflix\|nflx"
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
    994 nrdp52-appboot.netflix.com
      7 www.netflix.com

Von den täglich über 90’000 Queries entfallen über 90 Prozent auf Netflix-Domains:

$ cat queries.log.1 | grep 10.1.2.3 | grep -i "netflix\|nflx" | wc -l
84114

Dabei schauen wir — wenn überhaupt — mit der Netflix-App auf dem Apple TV 4K mit einer anderen IP Netflix, und nie mit der Android TV App.

Netflix, shame on you! Die Frage, wieso die Netflix-App das macht, konnte ich bis jetzt noch nicht beantworten, werde es hier aber nachtragen, sollte ich es erfahren.

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT

10 Kommentare | neuen Kommentar verfassen

Sonntag, 10. Juni 2018

Init7 TV7: Turris Omnia, UniFi Switch, Multicast und IGMP Snooping

Link zu diesem Artikel

Seit der Ankündigung von Init7 verwende ich gelegentlich deren TV7-Angebot, welches ein ganz „normales“ Multicast IPTV ist.

Bei der Konfiguration des Services bei einer Bekannten, welche ich mit einem Ubiquiti EdgeRouter ER-X ausgestattet habe, musste ich feststellen, dass das Netzwerk wie vom ISP angedroht mit Multicast geflutet wird, wenn man einen TV-Sender schaut.

Das spürt man sehr gut, wenn man über den am ER-X angeschlossenen Ubiquiti UniFi AP-AC-LR surfen will oder bspw. eine SSH-Verbindung aufgebaut hat. Zwischen dem Druck einer Taste und dem erscheinen des Buchstabens in der Shell gibt es eine spürbare Verzögerung.

Damals war ich der Meinung, dass mein Turris Omnia hier zu Hause mit IPTV Multicast zu schlage kommt, weil ich solche Probleme initial nicht wahrnahm. Doch auch mein Netzwerk wird in Mitleidenschaft gezogen, und auch hier spüre ich es primär mittels Verbindungsproblemen mit dem UniFi Access Point. Da ich direkt nach dem Turris Omnia einen UniFi Switch US-8-60W angeschlossen habe und die Interface-Statistiken mit Cacti aufzeichne, kann ich das Problem einfach visualisieren — an Hand des Matches der Schweizer Nationalmannschaft gegen Japan am Freitag, 8. Juni 2018 ab 19 Uhr (wir schalteten uns ein paar Minuten später zu):

Man sieht auf den Graphen sehr gut, dass Multicast auf allen Interfaces des Switches einschlägt, egal, ob das Netzwerkgerät dahinter den Stream schaut oder nicht.

Was ich jetzt zudem auch noch realisiere: Meine Sonos PLAYBASAE, der SUB und die beiden Sonos PLAY:1 hatten Probleme mit der Audio-Wiedergabe von IPTV-Streams. Ich dachte, dass dies entweder an den Streams selber oder aber den Apps liegt, welche ich verwendet habe. Mir schwant nun aber, dass die PLAYBASE das Audio auf Grund des Multicast-Floodings eifach nicht schnell genug über den UniFi Access Point (d.h. per WLAN) zum SUB und den zwei PLAY:1 senden konnte.

Der Match lief bei uns über die App iPlayTV auf dem Apple TV 4 (mit Ethernet am UniFi-Switch angeschlossen) via HDMI auf unserem Panasonic Plasma in der Stube. Hierzu verwende ich udpxy, welches auf einem Linux-Server Intel NUC läuft, welcher ebenfalls am UniFi-Switch angeschlossen (dies nicht aus Spass; iPlayTV kommt mit der M3U8 respektive dem Multicast-Stream direkt von TV7 irgendwie nicht klar). D.h. udpxy empfängt Multicast, wandelt es in einen Unicast-Stream um und sendet diesen an den Apple TV.

Mitten im Spiel entschied ich mich, den Apple TV direkt an einen der vier freien Switch-Ports des Turris Omnia zu hängen (jetzt, als ich diese Zeilen schreibe, realisiere ich gerade, dass ich eigentlich den NUC dort hätte anhängen sollen, da er ja der Multicast-Empfänger war — und nicht den Apple TV). Das änderte an der Multicast-Flut nichts (wie auch, der Multicast-Empfänger war immer noch am Switch angehängt — ich Depp!).

Der Turris Omnia aber hat gemäss Kommandozeile IGMP-Snooping aktiviert:

$ cat /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
1

Quellen: How can I enable IGMP Snooping in OpenWRT? sowie IPTV / UDP multicast

Schlussendlich nach viel Googlen dann die Erkenntnis: Ich musste IGMP Snooping noch auf meiner Ubiquiti-Netzwerkinfrastruktur aktivieren! Das macht man über den UniFi-Controller:

  1. Login auf die Web-Oberfläche des UniFi-Controllers
  2. Settings
  3. Networks
  4. Edit
  5. [x] Enable IGMP Snooping

Et voilà! Auf den Cacti-Graphen sind man in der Detail-Ansicht sehr schön, dass ich um spätestens 20:45 Uhr IGMP Snooping auf dem Switch aktiviert hatte:

Der Multicast-Stream mit locker 15 Mbit/s kommt immer noch über den Router auf dem Switch rein (Port 1, mit „TURRIS OMNIA“ bezeichnet), doch er wird nur noch an Switch-Port 3 weitergereicht, an welchem der NUC hängt, auf welchem udpxy läuft und den Multicast-Stream in Unicast umwandelt. Die anderen Ports werden mit Multicast sinnvollerweise nicht mehr bedient, und deshalb bricht die blaue Linie (Outbound-Traffic, d.h. in Richtung des angeschlossenen Netzwerkgerätes) fast gegen Null ein.

Was ich jetzt noch mache: Ich hänge den NUC auch noch direkt an einen freien Ethernet-Port des Turris Omnia. Dann gibt es eigentlich keinen Grund mehr, wieso Multicast-Traffic überhaupt bis zum UniFi-Switch gelangen sollte (ausser ich streame diesen bspw. auf meinem per Ethernet angebundenen iMac im Büro).

Tags: , , , , , , , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 31. Mai 2018

Init7 TV7: Installation mit einem Ubiquiti Edgerouter X SFP

Link zu diesem Artikel

(Folgeartikel zum Artikel Init7 TV7: Installation mit einem Turris Omnia-Router)

An einem Zweitstandort betreibe ich einen Ubiquiti Edgerouter X SFP (Firmware v1.10.0) mit einem offiziellen FlexOptix-Transceiver von Fiber7. Damit dieser Router IPTV-Multicast ins LAN weiterleitet, waren folgende Anpassungen an der Konfiguration nötig (hat mich 90 Minuten meines Lebens gekostet):

Firewall

Auf rudimentärem Deutsch: Lasse IGMP sowie Multicast UDP durch die Firewall gegen das Internet

...
firewall {
    ...
    name WAN_IN {
        ...
        rule 4 {
            action accept
            description "Allow IGMP (max)"
            log disable
            protocol igmp
        }
        rule 5 {
            action accept
            description "Allow Multicast"
            destination {
                address 224.0.0.0/4
            }
            log disable
        }
    }
    name WAN_LOCAL {
        ...
        rule 4 {
            action accept
            description "Allow IGMP"
            log disable
            protocol igmp
        }
        ...
    }
    ...
}
...

IGMP Proxy

Auf rudimentärem Deutsch: Empfange IGMP-Traffic aus dem Internet und leite ihn in das LAN weiter.

...
protocols {
    igmp-proxy {
        interface switch0 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
        interface eth5 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
    }
    ...
}

Multicast-Status abfragen

Um zu überprüfen, ob Multicast grundsätzlich funktioniert, loggt man sich per SSH auf den Router ein und gibt im CLI folgende Befehle ein:

$ show ip multicast interfaces 
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
switch0            0.00b             0       31.17MB         24316        Y.Y.Y.1
eth5             31.17MB         24316         0.00b             0   X.X.X.X
$ show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
239.254.127.63  Y.Y.Y.5        eth5        switch0               1       116.00b      1
239.255.255.250 Y.Y.Y.50       eth5        switch0              56       17.61KB     56
239.77.3.21     77.109.129.16    eth5        switch0           37379       47.91MB      0

Die letzte Zeile war das Resultat, dass ich probehalber Dracula Untold auf Film 4 geschaut habe …

Nachtrag 1: Stream friert ein

Nach der Installation der TV7-App auf dem Apple TV (eigener Blog-Artikel zur App) musste ich entdecken, dass das Bild eines TV-Senders jeweils nach etwas mehr als 3 Minuten einfror (ich tippte nach mehreren Messungen auf ein Timeout von 200 Sekunden — und somit ein strukturelles Problem).

Recht schnell realisierte ich nach etwas Googlen, dass die Firewall-Regel 4 unter WLAN_LOCAL zwingend auch aktiviert werden muss. Diese hatte ich ursprünglich als überflüssig erachtet. Mein Fehler.

Meine Vermutung als IPTV-Laie: Diese (zusätzliche) Regel erlaubt ausgehende IGMP-Pakete. Wenn diese nicht an TV7 gesendet werden können (Heartbeat?), stellt TV7 den Multicast wieder ein. Sobald die Firewall-Rule aktiviert wurde, entfror sich das Bild und die Sendung lief weiter.

Nachtrag 2: Multicast flutet das Netzwerk

Obwohl die Streams nun auf dem Apple TV mit der offiziellen App problemlos laufen, habe ich einen schwerwiegenden Nachteil entdeckt, welcher bei meinem Turris Omnia nicht auftritt: Schaut man mit dem Apple TV einen TV7-Stream, wird das ganze LAN mit Multicast-Paketen geflutet. Dies beeinflusst meinen UniFi Access Point besonders, konnte ich doch einen spürbaren Lag zwischen Tastendruck und Anzeige des Buchstabens auf dem Bildschirm feststellen, wenn ich von meinem MacBook per WLAN per SSH auf einem Laptop im LAN verbunden war.

In meiner derzeitigen Konfiguration sendet der Edgerouter den eingehenden Multicast-Traffic an alle LAN-Interfaces weiter, die am switch0 hängen. Leider habe ich bis jetzt noch keine Lösung gefunden, wie man das auf einzelne Ports einschränken kann (ich brauche eigentlich nur den Apple TV- sowie den Laptop-Port, auf welchem udpxy läuft) respektive wie man IGMP-Snooping aktivieren kann, damit der Edgerouter selber realisiert, welches Gerät/welche Geräte im Netzwerk aktuell gerade Multicast-Streams abspielen möchte.

Links

Tags: , , , , , , , , , , ,
Labels: IT, Linux, Medien, Schweiz

4 Kommentare | neuen Kommentar verfassen