Sitat av
mroek
Lykke til. Jeg gjorde også det (pakkedumpet på begge sider), men fant ingenting åpenbart. Jeg må innrømme at jeg gikk litt lei også, men jeg er fremdeles interessert i å vite hva det er som er trikset, om du finner ut av det. Problemet er jo at når den først har provisjonert seg, så får du ikke sjekket det på nytt, da det er en engangsgreie.
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);
- ICMPv6 NS/RS-meldinger
- 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").
- IGMPv2 til 239.255.255.250 (SSDP)
- 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)
- DNS-oppslag av 2.android.pool.ntp.org
- Flere SSDP-meldinger (NOTIFY). Ser fortsatt ut som UPnP-åpninger.
- 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)
- Sender deretter SSDP-meldinger, denne gangen M-SEARCH (og ikke NOTIFY).
- 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").
- Deretter flere SSDP-meldinger, igjen M-SEARCH.
- Sender deretter IGMPv2-leave til 224.0.0.2 for gruppene 0.0.0.0 (general) og 239.193.4.179.
- DNS-oppslag av tmu02.services.altibox.net (A-record 213.167.98.14).
- STUN-forbindelse opprettes mot 213.167.98.14 (tmu02.services.altibox.net)
- Flere SSDP-meldinger
- 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
- STB-en fortsetter kryptert TCP-kommunikasjon med 213.167.98.14.
- 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.
- TCP-sesjonen mot 213.167.98.14 lukkes.
- Ny STUN-tilkobling mot 213.167.98.14 (opprettholder nok bare eksisterende tilkobling; samme src/dst-porter).
- 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å).
- 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.
- Ny refresh av STUN.
- Ny kryptert TCP-forbindelse mot 213.167.98.14. Denne lukkes og åpnes gjentatte ganger, noen ganger kombinert med flere RSL- og IPA-meldinger.
- DNS-oppslag av tviptveds.services.altibox.net (A-records 172.21.33.7 og 172.21.35.7).
- 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.
- DNS-oppslag av gmtviptvupg02.services.altibox.net (A-record 172.21.33.78).
- 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
- Ny STUN-refresh.
- 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)
- Ny kryptert TCP-forbindelse mot 213.167.98.14. Lukkes og åpnes gjentatte ganger.
- DNS-oppslag av digitviptvepg05.services.altibox.net (A-record 172.21.35.12), etterfulgt av TCP-forbindelse mot dst-port 33207.
- TCP-pakker/sesjoner lukkes og opprettes mot både 213.167.98.14 og 172.21.35.12.
- Gjør deretter HTTP GET mot "http://digitviptvepg05.services.altibox.net:33200/EPG/HDUI/index.html?1504890909882".
- 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).
- 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)
- Gjør på et tidspunkt HTTP GET mot "http://services.wmdrm.windowsmedia.com/SecureClock/?Time".
- 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).
- 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.
Sist endret av jockek; 14. september 2017 kl. 11:32.