u

Koniecznie odpal Wiresharka i zobacz co się dzieje. Jak kładzie całą sieć, to możliwe, że odpowiada na każdy pakiet TCP - tak jakby nie filtruje własnego MAC-a - każdy traktuje jak swój i w rezultacie switch wszystkie pakiety kieruje do niego. Drugi problem może być z samym układem PHY - wtedy prawdopodobnie nic nie zobaczysz. Z tym pierwszym przypadkiem spotkałem się OIDP tylko raz i co ciekawe tak się zachowywała końcówka GPON operatora. Z drugim przypadkiem spotkałem się wielokrotnie - zwykle był to switch z kategorii mały, tani 4-ro, 8-mio portowy, ale też pamiętam Mikrotika i mediakonwerter MOXA - tak że nie ma reguły. Na Wiresharku nic nie widać - po prostu z czasem pakiety nie dochodzą i tyle. Po odłączeniu pacjenta od sieci sytuacja wraca do normy, ale dopiero po pewnym czasie. Tak samo po podłączeniu problem zaczyna się robić z dużym opóźnieniem, tak że w rozległej sieci ciężko coś takiego namierzyć.

Mógłbyś to precyzyjniej opisać? Przecież to switch decyduje co komu wg tablicy, który MAC "widać" na danym porcie. Urządzenie musiałoby odpowiadać na każdy whohas o dowolny IP co jest nieprawdopodobne w stosie mchp. Jak przez mgłę kojarzę bardzo podobny przypadek jaki miałem z tym stosem (nagła niewidzialność innych urządzeń) ale niestety nie mogę sobie przypomnieć wniosków z diagnostyki.

Rozumiem, że aplikacja działa nadal podczas zwieszki sieciowej, nie wiesza się, tylko sieć nie działa? Czy możesz periodycznie na konsole debug wyrzucać bieżącą konfigurację sieci (przydzielony IP, maska) oraz MAC? Czy czasem ona się nie zmienia po wystąpieniu zwieszki?

Tak, mogę. Zapomniałem właśnie o tym wspomnieć. Konfiguracja po stronie urządzenia nie zmienia się. Komenda "netinfo" pokazuje poprawną konfigurację. Adresy IP i MAC nie zmieniają się, system twierdzi, że interfejs sieciowy jest w stanie "up". Komenda "macinfo" pokazuje tylko tyle, że licznik odebranych/wysłanych pakietów w pewnym momencie przestaje się zwiększać.

Przyszedł mi do głowy jeszcze pomysł - uruchomiłem urządzenie na minimalnej konfiguracji. Ro znaczy zostawiłem jedynie obsługę podstawowego stosu z TCP/IP/UDP/ARP/DHCP/DNS. Wywaliłem NBNS, HTTP i biblioteki kryptograficzne związane z WOLFSSL (nawet jeśli się z niego nie korzysta, autorzy bibliotek zalecają dodanie ich do projektu, ze względu na lepsza obsługę RNG, można to jednak wyłączyć).

Jak na razie projekt się nie zawiesił, ale jak mówiłem - niekiedy działo się to po kilku dniach. Jeśli do tego nie dojdzie, będę powoli dodawał kolejne usunięte komponenty. Na pewno nie chciałbym rezygnować z HTTP, bo webUI było bardzo wygodną funkcjonalnością. Z SSL mogę na dobrą sprawę zrezygnować, bo na chwilę obecną i tak nie zaimplmenetowałem funkcji odbioru streamów HTTPS.

Co ma warstwa 7 OSI do warstwy 4? Ewidentnie problem jest raczej poniżej warstwy 5.

Nieprawdopodobne jest to, co napisałem, czyli że odpowiada na każdy MAC

- żeby to zadziałało, to musiałby odpowiedzieć pakietem z takim samym MAC-iem źródłowym jak dostał docelowy żeby zmylić switcha. Bardziej możliwe jest, że pamięć mnie zawodzi - faktycznie chyba odpowiadał na każde who has, czyli brał na siebie wszystkie IP. Szkoda, że nie zrobiłem wtedy zrzutu z wiresharka. Zwykle przy takich akcjach jest wszystko na wczoraj i nie ma czasu na dociekanie co się dzieje. Sukcesem jest znalezienie wadliwego urządzenia, a co ono tam wyprawia to już nie ma znaczenia.

