Výměna pronajatého ONT (Comtrend) za FS XGS-SFP-ONT-MAC-I zastrčený přímo do SFP+ portu routeru. Vyřešeno v červenci 2026 — od té doby v provozu. Všechno níže je ověřené na reálné lince O2/CETIN: výstupy v tomto textu jsou skutečné, ne ilustrační (jediné dvě odvozené věci — baby-jumbo MTU a průběh VEIP setu v 1U — jsou v textu výslovně označené).
(English version: fs-xgspon-stick-o2-cetin-en.)
Ověřená sestava: FS XGS-SFP-ONT-MAC-I (SKU 378865, čip MaxLinear PRX126,
firmware LEDE 1.23.1 / v22.03.3_maxlinear) v Ubiquiti UCG-Fiber (SFP+ WAN).
Diagnostický postup platí pro jakýkoli modul s čipem PRX126 (komunitně
„stick“, např. i WAS-110) a v principu pro jakéhokoli operátora, jehož OLT
nevytvoří účastnický bridge port.
- Kupte správný modul. Linka O2 na infrastruktuře CETINu je dnes typicky XGS-PON (10G, vlnové délky 1270 nm up / 1577 nm down) — ověřte štítek svého ONT. FS prodává GPON i XGS-PON variantu; GPON verze na XGS lince nenaběhne.
- Nechte u O2 zaregistrovat sériové číslo modulu. CETIN autorizuje POUZE
podle GPON SN (žádné heslo, žádný regID). Pošlete raději obě formy — ASCII
(
FSOX--------) i plný hex (46534F58--------) — ať si partner CETIN vybere. Vyřizuje se přes O2 na objednávku „vlastní ONT“; samotná registrace/výměna proběhla v mém případě tentýž den (déle trvá až případné ODblokování po karanténě, viz níže). - Konfigurace modulu (SSH
root@192.168.101.1, prázdné heslo, z routeru si přidejte IP:ip addr add 192.168.101.99/24 dev <sfp-iface>; modul musí sedět v šachtě s připojeným, svítícím vláknem — bez světla není SGMII link ani management, viz Varování). Nejdřív nastavte root heslo — tovární firmware žádné nemá (viz Varování):Pak PON konfigurace:passwd
Ostatní hodnoty (uci set gpon.ploam.nSerial='FSOX--------' # 4 ASCII + 8 hex znaků, NE plný hex tvar uci set gpon.ponip.pon_mode='xgspon' uci set omci.default.mib_file='/etc/mibs/prx300_1U.ini' uci commit && reboot
omci.default.loid/lpwd/omcc_version,gpon.ponip.iop_mask) nechte tovární — na FS modulu jsou správně.gpon.ploam.regIDNEMAZAT (viz Varování — prázdný/chybějící regID zablokuje celý PON stack). - Router: PPPoE na VLAN 848, uživatel
O2, hesloO2(IPTV je 835, VoIP 899). MTU 1492. - Po registraci SN modul naběhne do provozu (
pon psg→current=51), OLT nahraje profil — a PPPoE stejně nepojede („Timeout waiting for PADO packets“). To je ta past. Oprava — jeden příkaz na modulu:PADO přijde do minuty. Proč to tak je a proč je to korektní řešení, nikoli hack — viz hloubková analýza níže.brctl addif sw1 eth0_0
- Oprava nepřežije restart — nainstalujte si hlídač (sekce Perzistence): malý skript + cron, který most po každém restartu/re-provisioningu sám obnoví. Změřeno při ostrém testu (úmyslné odpojení za provozu): most obnoven za 79 s, celý WAN vč. PPPoE do ~3 minut.
- Když modul nenabíhá a
pon psgcyklujecurrent=23→ vaše SN je na OLT blokované — to z modulu nespravíte, musí to odblokovat partner CETIN (viz sekce Blokace SN).
internet (O2 BNG) ── CETIN OLT ═══ XGS-PON vlákno (1577 nm ↓ / 1270 nm ↑, zdravé Rx ≈ −17 dBm)
│
FS modul (pon0)
├── gem4095 ── sw-multicast (multicast, IPTV)
└── gem1024 ── sw1 ═ eth0_0 (unicast; eth0_0 tam MUSÍ někdo přidat!)
│ SGMII 10G (uvnitř SFP+ šachty)
router: SFP+ iface ── <iface>.848 ── pppd (PPPoE O2/O2)
└ management modulu: 192.168.101.1 (LCT, jede mimo datový most)
Provisioning krok za krokem:
sequenceDiagram
participant ONT as FS modul
participant OLT as CETIN OLT
ONT->>OLT: PLOAM: hlásím SN (stav O2.3)
OLT->>ONT: přiděleno ONU-ID, ranging (O4) → provoz (O5.1)
OLT->>ONT: OMCI push profilu: bridge, GEM 1024/4095, VLAN filtr 848
OLT--xONT: SET VEIP (ME 329) — SELŽE (modul v 1U žádný VEIP nemá)
Note over ONT: účastnický bridge port NEVZNIKNE<br/>sw1 zůstane jen s gem1024
ONT->>ONT: ruční oprava: brctl addif sw1 eth0_0
ONT->>OLT: PPPoE PADI (VLAN 848) → PADO → session
Pozn. k poctivosti: krok „SET VEIP selže“ je doložený z OLT logu partnera CETIN (12. 7., režim 1V); pro režim 1U je odvozený z VEIP orientace profilu — samotný onboarding flow v 1U se zachytit nepodařilo. Výsledek (chybějící účastnický port) je ověřený přímo z MIB.
Po přijetí modulu (PLOAM O5.1) nahraje OLT přes protokol OMCI svůj servisní profil jako sadu Managed Entities (ME). Pro data je podstatná tahle sestava — takhle vypadá kompletní profil O2/CETIN na této lince (reálný výpis):
omci_pipe.sh mib_dump | grep -E "^\|" | grep -iE "bridge port|GEM|VLAN tag"
| 47 | 257 (0x0101) | Bridge port config data <- unicast bridge port (strana GEM)
| 47 | 511 (0x01ff) | Bridge port config data <- multicast
| 84 | 257 (0x0101) | VLAN tagging filter data <- filtr: TCI 0x0350 = VLAN 848
| 266 | 1024 (0x0400) | GEM interworking TP <- unicast „lepidlo“
| 268 | 1024 (0x0400) | GEM port network CTP <- unicast GEM
| 268 | 4095 (0x0fff) | GEM port network CTP <- multicast
| 281 | 4095 (0x0fff) | Multicast GEM TP
Funkční most potřebuje dvojici bridge portů (ME 47) na tomtéž mostu:
jeden na straně GEM (TP typ 0x05) a jeden účastnický — buď fyzický UNI
(TP 0x01), nebo VEIP (TP 0x0b). Podívejte se na výpis výš: žádná
instance ME 47 s TP typem 0x01 ani 0x0b tam není. OLT postavil půlku mostu.
CETIN od vlastních ONT vyžaduje VEIP („zařízení musí podporovat VEIP“ — to
je celé zadání, které dostanete). Profil OLT se proto pokouší nastavit ME 329
(VEIP) na instanci 0x1:
- FS modul v defaultní osobnosti 1U (
prx300_1U.ini) vystavuje fyzické UNI (PPTP Ethernet UNI, ME 11) — žádný VEIP nemá, set selže, OLT jede dál a účastnický bridge port prostě nevytvoří. Síťová strana (GEM, VLAN filtr) vznikne, most zůstane poloviční. - Osobnost 1V (
prx300_1V.ini) VEIP má — jenže tovární soubor ho deklaruje na instanci0x0101, zatímco OLT nastavuje0x0001. Výsledek na straně OLT:Failed cause: OLT return instance invalid (0x3000e)— a podpora vám řekne, že „zařízení neumí VEIP“. Ta chyba je instančním nesouladem plně vysvětlená; oprava je jednořádková (v/etc/mibs/prx300_1V.inipřepsat329 0x0101na329 0x0001) — ale POZOR: 1V nikdy nezkoušejte na dálku. Datový most OLT si v 1V vezmeeth0_0, přes které jede i management modulu, a přístup ztratíte (strukturálně — na dálku neopravitelné). Právě proto režim 1V s opravenou instancí nebyl na této lince nikdy ověřen až do konce (všechna testovací okna byla „slepá“) — a právě proto tenhle návod doporučuje cestu 1U + hlídač.
Prakticky nejrobustnější cesta: zůstat na 1U, nechat VEIP set selhat a chybějící připojení mostu doplnit ručně.
Na modulu překládá OMCI do linuxového síťování démon omcid (MaxLinear
pon_net_lib). Když OLT vytvoří ME účastnického bridge portu, omcid provede
přesně: ip link set $dev master $br — je to vidět přímo ve zdrojácích
(pon_net_lib, mac_bridge_port_config_data.c).
Ruční brctl addif sw1 eth0_0 je tatáž operace, na téže vrstvě — jen ji
spouštíte vy, protože OLT příslušné ME nikdy nepošle.
Opravit to „čistě“ na vrstvě OMCI z modulu nelze: bridge-port ME jsou
set-by-create — vytvořit je smí jen OLT. Vrstva pod OMCI je jediná, která
vám zbývá. A protože jde o čistě runtime stav jádra (žádné uci, žádné OMCI,
žádný zápis do flash), je operace plně vratná (brctl delif sw1 eth0_0) a
z pohledu OLT neviditelná.
Důkaz kauzality z této linky: nekonečná zeď Timeout waiting for PADO packets, pak PADO + PADS + veřejná IP do 60 sekund od toho jednoho
příkazu, beze
změny čehokoli jiného. A obráceně: delif → WAN do ~70 s spadne (LCP),
addif → WAN se sám vrátí. A/B/A ověřeno.
Filtr ME 84/257 na straně OLT má jedinou položku, TCI 0x0350 = VID 848,
forward-op 0x10 (propouští jen rámce označkované tímto VID). Na modulu není
žádné ME 171 (přeznačkování) ani ME 130 (p-mapper) — most sw1 je
VLAN-neutrální (vlan_filtering=0) a rámce jím projdou beze změny. Router
tedy značkuje 848 (<iface>.848), modul nic nepřepisuje, OLT filtr 848
propustí. Proto stačí prosté přemostění.
1. Stav PLOAM:
pon psg
errorcode=0 current=51 previous=40 time_curr=2233 change_reason=65535current= |
Význam |
|---|---|
| 10/11/12 | O1.x — synchronizace downstreamu |
| 23 | O2.3 — modul hlásí SN, čeká na ONU-ID (cyklení tady = blokace SN) |
| 40 | O4 — ranging |
| 51 | O5.1 — provoz, OMCI běží |
| errorcode=-1032 | PON stack vůbec neběží (viz regID ve Varování) |
Zdravý náběh: 10 → 12 → (23 → 40) → 51 během sekund. Pokud nejste na 51, řešte nejdřív registraci/blokaci SN — most je až další krok.
2. SN na vlákně (co modul skutečně vysílá):
pon sng
errorcode=0 serial_no="FSOX--------"3. Co OLT nahrál — viz výpis MIB v analýze výš. Klíčová kontrola: existuje
ME 47 s TP typem 0x01/0x0b? (omci_pipe.sh meg 47 <instance>, atribut 3.)
Ne → OLT účastnický port nevytvořil.
4. Stav mostu na modulu:
brctl show
sw-multicast ... gem4095
sw1 ... gem1024 <- JEN gem1024: tady je závada
ip -o link show eth0_0
2: eth0_0: <...UP,LOWER_UP> ... <- chybí „master sw1“: UNI nikam nevede5. Router: Timeout waiting for PADO packets každých ~40 s. PADI odchází,
ale na eth0_0 skončí v prázdnu (rozhraní není v mostu) — OLT ho nikdy
neuvidí. Je to čistě L2 problém — na přihlašovacích údajích nezáleží
(ověřování ještě ani nezačalo).
Tip pro zachytávání na routeru: na platformách se switch ASIC (UniFi
ipq9574 apod.) tcpdump na fyzickém rozhraní nevidí lokálně odesílané rámce —
zachytávejte na VLAN subrozhraní: tcpdump -i <iface>.848 pppoed.
Signatura — pon psg cykluje donekonečna:
current=23 previous=12 time_curr=53 # ~60–70 s v O2.3
current=12 previous=11 time_curr=9 # krátce v O1.2, a znovu
SN je vysíláno správně (ověřte pon sng), ale OLT nikdy nepřidělí ONU-ID.
Z modulu to neopravíte. OLT (ochrana proti rogue ONT) se do tohoto stavu
umí dostat po dni plném restartů, přepínání osobností a polomrtvých stavů —
každá taková událost se počítá. Ověřený poznatek z této linky: blokace je na
úrovni linky/portu, ne konkrétního SN (OLT odmítal i SN původního ONT).
Co dělat: přestat restartovat (každý pokus jámu prohlubuje) a obrátit se na podporu O2 — ta komunikuje s technickým partnerem CETINu, který jediný umí SN na OLT odblokovat. Uveďte číslo objednávky a SN a věcně popište stav (modul sériové číslo vysílá, ONU-ID nepřichází). Odblokování proběhlo v mém případě dvakrát a pokaždé vyžadovalo explicitní žádost; po odblokování modul naběhl okamžitě.
brctl addif je runtime stav: zmizí při každém restartu modulu, restartu
omcid i re-provisioningu z OLT (OLT nahrává profil při každém onboardingu a
sw1 se pokaždé postaví znovu — bez eth0_0). Řešení: mini-skript spouštěný
cronem každou minutu, který most doplní, kdykoli je potřeba.
/root/uni-bridge-guard.sh (md5 2956349e7755a5b484b8bcf47914e84c):
#!/bin/sh
# uni-bridge-guard — re-attach eth0_0 to the OMCI unicast bridge (sw1) if an
# OMCI rebuild dropped it (stick reboot, omcid restart, OLT MIB re-push).
# Installed at /root/uni-bridge-guard.sh on the stick; run by cron every
# minute (/etc/crontabs/root); checks every 10 s within its minute.
# Acts ONLY when: sw1 exists AND holds a gem* port (OLT unicast provisioned)
# AND eth0_0 is not already enslaved. Worst failure mode: does nothing.
# Remove: rm /root/uni-bridge-guard.sh /etc/crontabs/root; /etc/init.d/cron stop
i=0
while [ $i -lt 5 ]; do
if [ -d /sys/class/net/sw1 ] \
&& ls /sys/class/net/sw1/brif 2>/dev/null | grep -q "^gem" \
&& [ -d /sys/class/net/eth0_0 ] \
&& [ ! -d /sys/class/net/eth0_0/brport ]; then
brctl addif sw1 eth0_0 && echo "$(date) re-attached eth0_0 to sw1" >> /root/uni-bridge-guard.log
fi
i=$((i+1))
sleep 10
doneInstalace (na modulu) — bezpečná i pro moduly, kde už v crontabu něco máte (WAS-110 s komunitním firmware apod.):
# skript nahrajte do /root/uni-bridge-guard.sh, potom:
grep -q uni-bridge-guard /etc/crontabs/root 2>/dev/null || \
echo '* * * * * /bin/sh /root/uni-bridge-guard.sh' >> /etc/crontabs/root
/etc/init.d/cron enable
/etc/init.d/cron startOdinstalace: smažte jen řádek hlídače (sed -i '/uni-bridge-guard/d' /etc/crontabs/root) a rm /root/uni-bridge-guard.sh — hlavička skriptu
uvádí razantnější variantu (smazání celého crontabu), ta je v pořádku jen na
továrním FS modulu, kde je crontab jinak prázdný.
Všechny tři artefakty (skript, crontab, rc.d symlink) leží na zapisovatelném overlay → přežijí restart i výpadek napájení.
Proč cron a ne démon: tahle platforma spolehlivě zabíjí rezidentní
procesy — busybox nemá timeout, omci_pipe.sh umí zablokovat navždy a
nohup přes dropbear umírá se svou SSH session (obojí reálně nastalo).
Čerstvý proces každou minutu se nemá na čem zaseknout. Hlídač jedná, JEN když
sw1 existuje, má gem* port a eth0_0 je odpojené — takže v karanténních
stavech nic nedělá, a pokud by CETIN někdy profil opravil (OLT by účastnický
port vytvářel sám), hlídač se trvale odmlčí. Nejhorší selhání: neudělá nic.
Změřeno při ostrém testu (úmyslné brctl delif za provozu): LCP odhlásil
session po ~70 s, hlídač most obnovil za 79 s, PPPoE se samo znovu
dojednalo — stejná veřejná IP, celkový výpadek ~3 minuty, nula ručních zásahů.
Přežití restartu je dané mechanismem (vše na overlay, cron startuje přes
rc.d); kompletní restartová cesta (crond po bootu + načasování OLT push)
v době psaní ještě naostro neproběhla — ověří ji první reálný restart.
gpon.ploam.regIDnikdy nemazat. Je to povinné pole libpon: chybějící nebo prázdné → omcid v crash-loopu, laser nevysílá,pon psgvracíerrorcode=-1032. CETIN obsah pole nepoužívá (autorizace jen podle SN) — ale pole musí existovat. Kontrola:uci get gpon.ploam.regID. Pokud chybí, naplňte 36 nulovými bajty:uci set gpon.ploam.regID='0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00' uci commit gpon
- Tovární firmware má root SSH bez hesla (a web s
root/root). Kdo se dostane na 192.168.101.1, má roota na zařízení, přes které teče celý váš WAN provoz — odposlech/MITM, shození WAN i rozbití PON identity je jedno přihlášení daleko. A pozor: management alias na routeru (ip addr add 192.168.101.99/24 ...) zůstává aktivní, dokud ho neodeberete nebo router nerestartuje — cesta k modulu tak může zůstat otevřená celé vaší LAN, pokud ji firewall neblokuje. Heslo si nastavte hned po prvním přihlášení (passwd); web server jde rovnou vypnout (/etc/init.d/uhttpd stop && /etc/init.d/uhttpd disable— správa jde stejně po SSH); alias po práci odeberte (ip addr del 192.168.101.99/24 dev <sfp-iface>), případně provoz z LAN do 192.168.101.0/24 zablokujte firewallem. - SN v uci zadávejte jako 4 ASCII + 8 hex (
FSOX--------), NE jako plný 16znakový hex — ten se rozparsuje špatně a modul vysílá jiné SN, než myslíte. Vždy ověřtepon sng. - Osobnost 1V (VEIP) nikdy nezkoušejte na dálku. Datový most si vezme
eth0_0a management (LCT) zhasne — strukturálně. Návrat = zachytit ~35s okno při bootu připraveným skriptem, nebo fyzicky vytáhnout modul. Jen s konzolí / fyzickým přístupem. - Nepřepínejte osobnosti opakovaně a šetřete restarty. 1U/1V hlásí OLT různou identitu zařízení; v kombinaci s restartovacím maratonem to je pravděpodobný spouštěč blokace SN (ochrana proti rogue ONT). Rozpočet: jednotky událostí denně, ne desítky.
- Modul nemá RTC — čas a mtime souborů na modulu jsou do NTP synchronizace (která potřebuje funkční WAN/NAT) bezcenné. Časové značky berte z routeru.
- UCG-Fiber vyhodnocuje RX_LOS na SFP+ nekompromisně: bez světla z OLT není SGMII link — a tedy ani management modulu. Tmavé vlákno = nedostupný modul, není to závada modulu.
- UniFi SSH je keyboard-interactive.
sshpass -e ssh ...funguje; nikdy nepřidávejte-o PreferredAuthentications=password— rozbije to auth úplně. A nebušte do SSH v dávkách: UCG má rate-limit, který při náporu vracíPermission deniedi se správným heslem (vypadá přesně jako změněné heslo; samo se to za pár sekund klidu srovná). - MTU: pro PPPoE nechte 1492 (standardní PPPoE MTU na O2). Baby-jumbo (RFC 4638, MTU 1500) jsem na této instalaci netestoval — jeho rámce (na drátě 1522+ B) přesahují, co cesta přes most modulu při výchozích MTU přenese, a podpora na straně O2 BNG je neověřená. Počítejte s 1492.
- Vše výše pochází z jedné reálné, plně dokumentované instalace na O2/CETIN XGS-PON (2026): výstupy jsou skutečné a každé tvrzení má za sebou timestampovaný log (odvozené výjimky jsou označené přímo v textu). Průběh zahrnoval dvě blokace SN, regresi profilu na straně OLT a její obnovu partnerem CETIN — takže popsané signatury („O2.3 smyčka“, „poloviční most“, „multicast-only profil“) jsou vyfocené ze života, ne z dokumentace.
- Mechanismus opravy je doložitelný ve zdrojácích výrobce čipu: MaxLinear pon_net_lib — omcid při vytvoření účastnického bridge portu provádí přesně tu operaci, kterou děláte ručně.
- Nezávislý precedens na stejném křemíku: WAS-110 na Fidium/GoNetSpeed (transscendsurvival.org, 05/2026) — OLT také nevytvořil účastnický bridge port, stejná oprava na linuxové vrstvě.
- Další zdroje ke studiu: hack-gpon.org (PPTP vs VEIP, hardware ONT modulů), pon.wiki a komunita 8311 (PLOAM/OMCI know-how, WAS-110).
Sepsáno z provozní dokumentace této instalace; dotazy klidně do komentářů.