Provozuju Turris na půdě, routuju s ním do gigabitového p2p spoje Mikrotik, ale zaznamenal jsem že někdy mi dochází k výpadkům na LAN kdy se ethernet přepíná mezi 1000gbps a 100mbp. Síť mám 5e (do 20m), spoje prověřené “pípačkou”, v zásuvkách po domě mám Ubiquiti Unify UAPčka. Myslel jsem, že je to nekvalitní kabeláží, ale začalo docházet k výpadkům také mezi Turrisem a Unify AP anténkou co mám na střeše na pokrytí zahrady a tam se jedná o 3m dlouhý patch kabel.
Teplota na půdě je samozřejmě vysoká, zřejmě i vyšší než byl Turris designován. Může to být problém? Co ještě jiného mohu udělat před tím, než to vzdám a dám tam switch a NAT si udělám na Mikrotiku?
OS mám 3.x a už jsem si Turris stáhnul dolů abych udělal upgrade na 5.x a komplet reset. Ale vypadá to, že si snad ethernety nerozumí s Uniquity hardwarem. Nebo nevím - nechápu.
Chystal jsem se založit podobný dotaz, resp. spíše info a narazil na tohle vlákno. Provozuji starého modráka v1.0, donedávna jako DSL modem sloužil FritzBox 7590. Tento týden proběhl upgrade na VDSL 250/25 s bondingem, tudíž se modem měnil za Cetin terminátor. Zdánlivě vše zafungovalo na první dobrou. Po nějaké době jsem si všiml že rychlost (kterou jsem po upgradu testoval a byla v pořádku 230+Mbps) je na necelých 100Mbps. Následné pátrání po příčině odhalilo že WAN port se přepnul na 100Mbps. Obligátní výměna kabelu nepomohla, restart nepomohl, info zjištěné poté je následující:
Jiný router (Mikrotik a Asus s OpenWRT) se připojí bez problémů, vyjednaná rychlost s terminátorem na WAN portu v autoneg režimu je vždy 1Gbps
Turris 1.0 se připojí jak kdy - úspěšnost na první pokus je cca 20%, většinou skončí na 100Mbps. Po několikerém vynucení ethtool -s eth2 speed 1000 duplex full autoneg on se podaří spojit na 1Gbps, po nějakém čase (řádově hodiny provozu) se ale stejně “domluví” zase jen na 100Mbps
Při vynucení natvrdo 1Gbps ethtool -s eth2 speed 1000 duplex full autoneg off se Turris na terminátor nespojí vůbec. Pokud toto provedu po úspěšném spojení na 1Gbps (viz bod výše), spojení nadále funguje a po nějaké době (řádově hodiny) se rozpadne a nenaváže (opět koresponduje s předchozím bodem)
Stejně se Turris chová i na jakémkoliv jiném portu vestavěného switche
Zdárně vyřešeno (alespoň se to tak zatím jeví) tím, že jsem mezi WAN Turrise a Cetin terminátor vrazil switch s gigabitovými porty (DGS-1100-05V2, s nastavenou VLAN - to jen pro info, stejně by měl zafungovat i jakýkoliv jiný “hloupý” switch) a vše už funguje třetí den jak má. UPDATE: uběhl týden a něco, všechno stále OK.
Umístění v malém racku, OS v 3.x, teplota okolí nepřevyšuje 20-22 stupňů, teploty: Board: 52 CPU: 83
Turris je podtaktovaný na: CPU 800Mhz / platform 400Mhz / DDR 800Mhz.
Fakt nevím, jestli to nemůže souviset třeba i s podtaktováním (teoreticky ne, ale změna freq. asi nebyla nikdy ani autory nějak dlouhodoběji testována) nebo mi po těch letech už něco odchází (možná by bylo na čase ho zase rozebrat a zkontrolovat alespoň kondenzátory) a upřímně nevím co s tím a ani se mi to nechce nějak řešit, byť switch-in-the-middle mi jako úplně elegantní řešení nepřijde.
Normálně bych si vsadil na UTP kabel ale vyzkoušeno několik různých a se switchem to funguje. Nějakému problému se specifikací a s tím, že by se nedomluvil ausgerechnet s terminátorem se také zdráhám věřit, takže buď něco odchází nebo zato může to podtaktování (a to se mi moc zkoumat už nechce :D)
Zdravím, díky za reakci, je fajn že někdo sleduje i tyhle vedlejší vlákna o starých modrácích :D.
Bohužel s TOS5 nemohu sloužit, tenhle konkrétní kus běží trochu z ruky a v produkčním provozu a momentálně nemám moc prostoru si s tím hrát. Příležitostně, až se k tomu dostanu tak zkusím a dám vědět, ale chvíli to potrvá
UPDATE:
medkit TOS5 na jiné SD (pro jistotu), prohozeny SD karty, pomocí watch -n 1 ethtool eth2 sledován WAN port během restartu/připojování/odpojování UTP kabelu do terminátoru ===> stejné chování jako v případě TOS v3.11.23. Kvůli nedostatku času nevyzkoušeny ostatní porty na switchi ani přetaktování na původní frekvence CPU/system. Až bude více času zkusím i to a případně sem postnu i nějaký ten log.
POZN. vnitřek, včetně kondenzátorů vypadá na první pohled dobře
UPDATE 1:
Posílám slíbené vybrané logy během vytažení/zastrčení UTP do WAN portu (Turris OS v5.2.7, HBS). Osobně jsem si sám pro sebe určil jako zdroj problému terminátor (viz “partner advertised link modes” z ethtool) a dál to asi řešit nebudu - workaround se switchem funguje spolehlivě.
I.)while :; do ethtool eth2 >> ethtool.log; sleep 1; done
během vyjednávání “partner advertised link modes” oscilují několikrát mezi 1000baseT a 100baseT - viz vybrané části logu
1. Settings for eth2: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 7 Transceiver: internal Auto-negotiation: on Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: no
2. Settings for eth2: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 7 Transceiver: internal Auto-negotiation: on Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes
II.)tail -f /var/log/messages | grep eth2 | tee messages.log
koresponduje z výpisem z ethtool, párkrát se změní 1Gbps/Full a 100Mbps/Full, sem tam skončí na 1Gbps, většinou na 100Mbps…
Oct 29 12:45:30 turris kernel: [29833.704629] fsl-gianfar ffe26000.ethernet eth2: Link is Down
Oct 29 10:45:30 turris netifd: Network device ‘eth2’ link is down
Oct 29 10:45:30 turris netifd: VLAN ‘eth2.848’ link is down
Oct 29 12:45:38 turris kernel: [29838.818398] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 29 12:45:38 turris kernel: [29838.838196] IPv6: ADDRCONF(NETDEV_UP): eth2.848: link is not ready
Oct 29 12:45:47 turris kernel: [29851.112582] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Oct 29 12:45:47 turris kernel: [29851.128444] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Oct 29 12:45:47 turris kernel: [29851.153009] IPv6: ADDRCONF(NETDEV_CHANGE): eth2.848: link becomes ready
Oct 29 10:45:47 turris netifd: Network device ‘eth2’ link is up
Oct 29 10:45:47 turris netifd: VLAN ‘eth2.848’ link is up
Oct 29 12:45:49 turris kernel: [29853.162596] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off
Oct 29 12:46:13 turris kernel: [29876.868861] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 29 12:46:13 turris kernel: [29876.898989] IPv6: ADDRCONF(NETDEV_UP): eth2.848: link is not ready
Oct 29 10:46:13 turris netifd: VLAN ‘eth2.848’ link is down
Oct 29 10:46:13 turris netifd: Network device ‘eth2’ link is down
Oct 29 12:46:14 turris kernel: [29878.340979] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 29 12:46:14 turris kernel: [29878.402200] IPv6: ADDRCONF(NETDEV_UP): eth2.848: link is not ready
Oct 29 12:46:20 turris kernel: [29884.488414] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Oct 29 12:46:20 turris kernel: [29884.513226] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Oct 29 12:46:20 turris kernel: [29884.542486] IPv6: ADDRCONF(NETDEV_CHANGE): eth2.848: link becomes ready
Oct 29 10:46:20 turris netifd: Network device ‘eth2’ link is up
Oct 29 10:46:20 turris netifd: VLAN ‘eth2.848’ link is up
Oct 29 12:46:22 turris kernel: [29886.536294] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off
Oct 29 12:46:46 turris kernel: [29910.083960] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 29 12:46:46 turris kernel: [29910.094299] IPv6: ADDRCONF(NETDEV_UP): eth2.848: link is not ready
Oct 29 10:46:46 turris netifd: VLAN ‘eth2.848’ link is down
Oct 29 10:46:46 turris netifd: Network device ‘eth2’ link is down
Oct 29 12:46:47 turris kernel: [29911.568383] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 29 12:46:47 turris kernel: [29911.608726] IPv6: ADDRCONF(NETDEV_UP): eth2.848: link is not ready
Oct 29 12:46:54 turris kernel: [29917.704287] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Oct 29 12:46:54 turris kernel: [29917.719710] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Oct 29 12:46:54 turris kernel: [29917.747684] IPv6: ADDRCONF(NETDEV_CHANGE): eth2.848: link becomes ready
Oct 29 10:46:54 turris netifd: Network device ‘eth2’ link is up
Oct 29 10:46:54 turris netifd: VLAN ‘eth2.848’ link is up
Oct 29 12:46:56 turris kernel: [29919.752161] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off
Oct 29 12:47:19 turris kernel: [29943.562704] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 29 12:47:19 turris kernel: [29943.591272] IPv6: ADDRCONF(NETDEV_UP): eth2.848: link is not ready
Paráda — řešil jsem dnes jiný problém a u té příležitosti poslal logy —>USB port - když modrák běží dlouho (teď to bylo přes 40 dní) tak po restartu občas přestanou fungovat USB porty - ať tam strčím co strčím (flashku, externí HDD, LTE modem od T-Mobile) nic, ani písmenko v logu, prostě jako by v portu nic nebylo, napájení přitom funguje (disk se roztočí, modem zabliká), lsusb dokonce neukáže ani root hub, nepomůže ani reload modulů. Vždy pomůže router odpojit od napájení a zpátky zapnout, pak USB spolehlivě fungují, dokonce i po restartech … stává se to občas, tak jednou za dva/tři měsíce když se restartuje po delší době, nikdy ne za provozu — to jen tak na okraj :-), asi už vážně pomalu umírá
Budu rád když si najdete čas a přijdete těm rychlostem na portu na kloub, samotného mě zajímá v čem je problém a díky, že se věnujete i tak muzejním kouskům HW
mi jako úplně elegantní řešení nepřijde.