Zawieszanie się Funbox'a 3.0


Poziom 8, Zwiadowca Przestworzy
  • 3
  • 4
  • 0

Zawieszanie się Funbox'a 3.0

Cześć, mam FunBox 3.0 i od pewnego czasu mam okresowe awarie LAN. Z monitoringu wychodzi dość powtarzalny schemat: najpierw mocno zwalnia albo przestaje odpowiadać /sysbus/Devices:get (timeouty ok. 9 s), podczas gdy WAN i pozostałe lekkie endpointy nadal działają. Po kilku minutach zaczynają timeoutować też kolejne endpointy sysbus, a następnie pojawiają się problemy z DHCP i część urządzeń traci sieć. Restart FunBoxa przywraca wszystko do normy, ale problem wraca.

Sysbus sprawdzam bezpośrednio z poziomu panelu FunBoxa w przeglądarce, wykorzystując jego własną sesję i zapytania do endpointów /sysbus/..., więc mogę mierzyć czasy odpowiedzi i obserwować, które usługi zaczynają się zawieszać jako pierwsze.

W czasie tych zdarzeń router nie wygląda na przeciążony pamięcią, a w sieci nie ma drugiego serwera DHCP. Czy ktoś spotkał się z podobnym zachowaniem FunBoxa 3.0 albo ma konkretną informację, czy ten model ma jakieś praktyczne ograniczenie liczby urządzeń/klientów w LAN lub DHCP?

6 ODPOW. 6

Poziom 39, Pomocnik Międzygalaktyczny
  • 10125
  • 42650
  • 351

Zawieszanie się Funbox'a 3.0

A diody co pokazują? Wszytko na zielono? Jaki jest poziom sygnału optycznego w menu? Czy też może masz zewnętrzny ONT (ale wątpię, bo pewnie byś napisał)? Napięcie w gniazdku sprawdzałeś? Może pada zasilacz?

PS. Kiedy jeszcze go używałem był ultra stabilny (uptime maksymalny możliwy, czyli zawsze pełna sesja od resetu do resetu fundowanego przez operatora co 10 dni). Ale ja miałem z nim w kaskadzie swój ruter, więc FB3 obsługiwał tylko jedno urządzenie i miał WiFi wyłączone, wiec pewnie z twoją sytuacją trudno to porównać.


Poziom 8, Zwiadowca Przestworzy
  • 3
  • 4
  • 0

Zawieszanie się Funbox'a 3.0

Diody podczas awarii są zielone. Zewnętrznego ONT nie ma, FunBox jest podpięty bezpośrednio do światłowodu. Parametry optyczne wyglądają prawidłowo: RX -15,436 dBm, TX około +2,7 dBm, więc na tę chwilę nie widać problemu po stronie sygnału optycznego.

Zasilacz również był sprawdzany i nie wygląda na uszkodzony. Sam FunBox nie zachowuje się też jak przy zaniku zasilania. Co ciekawe, podczas awarii nadal działa zdalny dostęp do panelu WWW FunBoxa od strony WAN. Czyli urządzenie nie jest całkowicie martwe ani zrestartowane, bo jego interfejs zarządzania od strony Internetu nadal odpowiada, podczas gdy usługi lokalne po stronie LAN zaczynają się zawieszać.

U nas sytuacja jest trochę inna niż u Ciebie, bo FunBox 3 jest jedynym routerem w sieci i faktycznie obsługuje całą szkołę. Jest sporo urządzeń, komputery, kamery, rejestratory, telefony itd. I właśnie to jest dla mnie jeden z głównych tropów, bo w logach widać, że najpierw zaczyna się dławić obsługa listy urządzeń w /sysbus/Devices:get, później przestają odpowiadać kolejne usługi lokalne, a przy większej awarii zaczyna siadać DHCP.

Dlatego bardzo mnie interesuje, czy FunBox 3 ma jakieś realne ograniczenia liczby urządzeń albo problem firmware przy większej liczbie klientów. U mnie baza Devices ma około 100 wpisów i wygląda na to, że FunBox potrafi ponownie tworzyć wpisy dla urządzeń, które były już wcześniej znane.

Swoją drogą trochę mnie dziwi, że Orange Biznes daje FunBoxa 3 jako router w ofercie biznesowej. W małej firmie z kilkoma urządzeniami pewnie faktycznie może działać latami bez problemu, ale przy większej sieci szkolnej zaczyna to wyglądać jak sprzęt pracujący na granicy tego, do czego był projektowany.

