u

Feb 05, 2024 Last reply: 2 years ago 50 Replies

Finalnie urządzenie chodziło podłączone do laptopa w Wiresharkiem przez trochę ponad tydzień. Problem nie pojawił się ani razu, wszystko działało perfekcyjnie stabilnie. Potem podłączyłem płytkę do nieco lepszego gigabitowego switcha (TP-Link TL-SG1024D). Od tego momentu minęły już prawie trzy doby i jak dotąd problem nie wystąpił. Jeszcze za wcześnie, żeby to stwierdzać ze 100% pewnością, ale trochę wygląda na to, że źródło problemu jest związane z najniższą warstwą. Najwyraźniej znaczenie ma to, co znajduje się po drugiej stronie kabla Ethernetowego. Awaria nie wystąpiła po podłączeniu crossem do taniej karty USB Ethernet wpiętej w laptopa oraz (przynajmniej jak na razie) do lepszego switcha. Występowała natomiast w przypadku domowego routera oraz tanich, starych, plastikowych 100Mbps switchy TP-Linka.

Skoro nie udało mi się zebrać ruchu na interfejsie sieciowym samej płytki w momencie awarii, w dalszej kolejności spróbuję zrobić kolejną najlepszą rzecz - zobaczę jak to wygląda z perspektywy jednego z komputerów podpiętych do tego samego switcha w momencie, gdy pada łączność.

Ale mówimy tu o utracie możliwości zainicjowania połączenia przy jednoczesnej możliwości połączenia do urządzenia czy o całkowitym zablokowaniu ethernetu - bo już się pogubiłem (i możliwe że sam to poknociłem)?

Dwie uwagi: Dawno nie widziałem urządzenia, które wymaga kabla cross (chyba że PoE) Te ogonki usb <> ethernet bywają tak podłe, że nie mają nawet transformatorków - jaja są z potencjałami.

Tak jeszcze BTW: widziałem już różne cuda z ethernetem, np zdarzyła mi się kamera, która działała parę lat na odwróconej parze 1-2 (biało-pomarańczowy zamieniony z pomarańczowym z jednej strony). Klient skarżył się, że czasem się zwiesza, ale to było raz na parę tygodni i pomagał restart switcha PoE. Aż któregoś pięknego dnia po burzy padł rzeczony switch - wymieniamy, ale ta jedna kamera nie wstaje. Podmieniamy kamerę... nie wstaje. Sprawdzamy kabel... szczena nam opada bo jest odwrócona para. Poprawiamy, podłączamy starą kamerę, która działa i już się później nie zawiesza.

Mówimy o całkowitym zablokowaniu Ethernetu na poziomie całego switcha. Dioda ACT na urządzeniu zaczyna się świecić cały czas, a ono samo traci kontakt z siecią. Jednocześnie łączność tracą wszystkie inne urządzenia, podłączone do tego samego switcha. Problem z zainicjowaniem połączenia klienta był osobną kwestią, o której wspominałem przy okazji. Najwyraźniej ustąpił po wgraniu poprawek kilku błędów, które zauważyłem w międzyczasie (najpewniej chodziło o korzystanie z malloc/free zamiast pvPortMalloc/vPortFree).

Tak, wiem. Ale to raczej siła przyzwyczajenia. Skoro miałem pod ręką scrossowany kabel, to postanowiłem go wykorzystać, skoro już łączyłem urządzenia bezpośrednio. Raczej w niczym to nie zaszkodziło, a połączenie przez tydzień działało stabilnie.

No cóż, to było jedynie urządzenie, jakie miałem pod ręką do wykorzystania na szybko. No i jak mówię - w tym wypadku się sprawdziło. A w tym konkretnym przypadku transformatorek jest - widać do przez półprzezroczystą obudowę. ;)

Też o tym pomyślałem, ale taką opcję wyeliminowałem na samym początku, testując z kilkoma różnymi kablami i switchami. Tak więc to nie jest kwestia niekontaktującego styku, złego kabla albo uwalonego portu w switchu.

Prawdę mówiąc stawiałem na to, że przyczyna będzie leżała na warstwie MAC lub wyżej. Ten sam układ PHY (DP83848) wykorzystałem już w kilku różnych projektach, z kilkoma różnymi MCU, używając identycznego układu ścieżek na PCB (oczywiście z pominięciem linii interfejsu RMII, które są unikalne dla konkretnego typu mikrokontrolera) i podobny problem nigdy nie wystąpił. Stawiałem albo na jakiś bug programowy, albo problem z kontrolerem MAC w strukturze PIC32MX795F512, albo ewentualnie jakiś problem na liniach interfejsu RMII. Wtedy jednak awaria powinna wystąpić też przy testach z laptopem. Tymczasem to zaczyna wyglądać na problem na warstwie fizycznej, ograniczony do sytuacji, kiedy po drugiej stronie kabla znajdują się dość konkretne urządzenia...

Przy zapętleniu cały switch mruga nieprzerwanie jak szalony - tego nie da się pomylić z normalnym zachowaniem. No chyba, że tam masz jakieś multicasty, albo kamery tam chodzą i generują ciągły ruch.