No cóż... Uruchomiłem bardziej minimalistyczną wersję stosu, z wywalona obsługą HTTP, NBNS oraz WolfSSL (z towarzyszącymi mu bibliotekami). Od tamtego momentu problem wystąpił już jeden raz. Przyszedł mi do głowy jeszcze jeden pomysł. Płytka podczas testów właściwie non-stop jest pingowana przez peceta. Zobaczę jak urządzenie się zachowa, jeśli tego zaniecham na jakiś czas.

Przypomniałem sobie jeszcze, że przez pewien czas (na samym początku) urządzenie pracowało na firmware napisanym za pomocą starych bibliotek MLA. Dopiero później przeniosłem je na Harmony. Nie przypominam sobie żeby podczas testów na starym FW wystąpił taki błąd. To zmniejsza prawdopodobieństwo hipotezy, że winę ponosi problem sprzętowy.

Ty mi powiedz.

Pozdrawiam

Adam Górski

W odpowiedzi komu innemu pisałem że na 99% kilka lat temu zetknąłem się z tym samym problemem na pic32. Tylko niestety nie pamiętam, który to był stos mla czy Harmony bo w tamtym czasie używałem oba. Pamiętam blokadę "ruchu" na switchu i palącą się na stałe diodę ACT na gnieździe eth z pic32. Jak tylko przypomnę sobie co to było dam znać.

Gdyby udało się przypomnieć co to powodowało, to byłbym bardzo wdzięczny za tę informację. Na razie sprawdzam hipotezę na temat wpływu pingowania płytki na to zachowanie. Póki co od wczoraj się nie zawiesiła, ale to jeszcze niczego nie przesądza, bo nieraz problem występował dopiero po kilku dniach.

Gdy jest zwieszka i wyjmiesz wtyk eth z płytki ruch na switchu się przywraca? Czy po włożeniu wtyczki z powrotem (bez resetowania płytki) od razu diioda ACT zapala się na stałe i ruch ponownie zanika?

Tak. Komputer podłączony do tego samego switcha odzyskuje łączność natychmiast po wyjęciu kabla Ethernet z mojej płytki. Jeśli podłączę kabel ponownie, problem powraca - dioda ACT znów zaczyna świecić cały czas, chociaż komputer traci łączność z drobnym opóźnieniem.

Problem powrócił dzisiaj, czyli jednak wiadomo, że to nie pingowanie płytki było przyczyną.

Tak. Po włożeniu kabla bez resetu dioda zapala się cały czas i problem pojawia się natychmiast.

Było też kilka sytuacji, kiedy problem pojawiał się ponownie po resecie, ale wtedy dioda zdążyła jeszcze mignąć kilka razy przed zapaleniem się na stałe.

Przyszedł mi jeszcze do głowy pomysł, że może dochodzić do zagłodzenia któregoś z tasków odpowiedzialnych za łączność sieciową. Sprawdziłem i faktycznie wszystkie one mają priorytet 1 - taki sam, jak task w którym wykonuje się mój kod. Zmieniłem go na 2 i zobaczę jak teraz zachowa się urządzenie.

Tak w sumie zapomniałem dodać, że równolegle mam do czynienia z nieco podobnym problemem, którego przyczyna może (chociaż wcale nie musi) być związana z tym opisywanym powyżej.

Mianowicie jakiś czas wcześniej powstała uboższa wersja tego hardware'u, gdzie jedyną róznicą było zastosowanie układu ENC28J60 zamiast wbudowanego w PIC32MX795F512L układu MAC z zewnętrznym PHY. Ta płytka również oryginalnie pracowała na bibliotekach MLA. Jakiś czas temu postanowiłem jednak przenieść na nią nową wersję firmware (napisaną przy pomocy Harmony3). Było to dosyć proste - wystarczyło wygenerować kod w oparciu o prawie taką samą konfigurację (zmieniając jedynie kontroler Ethernetu i kilka pinów) oraz przerzucić pliki z kodem aplikacji. Urządzenie generalnie działa, ale również od czasu do czasu wywala się w nim stos TCP/IP. W tym wypadku crashe nie są jednak losowe, a dzieją się w konkretnym momencie - przy próbie dostania się do serwera HTTP. Dosłownie w momencie otwarcia adresu w przeglądarce wywala się łączność. Jeśli usunę serwer HTTP z konfiguracji (albo przynajmniej nie próbuję się z nim łączyć) urządzenia działa całkowicie stabilnie.

Tutaj także w przypadku wywalenia łączności cała reszta aplikacji działa poprawnie. Na wydzielonym dla TCP/IP fragmencie sterty jest jeszcze sporo miejsca. W "macinfo" widzę natomiast nTxPendBuffers: 3 - wartość ta się nie zmienia. Jakby nie mógł wysłać tych danych.

