View Single Post
@KydeX: Neida, det var litt tilfeldig at jeg oppdaget dette. Men det viste seg å være noe mer interessant enn først antatt. :-)

Jeg satte opp min egen FTP-server, og snudde trafikken til denne spesifikke IP-adressen dit, fordi jeg rett og slett ville se hva som skjedde. Etter litt om og men for å få det til å virke, så ser jeg nå at dekoderne laster opp loggfiler til denne FTP-serveren. Det er snakk om standard CSV, så filene kan leses i en vanlig teksteditor. Dekoderne lager en ny fil hver time, og har tydeligvis en buffer på 4 slike filer, for da de først klarte å laste opp filene til min FTP, så fikk jeg 4 filer fra hver dekoder. Om jeg lar FTP-serveren stå oppe, så antar jeg at det kommer en ny fil hver time fremover.

Her er starten på en slik fil:

Kode

STBID, 00000000000810101010xxxxxxxxxxxx
PhyMemSize, 1982668
StorageSize, 8388608
OUI, 00E0FC
SoftwareVersion, V100R003C85LALTX1SPC300B011
ConfigFileVersion, 
HardwareVersion, Q22_pub_alt
Startpoint, 20170829152006
Endpoint, 20170829162006
x'ene i STBID linje er MAC-adressen til dekoderen, men jeg har altså sensurert den. Hva de to size-parametrene representerer er ikke godt å si, men det er kanskje naturlig å tippe RAM og flash, men det er nok neppe angitt i bytes, til det er tallene for små.

De fleste parametrene i filen er dessverre null, som f.eks:

Kode

BootUpTime, 0
PowerOnTime, 0
ChannelZappingPerform, 0.0
ChannelZappingBestPerform, 0.0
ChannelZappingWorstPerform, 0.0
Det er en interessant parameter som ikke er null, og det er denne:

Kode

PacketsLost, 504948578
Tallet er jo varierende fra logg til logg, men jeg synes det ser ut som et veldig stort tall. Det ser også ut for at tallet er identisk i to av de fire loggene fra den ene dekoderen, så da kan det ikke være et tall for reelt pakketap, i hvert fall.