Jeśli ktoś z techników Orange zna faktyczne ograniczenia FunBoxa 3 pod kątem liczby klientów, DHCP, tablicy urządzeń albo znane problemy firmware z Devices/sysbus, to bardzo chętnie poznam konkrety.


Poziom 33, Ekspert Galaktyczny
  • 4562
  • 22963
  • 107

Zawieszanie się Funbox'a 3.0

Każdy router ma ograniczenia. Najbardziej obciąża NATowanie, a przy tak dużej ilości sprzętu to ten router pewnie działa na 100%. Zapewne jeszcze masz jakieś reguły na FW, co dodatkowo obciąża CPU. 

Funbox 3.0 do obsługi szkoły raczej się nie nadaje. Zrób z niego brame, a całą sieć zrób na swoim sprzęcie. W ofercie dla firm chyba można wykupić tryb mostu więc ja bym to rozważył. 

Edycja: 

Rzuciłem okiem na specyfikę tego sprzętu i jest hmm słaba . 2rdzeniowy MIPS 600Mhz,  to już przeszłość. Przyspieszenie sprzętowe do obsługi NAT na tym procku to już technologia, która przeminęła z wiatrem 🙂  256RAM ..... Bez komentarza:) . W domu, do kilku urządzeń mam 512MB i to szału nie robi... ale Nginx obsługuje. 


Screenshot_20260923-133411.png

Poziom 36, Nawigator Galaktyczny
  • 3216
  • 15686
  • 143

Zawieszanie się Funbox'a 3.0

@mike2pl Próbowałeś skrócić maskę podsieci?

PS Pytanie pomocnicze: korzystasz z IPv6/IPv4 czy tylko IPv4?


Poziom 8, Zwiadowca Przestworzy
  • 3
  • 4
  • 0

Zawieszanie się Funbox'a 3.0

Tak, to jasne, że każdy router ma swoje ograniczenia i nie da się podać jednej liczby urządzeń. Mnie interesuje, gdzie mniej więcej leży granica tego konkretnego modelu i czy są znane przypadki, że przy większej liczbie klientów zaczyna się dławić jego warstwa zarządzania albo DHCP.

U mnie na FunBoxie praktycznie nie ma żadnej dodatkowej konfiguracji. Jedyne co jest ustawione, to 62 statyczne adresy DHCP. Poza tym działa jako główny router, NAT i DHCP dla całej sieci.

Gdybym miał pełną dowolność, to od początku zostawiłbym go wyłącznie jako zakończenie łącza Orange, a całą sieć puścił przez własny router. Tryb bridge też biorę pod uwagę, tylko w jednostce budżetowej sama biurokracja, obieg dokumentów i formalności związane z taką zmianą potrafią potrwać około 3 tygodni, a problem mam dzisiaj 😉

PS

 

Odpytuje bezpośrednio wewnętrzny sysbus FunBoxa, m.in.:

/sysbus/Devices:get
/sysbus/NMC:getWANStatus
/sysbus/DHCPv4/Server/Stats:get
/sysbus/DeviceInfo:get
/sysbus/DeviceInfo/MemoryStatus:get


Przykładowo z konsoli przeglądarki wygląda to mniej więcej tak:

(async () => {
const ctx = document.cookie.match(/(?:^|;\s*)context=([^;]+)/)?.[1];

for (const url of [
'/sysbus/Devices:get',
'/sysbus/NMC:getWANStatus',

'/sysbus/DHCPv4/Server/Stats:get'
]) {
const t = performance.now();

try {
const r = await fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/x-sah-ws-1-call+json',
'X-Requested-With': 'XMLHttpRequest',
'X-Prototype-Version': '1.7',
'X-Context': ctx
},
body: '{"parameters":{}}'
});

console.log(url, r.status, Math.round(performance.now() - t) + ' ms');
} catch (e) {
console.log(url, 'FAIL', e);
}
}
})();


W normalnym stanie te wywołania odpowiadają w dziesiątkach lub setkach ms. Przed awarią Devices:get zaczyna iść w kilka sekund albo timeout, podczas gdy np. getWANStatus jeszcze odpowiada normalnie. Kilkanaście-kilkadziesiąt sekund później zaczynają timeoutować kolejne endpointy i równolegle przestaje działać DHCP/LAN.


Poziom 33, Ekspert Galaktyczny
  • 4562
  • 22963
  • 107

Zawieszanie się Funbox'a 3.0

Rozumiem, że  budżetówka ma swoje prawa, tylko ARP a tym nie wie 😞