Nie mam zbyt dużo doswiadczenia z Harmony, Kiedyś krótko to testowałem ale nie wdrażałem produkcyjnie. Natomiast na MLA + enc28j60 mam na produkcji urządzenia chodzące już 10 rok 24h i nigdy nie było problemu z łącznością z nimi, uważam, że stos MLA jest bardzo stabilny (TCP + UDP, jedyne co nie używam, ze stosu to DHCP oraz tego ich serwera HTTP, używam własny). Był jeden incydent w trakcie jakiś testów właśnie podobny do tego co opisujesz, ale ciągle nie pamiętam szczegółów.

Ja też właśnie przez długie lata korzystałem z z MLA i ciągle korzystam z niego w projektach z mniejszymi MCU. W przypadku PIC18/PIC24 innego wyjścia właściwie nie ma, a i część PIC32 ma za mało zasobów, żeby obsłużyć Harmony. Jednak jakby nie patrzeć, MLA jest już dość starą i nierozwijaną biblioteką, która z kolei nie wspiera nowszych układów. To jest właśnie główny powód, dla którego przeniosłem ten projekt na Harmony - nowsza wersja hardware'u wykorzystuje PIC32MZ2048.

Harmony ma też swoje zalety - kod łatwo generuje się z konfiguratora, jest też dostępnych więcej bibliotek. Pamiętam, że kiedyś spędziłem kilka tygodni naprawiając jakiś krzywy kod z GitHuba, aby mieć na MLA obsługę klienta MQTT. W Harmony taki klient po prostu jest zaimplementowany.

Co do stabilności - jak wspomniałem, na PIC32MZ2048 nie natknąłem się na podobne problemy. Dlatego podejrzewam, że kwestia może się kryć gdzieś w optymalizacji konfiguracji pod kątem wykorzystania zasobów.

Pamiętasz czy to było na MLA czy Harmony? W każdym razie, odkąd wczoraj zmieniłem priorytet tasku z moja aplikacją, problem się nie pojawił. To znaczy był inny crash, ale znacznie mniej uciążliwy: klient z utracił łączność i nie chciał się połączyć ponownie (DNS wywalał błąd -5) ale nie było już efektu świecenia diody ACT i blokady ruchu na poziomie switcha. Tym razem wystarczyło tylko odpiąć o ponownie podpiąć kabel ethernetowy, bez resetowania całego urządzenia.

Ok. Wygląda na to, że ten problem udało mi się rozwiązać. Wystarczyło włączyć obsługę DMA na SPI, który obsługuje ENC28J60.

Gdzie? Driver Harmony en28j60 używa DMA? Ale jaki to ma bezpośredni związek z blokadą switcha? Liczyłem na to, że jednak zrobisz analize ruchu w tym kablu bom był ciekaw jak taka 10Mbit zabawka może takiego DOSa na współczesnym switchu spowodować

Tak. To znaczy jest taka opcja. Można wygenerować konfigurację, w której ENC28J60 jest podpięty do drivera SPI skonfigurowanego do działania w trybie DMA.

Tutaj mówimy o dwóch osobnych problemach na dwóch podobnych płytkach.

Blokowanie switcha z objawem ciągłego świecenia ACT występuje (lub występowało) na nowszej wersji hardware'u, z PIC32MX795F512 + DP83848 (a więc FastEthernet). Na razie w ramach eksperymentu zmieniłem trochę konfigurację tasków FreeRTOS-a, obniżając priorytet tego, w którym działa mój kod. Jak na razie problem z blokadą nie wystąpił, chociaż jeszcze nie mogę tego wykluczyć, bo nieraz zdarzało się kilka dni spokoju. Jeśli jednak faktycznie nie powróci to będzie oznaczało, że powodem blokady było zagłodzenie któregoś z tasków zaangażowanych w łączność TCP/IP.

Osobny problem miałem na bliźniaczej, starszej wersji płytki z PIC32MX795F512L + ENC28J60. Tam dochodziło do crasha łączności sieciowej przy próbie wejścia na stronę obsługiwaną przez serwerek HTTP odpalony na tej płytce. W tym przypadku nie dochodziło jednak do zablokowania łączności na switchu (ani ciągłego świecenia ACT). Problem nie był też losowy - można było go dość jasno skojarzyć serwerem HTTP. W tym wypadku pomogło właśnie właczenie DMA, nie wiem dlaczego.

Oczywiście obydwie płytki nadal obserwuję, bo o ile sytuacja się poprawiła nie mogę mieć pewności, że wszystkie problemy zostały rozwiązane.