Compleet onverklaarbare switch reboots

[Tomby]

Ik zie het verband niet tussen een lekstroom op je coax mantel en een reboot van een switch die enkel via UTP verbonden is.

Nu je het zegt, de U in UTP is 'unshielded', dus via de netwerkkabels kan alleszins al niets tot bij die switch komen...

[Ordon]

Er treden potentaal verschillen op.
Hoe zit het met de aarding op beide/alle plaatsen?
Zit daar een verschil op?

Wordt de aarding goed doorgeven?
Minderwaardige stekkerdozen misschien?

Ter info.
In een groot bedrijfsgebouw (met indertijd nog een Coax netwerk, met repeaters) was uiteindelijk de enige oplossing een lange ononderbroken koperen kabel die begin- en eindpunt met elkaar verbond.
Pas dan waren de random problemen van de baan.
Men zou verwachten dat die Coax shielding over de honderden meters zou voldoen.
Nope.
De elektrische bekabeling in het gebouw was nochtans topnotch.

Zie ook eens hier: aardlus.

[DarkV]

Nu ik dacht dat de oorzaak van de spanning op de coax gekend was... schakel het toestel dan gewoon uit.

Probleem analyse begint met zoveel mogelijk dingen uit te zetten en zo terug op te bouwen.

[Tomby]

Nu ik dacht dat de oorzaak van de spanning op de coax gekend was... schakel het toestel dan gewoon uit.

Neen, na hopen dingen uittrekken en te zien of ik vonkjes kon trekken, heb ik nog altijd geen eenduidig antwoord op die vraag. Vandaar dat ik toch beter eens investeer in een goede multimeter (komt altijd van pas) die mij de max spanning kan tonen over pakweg een minuut tijd. Met de vinger voelen of vonkjes proberen te trekken is niet bepaald een betrouwbare/wetenschappelijke methode.

[Sasuke]

Voor een switch van amper 80 EUR heb je er al wreed veel tijd in gestoken
Heb je nu al eens getest of het probleem ook optreed als er NIETS is aangesloten en/of client per client (buiten het AP) ? Op een uur of 4 heb je toch wel alles geëlimineerd niet ?

[CCatalyst]

Echter, momenteel crasht hij weer om de paar uur.

Noteer je de tijdstippen van de crashes (bij benadering) om eventueel een patroon te zien?

Zoja, eens posten.

Voor een switch van amper 80 EUR heb je er al wreed veel tijd in gestoken

Ik zit er meer mee in dat z'n verlof straks gedaan is en de case/topic uitsterft zonder oplossing, zoals wel vaker op UB .

Is wel interessant om te volgen allemaal (ook de gedachtengang).

[Kiwivogel]

Omdat ik eigenlijk gewoon wat standaard antwoorden verwacht als: heb je de laatste firmware, of stuur hem op, we sturen een andere, of misschien zelfs gewoon gaan zeggen dat hij werkt... Een andere switch aanbieden gaat het probleem niet oplossen gezien ik het probleem met beide units heb hier thuis.

Dat is een aanname natuurlijk, maar ik denk dat ze daar wellicht toch dieper op in zullen willen gaan. Je wil als vendor toch continu de kwaliteit van je producten verbeteren? Waarom zouden ze anders FW updates maken?

Verder kan het ook zijn dat ze je een ander model aanbieden wegens een gekend probleem, dat kan dan toch ook de oplossing zijn? Dan kan je ineens ook stoppen met zoeken en is het probleem gekend.

[Tomby]

Voor een switch van amper 80 EUR heb je er al wreed veel tijd in gestoken
Heb je nu al eens getest of het probleem ook optreed als er NIETS is aangesloten en/of client per client (buiten het AP) ? Op een uur of 4 heb je toch wel alles geëlimineerd niet ?

Mja, ik blijf een nerd die onrustig blijft zolang ik iets niet begrijp of kan verklaren .
En neen, op 4u tijd heb je het niet allemaal geëlimineerd, integendeel, om de simpele reden dat de switch ook uren lang probleemloos blijft werken en de tijdstippen van de reboots compleet random lijken. Er is geen patroon in, en soms crasht hij ook in de vroege uren als iedereen hier ligt te slapen en de kamers lekker afgekoeld zijn. Om die reden is een hitte-probleem zo goed als uitgesloten, maar even zeer is het feit dat een client dit zou triggeren ook daarom heel onwaarschijnlijk.

Er zijn in elk geval nog wat scenarios die ik plan te doen voor uitgebreide tijd.
1. Toch eens verder draaien zonder AP. Uptime van de switch kan ik niet aflezen, maar de traffiek-statistieken worden dan wel gerest, dus ik laat hem eerst een paar minuten met AP aan, en trek dan het AP uit zodat ik wat >0 counters heb op die poort als een soort reboot-detectie.
2. Draaien met AP maar met gewijzigde SSID zodat er geen clients aan hangen.
3. Eens switch + MoCA (voor de uplink) + AP volledig standalone in de kamer hiernaast plaatsen.

Ik zit er meer mee in dat z'n verlof straks gedaan is en de case/topic uitsterft zonder oplossing, zoals wel vaker op UB .

Op zich is het allemaal niet zo time consuming. Ik denk dat ik meer tijd spendeer aan het hier posten en lezen, dan effectief aan de setup sleutelen. Uiteindelijk is het ook telkens maar een paar minuten werk, en dan weer afwachten wat het gaat geven, met nu en dan eens een check van de uptime.
Sowieso blijf ik jullie op de hoogte houden , ben het voorlopig nog niet beu.

