Dacă ai un server NTP dedicat - gen Rohde & Schwarz, Meinberg, Symmetricom sau orice alt appliance cu receptor GPS - și într-o zi observi că afișează o dată din trecut cu 10-20 de ani, nu e un bug de software și nu e CentOS-ul vinovat. E aproape sigur un GPS Week Number Rollover, o limitare fundamentală a protocolului GPS care lovește periodic echipamentele care n-au primit update de firmware la timp.
Cum funcționează GPS-ul și de ce apare problema
Receptoarele GPS nu transmit o dată calendaristică în formatul la care ne-am obișnuit. Sateliții GPS transmit timpul ca două valori: un număr de săptămână (WN - Week Number) și numărul de secunde scurs din acea săptămână (TOW - Time of Week). Numărul de săptămână e stocat pe 10 biți în semnalul GPS civilian (L1 C/A), ceea ce înseamnă că poate reprezenta maximum 2^10 = 1024 valori, adică 1024 săptămâni - aproximativ 19.7 ani. Când contorul ajunge la 1023, următoarea săptămână e din nou 0. Asta se numește rollover.
Prima epocă GPS a început la 6 ianuarie 1980. Primul rollover a avut loc la 21 august 1999 (săptămâna 1024). Al doilea la 6 aprilie 2019 (săptămâna 2048). Al treilea va fi în jur de noiembrie 2038.
Receptoarele GPS moderne gestionează rollover-ul printr-o valoare hardcodată în firmware, numită pivot date sau rollover offset - practic firmware-ul știe în ce epocă trăiește și adaugă numărul corect de săptămâni la valoarea primită. Problema apare când firmware-ul e vechi și pivot data e înainte de rollover-ul din 2019: receptorul interpretează săptămâna 0 ca pe prima săptămână din 1999 sau 1980, și sare înapoi cu 19.7 sau 39.4 ani față de data reală. De aici apare ianuarie 2006 sau alte date aberante din trecut.
Nu e o problemă de kernel, nu e o problemă de CentOS, nu rezolvi nimic cu yum update. E o problemă în firmware-ul receptorului GPS sau în biblioteca care interpretează semnalul.
Diagnosticare - ce rulezi pe aparat
Înainte de orice, identifică exact ce ai în față. Accesează aparatul prin SSH sau consola serială și rulează:
cat /etc/redhat-release
Îți arată versiunea exactă a sistemului de operare. Dacă scrie CentOS 6.x, aparatul rulează un OS care nu mai primește update-uri de securitate din noiembrie 2020 - asta e o problemă separată de care te ocupi după ce rezolvi data.
uname -rm
Versiunea de kernel și arhitectura. Util dacă ajungi să discuți cu suportul producătorului.
dmidecode -t system
Asta e comanda importantă - îți arată producătorul real al hardware-ului. Foarte multe servere NTP sunt OEM: aceeași cutie fizică apare sub Rohde & Schwarz, Meinberg, Spectracom sau alte branduri. Dacă dmidecode arată Meinberg în câmpul Manufacturer sau Product Name, știi exact cu cine să vorbești pentru firmware.
dmidecode -t bios
Versiunea de BIOS/firmware la nivel hardware. Notează-o.
Acum verifică daemonul NTP în sine:
ntpq -p
Uită-te la coloana refid și la starea surselor. Dacă sursa GPS apare cu refid de tip .GPS. sau .PPS. dar offset-ul e enorm (mii de secunde), confirmă că receptorul trimite timp greșit. Dacă sursa apare cu x în față, înseamnă că NTP a respins-o ca outlier - ceea ce e de fapt comportamentul corect al daemonului când primește timp aberant.
ntpq -c rv
Îți arată variabilele interne ale daemonului, inclusiv rootdisp, rootdelay și stratum. Un stratum 16 înseamnă că NTP-ul s-a desincronizat complet și a intrat în stare de fallback.
Dacă aparatul are și interfață web, caută în ea o secțiune de status GPS sau “receiver status” - producătorii serioși afișează acolo statusul receptorului, numărul de sateliți în vedere, calitatea semnalului și, relevant pentru noi, firmware version și uneori GPS epoch.
Cauze posibile și cum le diferențiezi
1. GPS Week Number Rollover
Simptome: data e exact cu ~19.7 ani sau ~39.4 ani în urmă față de data reală. Receptorul funcționează altfel normal - prinde sateliți, are fix, dar ora e greșită sistematic. Dacă scazi din data curentă și obții ceva în jurul lui 1999 sau 2006, e rollover.
2. Baterie CMOS descărcată
Simptome: data sare la o valoare complet aleatorie sau la epoch (1 ianuarie 1970 sau 1 ianuarie 1980), nu la o dată care are logică față de ciclurile GPS. Apare de obicei după o cădere de curent sau după ce aparatul a stat mult timp oprit.
3. Problemă de semnal GPS
Simptome: receptorul nu prinde deloc sateliți sau prinde prea puțini pentru un fix valid. Verifică antena GPS - cablu, conectori, poziția antenei. Un receptor fără fix valid poate raporta timp aleator sau poate merge pe ceasul intern, care driftează.
4. Bug în firmware specific unor versiuni
Unele modele Meinberg și Symmetricom au avut bug-uri în gestionarea rollover-ului 2019 documentate public, cu patch-uri disponibile. La Rohde & Schwarz există note de aplicație pentru echipamentele de broadcast afectate.
Soluții concrete
Prima opțiune: firmware update oficial
E soluția corectă și singura care rezolvă problema la rădăcină. Pașii:
- Identifică modelul exact de pe carcasă și numărul de serie
- Verifică site-ul producătorului pentru firmware updates - Meinberg are https://meinbergglobal.com/english/sw/, Rohde & Schwarz are portalul
rohde-schwarz.com/firmware - Dacă aparatul e sub contract de suport, deschide un tichet și cere imaginea de firmware corectă pentru modelul tău
- Dacă nu mai e sub suport, caută în forumuri și arhive - Meinberg în special are o comunitate activă și uneori pune firmware gratuit pentru modele mai vechi
- Aplică firmware-ul conform documentației producătorului, nu prin yum sau apt - de obicei e o imagine care se uploadează prin interfața web sau printr-un utilitar dedicat
Important: fă backup complet înainte, inclusiv la configurația NTP, listele de clienți autorizați și orice customizare. Pe unele aparate cu stocare flash, un update prost înseamnă brick.
A doua opțiune: configurare manuală a epoch-ului (dacă firmware-ul permite)
Unele receptoare GPS expun un parametru de configurare numit GPS epoch, week number offset sau similar, care poate fi setat manual prin interfața web sau prin fișiere de configurare. Pe aparatele Meinberg care rulează LANTIME firmware, asta se face din interfața web la Configuration > GPS Receiver. Pe altele e un fișier de configurare editat direct în sistem.
Această opțiune e un workaround, nu o soluție permanentă. Dacă vine un al treilea rollover (2038), problema reapare.
A treia opțiune: bypass-ul receptorului GPS și folosirea unui alt stratum 1
Dacă firmware-ul nu poate fi actualizat și nici configurarea epoch-ului nu e posibilă, poți configura daemonul NTP să ignore complet receptorul GPS local și să sincronizeze de la servere externe de încredere. Pe CentOS 6, editezi /etc/ntp.conf:
# Comentezi sau elimini linia cu sursa GPS locală:
# server 127.127.20.0 mode 17 prefer
# Adaugi servere publice de stratum 1-2:
server 0.ro.pool.ntp.org iburst
server 1.ro.pool.ntp.org iburst
server 2.ro.pool.ntp.org iburst
server 3.ro.pool.ntp.org iburst
Restartezi daemonul:
service ntpd restart
Verifici că sincronizarea funcționează:
ntpq -p
watch ntpq -p
Dezavantajul e că pierzi precizia unui stratum 1 local cu receptor GPS - ajungi la stratum 2-3 cu jitter de ordinul milisecundelor, suficient pentru marea majoritate a utilizărilor dar insuficient pentru aplicații de broadcast sau telecomunicații unde aveau rost exact aceste aparate.
A patra opțiune: înlocuirea aparatului
Dacă aparatul nu mai are suport, nu există firmware update și aplicația ta necesită precizie de stratum 1, e momentul să treci la ceva modern. Opțiuni:
- Meinberg LANTIME M300/M600 - clasa enterprise, suport activ, gestionează corect rollover-ul
- Raspberry Pi + GPS HAT + chrony - pentru aplicații mai puțin critice, o soluție DIY funcțională cu u-blox NEO-M8N sau similar costă sub 100 EUR și e complet configurabilă
- GPS disciplined oscillator dedicat de la GPS Source, Trimble sau Jackson Labs, dacă precizia e critică
Securizarea aparatului până la rezolvare
Indiferent ce soluție alegi, dacă aparatul rulează CentOS 6 neactualizat și e expus în rețea, trebuie să-i limitezi suprafața de atac imediat. CentOS 6 nu mai primește patch-uri de securitate din noiembrie 2020, ceea ce înseamnă că orice vulnerabilitate descoperită după acea dată e permanent nerezolvată pe acest sistem.
Izolează aparatul pe VLAN de management separat. Accesul la NTP (UDP 123) trebuie permis dinspre rețeaua care are nevoie de sincronizare, dar interfața web și SSH-ul trebuie restricționate strict la IP-urile de management. Dacă folosești iptables direct pe aparat:
# Permite NTP de la subnet-ul intern
iptables -A INPUT -p udp --dport 123 -s 192.168.x.0/24 -j ACCEPT
# Permite SSH doar de la IP-ul de management
iptables -A INPUT -p tcp --dport 22 -s 192.168.y.z -j ACCEPT
# Permite interfața web doar de la IP-ul de management
iptables -A INPUT -p tcp --dport 80 -s 192.168.y.z -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 192.168.y.z -j ACCEPT
# Drop orice altceva
iptables -A INPUT -j DROP
Adaptează adresele la topologia ta și salvează regulile cu service iptables save.
Dezactivează serviciile pe care nu le folosești. Verifică ce rulează:
chkconfig --list | grep on
Orice serviciu pe care nu-l recunoști sau nu-l folosești activ, oprește-l și scoate-l din autostart:
chkconfig <serviciu> off
service <serviciu> stop
Schimbă parolele dacă n-au fost schimbate de la instalare. Multe appliance-uri vin cu parole default documentate public.
Verifică accesul SSH - dacă SSH e necesar, asigură-te că root login e dezactivat (PermitRootLogin no în /etc/ssh/sshd_config) și că autentificarea se face cu cheie, nu parolă (PasswordAuthentication no).
Nu expune aparatul la internet. Un server NTP cu CentOS 6 nu are ce căuta cu acces direct la internet. Dacă ai nevoie să sincronizeze cu servere externe, fă asta printr-un proxy sau printr-un alt server NTP intern care are acces controlat spre exterior.
Concluzie
Problema cu data greșită pe un server NTP cu receptor GPS e aproape întotdeauna un GPS Week Number Rollover, nu o problemă de sistem de operare. Upgradul de la CentOS 6.8 la 6.9 sau 6.10 nu rezolvă nimic și poate strica configurația producătorului. Soluția corectă e firmware update de la producătorul aparatului - Rohde & Schwarz, Meinberg sau oricine e producătorul real al hardware-ului, identificabil cu dmidecode -t system.
Până la rezolvarea problemei principale, tratează aparatul ca pe un echipament legacy nesecurizat: VLAN separat, acces restricționat pe IP, servicii inutile dezactivate. CentOS 6 fără patch-uri de securitate e un risc real care merită adresat separat de problema GPS, fie prin izolare strictă, fie prin planificarea înlocuirii pe termen mediu.