Jeg hadde en ny seanse, og dumpet både høyt og lavt. Først ved aller første tilkobling av STB-en (og da bak helt normal FMG). Deretter ved tilkobling nummer to, denne gang også bak FMG. Deretter en tredje gang, nå bak "custom" oppsett.

STB-en registrerte seg fint (fikk SMS), og fungerte fint både ved første og andre tilkobling. Flyttet deretter bak eget oppsett, men fikk da "klassikeren" nevnt tidligere i tråden; finfint bilde i 10-15 sekunder (eller deromkring), og så veldig hakkete (deretter feilmelding/sort skjerm). Dette skjedde konsekvent.

Etter kjapp analyse av pakkedump, så ser første gangs oppstart cirka slik ut (i kronologisk rekkefølge);

1. ICMPv6 NS/RS-meldinger
2. DHCP-request (etterfulgt av offer+ack), hvor Option-43 er satt det samme som observert tidligere i tråden ("Altibox-TMS-Server-Address:https://tmc.services.altibox.net:37020/acs").
3. IGMPv2 til 239.255.255.250 (SSDP)
4. SSDP-meldinger (NOTIFY). Ser ut som UPnP-åpninger, hvor den annonserer følgende URL i LOCATION-feltet; http://$IP_TIL_STB:49152/description.xml (får connection refused om jeg forsøker å hente denne ned manuelt, men mulig den bare er tilgjengelig i en begrenset periode, eller at den faktisk har noe pre-definerte ACL-er som gjør at den "må" være i 192.168.10.0/24-nettet)
5. DNS-oppslag av 2.android.pool.ntp.org
6. Flere SSDP-meldinger (NOTIFY). Ser fortsatt ut som UPnP-åpninger.
7. DNS-oppslag av gmtviptvupg.services.altibox.net (A-record 172.21.33.79), som den deretter gjør NTP-forespørsel mot (og får gyldig NTP-svar i retur)
8. Sender deretter SSDP-meldinger, denne gangen M-SEARCH (og ikke NOTIFY).
9. STB-en oppretter deretter TCP-forbindelse mot 213.167.98.11 (jeg aner ikke hvor den har denne IP-en fra -- jeg finner ikke noe åpenbart i SSDP-meldinger eller andre meldinger i forkant -- kan være hardkodet fra fabrikk (f.eks. der den henter ned ny software første gangen). Dst-port: 37000. Ser ut som den sender serienummer + modellnummer + noe annet (f.eks. ser jeg strengen "Q22_pub_alt").
10. Deretter flere SSDP-meldinger, igjen M-SEARCH.
11. Sender deretter IGMPv2-leave til 224.0.0.2 for gruppene 0.0.0.0 (general) og 239.193.4.179.
12. DNS-oppslag av tmu02.services.altibox.net (A-record 213.167.98.14).
13. STUN-forbindelse opprettes mot 213.167.98.14 (tmu02.services.altibox.net)
14. Flere SSDP-meldinger
15. STB-en oppretter deretter TCP-forbindelse mot 213.167.98.14. Dst-port 37021. Dette er starten på en TLS-handshake. Sertifikatet til serveren er signert av Go Daddy, og følgende FQDN-er er i SAN-listen;
    
    

    Kode

    digitviptvepg01.services.altibox.net
    digitviptvepg02.services.altibox.net
    digitviptvepg03.services.altibox.net
    digitviptvepg04.services.altibox.net
    digitviptvepg05.services.altibox.net
    digitviptvepg06.services.altibox.net
    digitviptvepg07.services.altibox.net
    digitviptvepg08.services.altibox.net
    digitviptvepg09.services.altibox.net
    digitviptvepg10.services.altibox.net
    digitviptvepg11.services.altibox.net
    digitviptvupg01.services.altibox.net
    digitviptvupg02.services.altibox.net
    digitviptvupg.services.altibox.net
    digitvottepg01.services.altibox.net
    digitvottepg02.services.altibox.net
    digitvottepg03.services.altibox.net
    digitvottepg04.services.altibox.net
    digitvottepg05.services.altibox.net
    digitvottepg06.services.altibox.net
    digitvottepg07.services.altibox.net
    digitvottepg08.services.altibox.net
    digitvottepg09.services.altibox.net
    digitvottepg10.services.altibox.net
    digitvottupg01.services.altibox.net
    digitvottupg02.services.altibox.net
    digitvottupg.services.altibox.net
    gmtviptvepg01.services.altibox.net
    gmtviptvepg02.services.altibox.net
    gmtviptvepg03.services.altibox.net
    gmtviptvepg04.services.altibox.net
    gmtviptvepg05.services.altibox.net
    gmtviptvepg06.services.altibox.net
    gmtviptvepg07.services.altibox.net
    gmtviptvepg08.services.altibox.net
    gmtviptvepg09.services.altibox.net
    gmtviptvepg10.services.altibox.net
    gmtviptvepg11.services.altibox.net
    gmtviptvupg01.services.altibox.net
    gmtviptvupg02.services.altibox.net
    gmtviptvupg.services.altibox.net
    gmtvottepg01.services.altibox.net
    gmtvottepg02.services.altibox.net
    gmtvottepg03.services.altibox.net
    gmtvottepg04.services.altibox.net
    gmtvottepg05.services.altibox.net
    gmtvottepg06.services.altibox.net
    gmtvottepg07.services.altibox.net
    gmtvottepg08.services.altibox.net
    gmtvottepg09.services.altibox.net
    gmtvottepg10.services.altibox.net
    gmtvottupg01services.altibox.net
    gmtvottupg02services.altibox.net
    gmtvottupg.services.altibox.net
    mqmc.services.altibox.net
    tmc.services.altibox.net
    tmu01.services.altibox.net
    tmu02.services.altibox.net
    tviptveds.services.altibox.net
    tviptvupg.services.altibox.net
    tvotteds.services.altibox.net
    tvottupg.services.altibox.net
    www.tvotteds.services.altibox.net

16. STB-en fortsetter kryptert TCP-kommunikasjon med 213.167.98.14.
17. Kommer en enkelt SSDP-melding (M-SEARCH), etterfulgt av mer kryptert trafikk mot 213.167.98.14, og deretter én enkelt SSDP-melding igjen (M-SEARCH). Denne danser skjer litt om-hverandre.
18. TCP-sesjonen mot 213.167.98.14 lukkes.
19. Ny STUN-tilkobling mot 213.167.98.14 (opprettholder nok bare eksisterende tilkobling; samme src/dst-porter).
20. STB-en oppretter ny TCP-forbindelse mot 213.167.98.14 (samme dst-port; 37021). Samme TCP-sesjon følges opp med RSL og IPA-meldinger (som ser ut til å være GSM/mobil-relatert, men har tydeligvis andre usecases også).
21. TCP-forbindelsen mot 213.167.98.14 lukkes, og en ny opprettes mot samme destinasjon. Flere RSL- og IPA-meldinger utveksles, før TCP-sesjonen igjen lukkes.
22. Ny refresh av STUN.
23. Ny kryptert TCP-forbindelse mot 213.167.98.14. Denne lukkes og åpnes gjentatte ganger, noen ganger kombinert med flere RSL- og IPA-meldinger.
24. DNS-oppslag av tviptveds.services.altibox.net (A-records 172.21.33.7 og 172.21.35.7).
25. STB-en oppretter TCP-forbindelse mot en av A-records returnert fra DNS. Dst-port 8082. TCP-forbindelsen resulterer i en HTTP GET mot "http://tviptveds.services.altibox.net:8082/EDS/jsp/upgrade.jsp?TYPE=Q22_pub_alt&MAC=$MAC_TIL_STB&USER=&VER=V100 R003C85LALTX1SPC300B011&CHECKSUM=11577" (som får "302 Found" i retur). Tilkoblingen lukkes.
26. DNS-oppslag av gmtviptvupg02.services.altibox.net (A-record 172.21.33.78).
27. STB-en oppretter TCP-forbindelse mot 172.21.33.78, dst-port 33600. Resulterer i HTTP GET mot "http://gmtviptvupg02.services.altibox.net:33600/UPGRADE/jsp/upgrade.jsp?TYPE=Q22_pub_alt&MAC=$MAC_TIL_STB&USER=&VER=V100 R003C85LALTX1SPC300B011&CHECKSUM=12245". Dette resulterer i en "200 OK", hvor fil med navn "config.txt" lastes ned. Innhold;
    
    

    Kode

    [FIRMWARE-FULL]
    Version=V100R003C85LALTX1SPC300B011
    FileName=Hi3798CV200_V100R003C85LALTX1SPC300B011_ALL_20170625_230636.zip
    FromVersion=0
    
    ForceUpdate=1

28. Ny STUN-refresh.
29. Gjør ny HTTP GET mot begge de to tidligere URL-ene over, med samme resultat/innhold. I alle tilfellene er det følgende User-Agent-streng som brukes;
    
    

    Kode

    Dalvik/2.1.0 (Linux; U; Android 5.1.1; Q22_pub_alt Build/LMY48W)

30. Ny kryptert TCP-forbindelse mot 213.167.98.14. Lukkes og åpnes gjentatte ganger.
31. DNS-oppslag av digitviptvepg05.services.altibox.net (A-record 172.21.35.12), etterfulgt av TCP-forbindelse mot dst-port 33207.
32. TCP-pakker/sesjoner lukkes og opprettes mot både 213.167.98.14 og 172.21.35.12.
33. Gjør deretter HTTP GET mot "http://digitviptvepg05.services.altibox.net:33200/EPG/HDUI/index.html?1504890909882".
34. Trafikk går på nåværende tidspunkt primært mot 172.21.35.12 (masse HTTP/HTTPS). Basert på noen av URL-ene kan det se ut som at den laster boot-image og annet (så den er midt i boot-prosessen).
35. Laster deretter flere HTML-ting (.js og .css-filer), og snakker også TCP/HTTPS med gmtviptvepg03.services.altibox.net (A-record 172.21.33.10). Sistnevnte ser ut som den henter film-postere fra. User-Agent-strengen er nå endret til følgende;
    
    

    Kode

    AppleWebKit/534.30(linux ARMv7;U;tur), AiB_STB_Hi3798CV200/16.2 (Huawei,Q22,Wired)

36. Gjør på et tidspunkt HTTP GET mot "http://services.wmdrm.windowsmedia.com/SecureClock/?Time".
37. Begynner deretter å snakke UDP mot 172.21.35.16, 172.21.33.68 og 172.21.33.85, samt mange andre, på varierende porter. Dette er nok selve TV-strømmen, da det virker som at src-ip endres etter hvert som man browser kanaler (som gir mening).
38. Går deretter en del TCP/HTTP-trafikk mot 172.21.36.17 og noen andre IP-er, som ser ut til å være relatert til film/trailere;
    
    

    Kode

    http://172.21.36.17/88888888/16/20170901/268460615/268460615.mpd?rrsip=172.21.34.17:80,rrsip=172.21.34.17:80,rrsip=172.21.36.17:80&zoneoffset=0&servicetype=0&icpid=SSPID&accounttype=1&limitflux=-1&limitdur=-1&accountinfo=<SNIP>&GuardEncType=2
    http://172.21.33.132/wh7f454c46tw479999618_1926254748/88888888/16/20170901/268460615/208089_trailer_HD_GuardiansoftheGalaxyVol2_ABR_400000_init.m4i?hw_dash_index=1&hw_dash=1

Ved andre gangs tilkobling (fortsatt bak FMG-en), så ser ting ganske likt ut. Forskjellene er, så vidt jeg kan se, som følger;

• Den kobler seg til 213.167.98.14 *før* den har opprettet STUN-tunellen. Dette gjør den først på et seinere tidspunkt.
• Den gjør ikke HTTP GET mot tviptveds.services.altibox.net / gmtviptvupg02.services.altibox.net (upgrade-greiene). Har ikke analysert hva som evt. trigget at den spurte om dette ved første gangs påkobling. Kan være begravd i de krypterte sesjonene.

Ved tilkobling bak eget utstyr, så er følgende observert;

• Det ser ut som det kommer en del flere TCP RST og TCP-Out-Of-Order. Dette er muligens relatert til et kjent problem med USG/EdgeRouter (EdgeOS), men jeg mener det bare var relatert til UDP (https://community.ubnt.com/t5/EdgeMA...e/td-p/1343012).
• Ellers ser det ut som det er ganske likt med "andre gangs tilkobling bak FMG".

Foreløpige konklusjoner;

• Ny TV-løsning (Huawei) ser ikke ut til å bruke multicast i det hele tatt (kun unicast).
• Ny TV-løsning ser ut til å kreve UPnP.
• STUN ser ut til å etableres i alle tre tilfeller.

Neste plan er dermed å skru på UPnP, samt evt. gjøre siste tweak på ACL-er/annet for å se om det kan gi bedre resultater.

Dersom dette ikke virker, så er planen å koble FMG-en bak eget oppsett (fremfor å koble eget utstyr bak FMG-en, siden man da ender opp med dobbel NAT). Gulroten er også at om dette virker, så kan jeg mest sannsynlig glemme hele TV-biten, og fremtidige oppdateringer vil fungere som om jeg kun hadde hatt FMG-en.

Planen er at jeg terminerer VLAN100-102 på egen switch (switch1). Der sender jeg VLAN100-101 videre på en trunk til en annen tilkoblet switch (switch2). VLAN102 trekker jeg inn på egen ruter. Bak egen ruter har jeg et eget VLAN40 tiltenkt TV-er, men som jeg nå gjenbruker som "VLAN102 mot FMG". Siden switchene jeg har ikke støtter VLAN-egress/ingress-rewrite (skrive om VLAN inn/ut på en port), så piper jeg ut VLAN40 som access på en port på switch1, og tas inn som VLAN102 på switch2 (som ikke har VLAN102 fra før av). Jeg kan dermed pipe ut VLAN100-102 mot FMG-en (bare at VLAN102 nå er NAT-et bak VLAN40 på egen ruter). Håpet er at dette er nok til at FMG-en tar en IP, og ellers fungerer finfint (den får internett og TV-VLAN). STB-er kan jeg dermed koble direkte til FMG-en, eller, dersom jeg ønsker, trekke kabel fra FMG-en og inn på en av switchene på det dedikert VLAN som jeg deretter kan trekke hvor jeg vil.

edit: okay, kan være SSDP-meldingene bare er annonsering av tjenester som STB-en har/tilbyr, men mulig M-SEARCH er relevant. Det kan også være at STUN-biten faktisk bruker hele TR-111-implementasjonen (eller deler av den, som krever støtte i FMG-en/ruteren). Det kan se slik ut basert på innholdet i STUN-meldingene, og dersom dette stemmer, så er vi i større grad «screwed», da jeg tipper det er svært få som har implementert støtte for dette i enterprise-rutere (da det er en veldig CPE-spesifikk tjeneste). Man kunne fint brukt STUN uten TR-111, så siden STUN-meldingene refererer spesifikt til TR-111, så mistenker jeg at dette er tilfellet, og at det er «manglende brikken».

Om jeg får virk i FMG-bak-egen-ruter-oppsett, så tenker jeg det er den beste av to verdener; 1) du slipper dobbel NAT på egne klienter/utstyr (kun STB-ene som får dobbel NAT), 2) du slipper å måtte oppdatere oppsett dersom nye subnett blir rutet via VLAN101 eller tilsvarende, 3) du slipper evt. performance-issues med FMG-en, da dette evt. bare påvirker STB-ene, 4) og sikkert masse andre fordeler.