Nie mam pojęcia - może jakieś przesłuchy, ale to mało realne.

No cóż... Urządzenie w chwili obecnej pracuje już ponad tydzień podpięte do lepszego, gigabitowego switcha. Wygląda więc na to, że problem z zawieszaniem się i wywalaniem komunikacji na całym switchu dotyczy tylko niektórych modeli. Ciekawe co może powodować takie zachowanie...

Kiedys mi znajomy mowil ze jakis soft sie wywalal ale nie dalo sie tego zdebugowac bo jak lecial przez strace to sie nie wywalal.

Pewnie jakies warunki wyscigowe i strace spowalnialo nieco te krytyczna czesc. Ale tak to czasem jest, mierzysz i wplywasz na uklad.

W końcu udało mi się podejrzeć sytuację podczas awarii. Jak wspominałem, nie byłem w stanie zreplikować problemu z laptopem wpiętym pomiędzy urządzenie a switcha. Zrobiłem więc kolejną najlepszą rzecz - zobaczyłem co się dzieje na interfejsie sieciowym komputera, który jest podłączony do wspomnianego switcha. Okazuje się, że jest on spamowany znaczną liczbą następujących wiadomości:

Source: 00:00:00_00:00:01 Destination: MAC-specific-ctrl-proto-01 Protocol: MAC CTRL Length: 60 Info: Pause: pause_time: 65535 quanta

Hex dump przykładowej ramki:

0000 01 80 c2 00 00 01 00 00 00 00 00 01 88 08 00 01 0010 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00

Ktoś ma jakiś pomysł co do przyczyny takiego zachowania?

Pomysły to może mieć każdy ;) Żeby rozwiązać problem warto zadawać pytania (nawet głupie): Ja to rozumiem, że urządzenie wysyła: "czekaj, teraz nie mogę", ale czemu źródłem jest MAC 00-00-00-00-00-01 ? I czemu komunikacja zamiera? Ten komunikat powinien interesować tylko te urządzenia, które chcą nadawać do tego konkretnego MAC-a (jaki by nie był), reszta komunikacji powinna działać normalnie.

No i to jest właśnie zastanawiające. MAC jest dziwny i zdecydowanie nie należy do samego urządzenia.

Znaczniki czasowe pomiędzy kolejnymi pakietami wyglądają następująco:

0.000000 0.008097 0.015954 0.023974

Tak więc raczej nie wygląda na to, żeby interfejsy były fizycznie zapychane powodzią ramek broadcastowych.

Najbardziej jednak zastanawia mnie fakt, że problem najwyraźniej jest związany z najniższą warstwą. Podczas kilkutygodniowych prób awaria pojawiała się tylko w przypadku podłączenia do niektórych urządzeń (stare i tanie switche 100 Mbps TP-Linka, router tej samej firmy) ale nie byłem w stanie jej zaobserwować na lepszym, gigabitowym switchu albo przy podłączeniu przez komputer pracujący w trynie bridge'a do przechwytywania pakietów.

Gdyby po prostu urządzenie zaczynało po jakimś czasie siać pakietami mógłbym zrzucić winę na MAC w PIC32MX795F512L albo jakiś błąd w sterowniku z Harmony. Jednak tutaj znaczenie ma jeszcze to, co znajduje się po drugiej stronie kabla. No i efekt jest naprawdę dziwny.

No cóż... Tak naprawdę nie mogę być w 100% pewien, że ten komunikat jest tym, co wychodzi z mojego urządzenia i wszystkim co z niego wychodzi. Nie byłem w stanie zreplikować problemu, gdy do urządzenia był podpięty komputer przechwytujący cały ruch. Teraz widzę więc tylko to, co dociera do komputera na innym porcie switcha dotkniętego problemem. Może z urządzenia wychodzi więcej śmieci, ale switch je dropuje i w efekcie pakiety "pause" z dziwnym MAC-iem są jedynym, co przechodzi przez sito?

Taki protokół?

formatting link
śli dobrze tłumaczą, to jest to celowe żądanie pauzy, bo np switch nie nadąża.

Pytanie kto u Ciebie to żądanie wysyła, i dlaczego, i czy switch nie wariuje od tego.

A powyzej piszą, ze to może być zatrzymanie na 4ms ... co było ograniczeniem do 50% ...

Bo wychodzi, ze najnizsza ...

J.

No dobra, a jakiekolwiek pakiety wtedy dochodzą? Są jakiekolwiek prawidłowe pakiety od tego urządzenia?

Można jeszcze ustawić filtr we wiresharku na takie pakiety i poobserwować - może też występują (choćby sporadycznie), ale mocniejszy switch daje sobie radę.

No a jesteś w stanie podejrzeć komunikację pomiędzy PIC a PHY? - ciekawe co tam się wtedy dzieje.

No tak, i tak naprawdę nie wiemy co te komunikaty wysyła i czy one są powodem problemów czy skutkiem. Ja bym jeszcze sprawdził, czy problem replikuje się na inny podłączony podczas tej usterki switch - czy np, przez niego też nie będzie komunikacji i czy inny niż TP-link będzie na to odporny.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required