[Tomby]

Ik ga het bij deze wel weer jynxen (vooral omdat de verklaring geen steek houdt), maar de switch, met alles aangesloten, is ondertussen al 48u up. Nu, als ik het jynx, des te beter, want dan kan ik verderzoeken .

Maar buiten die slimme weegschaal die nog altijd uit staat (batterijen eruit) is er eigenlijk maar 1 ding anders : de Dreamcast zit niet in het stopcontact. Bij het zoeken naar dat probleem met spanning op de coax shielding, kwam ik uiteindelijk uit op de Dreamcast, zij het toch niet met 100% zekerheid. Sindsdien zit die dus niet meer in het stopcontact.

Maar zoals ik in mijn eerste zin schreef, zou ik totaal niet weten hoe die Dreamcast invloed kan hebben. Om te beginnen heeft die geen netwerk en zit dus niet in de switch. Als hij effectief spanning op de shielding zet, dan wordt die via de AV-kabel naar de versterker, en van daar naar de coax naar beneden als lekstroom afgevoerd. Maar sowieso is er via shielding/massa niets met de switch verbonden, want netwerkkabels hebben geen shielding. Dan eventueel 'straling', want de Dreamcast staat in de buurt van de switch, maar we spreken over ongeveer 20 cm. No way toch dat dit een invloed kan hebben ?

[Tomby]

Ik zit er meer mee in dat z'n verlof straks gedaan is en de case/topic uitsterft zonder oplossing, zoals wel vaker op UB .

Zoals beloofd ging ik hier zeker nog op terug komen.. alleen helaas nog niet met een oplossing, maar integendeel met een nog vreemdere vaststelling.

Om te beginnen was het wel zo dat de crashes blijkbaar niet enkel boven in onze home cinema voorvielen, maar toch ook soms in mijn bureau. Naar mijn gevoel waren de uptimes in de bureau wel beduidend hoger dan in de cinema-kamer.

Nadat ik alweer enkele keren er tegenaan liep dat de switch rebootte terwijl ik een stream aan het bekijken was, online aan het gamen was, of met familie aan het facetimen was, toch maar beslist om nog eens opnieuw langdurig te testen. Ik begon met in de cinema-kamer alles uit de switch te trekken, behalve de uplink. De uplink gaat via MoCA naar de garage waar de Telenet router hangt. De redenering hierachter was om uit te sluiten dat het ergens een broadcast van bvb de Telenet router was, die de switch doet crashen, en dus niet een van de toestellen in de cinema-kamer. Na een dag of 10 was er nog altijd geen enkele reboot gebeurd van beide routers, dus ik had een stabiele baseline.

Vervolgens plug ik in de cinema-kamer de netwerk-kabel van mijn TV in. En nu komt het vreemde. Na 3 dagen kreeg ik de eerste reboot, echter, niet van de switch in de cinema-kamer maar van de switch in mijn bureau ?!? Sinds ik de TV boven in de switch geplugd heb ruim een week geleden, heb ik al een viertal reboots gedetecteerd van die switch beneden. De switch waar de TV op hangt (met daarnaast dus enkel de MoCA uplink) is nog altijd niet down geweest en heeft nu al een uptime van bijna 3 weken. Begrijpe wie kan. Het vreemde is overigens dat enkele van de reboots beneden ook gebeurden terwijl boven niet eens de TV aan stond (bvb een van de reboots was om 5u30 toen iedereen nog sliep).

Ik ben dus eigenlijk nog verder van huis dan ervoor, lijkt het. Mijn ideeën op dit moment:
1. Ik moet rekening houden met de kleine statistische kans dat de reboots nog altijd random gebeuren, en ik gewoon pech heb met wanneer wat reboot dat ik er de verkeerde conclusies uit trek. Sowieso is dat de moeilijkheid in dit hele avontuur: de zekerheid van correlatie tussen wat ik test en wanneer de reboots gebeuren neemt toe naarmate ik een test langer laat lopen. Maar als ik bij elke test 2 weken moet wachten eer ik een bepaalde conclusie trek, zijn we 2023 eer ik rond ben (en dan nog ben ik nooit zeker).
2. Helemaal in het begin van dit 'avontuur' was het duidelijk de switch boven die regelmatig crashte. Onderweg heb ik een gegeven moment de switches omgewisseld, waarbij op dat moment dat omwisselen er niet voor zorgde dat de crashes ook omwisselden. Nochtans kan dat wel een verklaring zijn waarom ik nu ineens wel zie dat het de switch beneden is die om de paar dagen crasht.
3. En zoals door anderen al voorgesteld of geïnsinueerd, moet ik het misschien maar gewoon loslaten en gewoon de switches vervangen door iets anders. Want zelfs mocht ik uiteindelijk toch een verklaring vinden voor de crashes, is de kans vrij groot dat ik er niets ga kunnen aan doen en ik vooralsnog toch andere hardware ga moeten kopen. Soms moet je gewoon opgeven en aanvaarden dat er dingen zijn waar je nooit een antwoord op zal hebben.

EDIT: overigens is TP-Link Support wel zeer snel, maar kwamen ook niet verder dan evidente vragen rond DHCP en dergelijke, en dan concluderen dat reboots niet normaal zijn en ik mijn winkel moet contacteren voor garantie-omruiling.