Turris na půdě - výpadky 1gbps/100mbps

Zdravím!

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.

Díky

Ahoj,
zkus se podívat přes SSH na statistiky jednotlivých interface. Toho docílíš zadáním příkazu ip -s link show

Výpis bude vypadat nějak takto

root@prg-mox:~# ip -s link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped missed  mcast   
    502403334  1169642  0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    502403334  1169642  0       0       0       0       
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether d8:58:d7:00:cd:0c brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped missed  mcast   
    1677103363 26396052 0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    41281351   173455   0       0       0       0       
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether d8:58:d7:00:cd:0d brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped missed  mcast   
    270678     2495     0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    535734     4857     0       0       0       0       
4: lan1@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:cd:0d brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped missed  mcast   
    0          0        0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0       

a podívej se na hodnoty errors/dropped/missed/carrier. Případně sem pošli výstup.

*Teplota na půdě je samozřejmě vysoká, zřejmě i vyšší než byl Turris designován.*

*** Podstatná otázka … jaké jsou teploty procesoru ?

Tipnul bych to přehřívání. Možná to ovlivňuje trafa na portech.

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 :smiley: 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)

Ahoj @vlk, díky za Tvoje poznatky, vyzkoušíme u nás v labu (až se nám podaří sehnat Terminátora) a podíváme se na to.

Ještě dotaz, děje se ti tohle i na TOS5?

2 Likes

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á :smiley:

1 Like

Dobrá, i tak díky za informace!

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 :smiley:

1 Like

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

Ahoj vlku!
Dneska nám distributor konečně doručil Terminátora; po neděli postavím improvizovaný xDSL lab a podíváme se co se eventuálně děje.

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á :smiley: :smiley: :smiley:

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 :smiley:

1 Like