Od jakiegoś czasu rozwijam pewien projekt oparty na PIC32MX795F512,
który korzysta z wbudowanego w ten mikrokontroler sterownika MAC, z
zewnętrznym układem PHY (DP83848). W wielkim skrócie jest to stacjonarny
odtwarzacz plików z audio, z funkcją odbierania streamów po HTTP.

Firmware napisałem za pomocą bibliotek Harmony3 od Microchipa oraz
FreeRTOS. O ile sama aplikacja działa całkiem nieźle, to nie mogę sobie
poradzić z pewną uciążliwą przypadłością - co jakiś czas łączność
sieciowa zawiesza się. I to w tak dziwny sposób, że zawias wywala
łączność we wszystkich urządzeniach podłączonych do tego samego switcha.
Jestem pewien, że przyczyną jest moja płytka, bo prowadziłem testy z
kilkoma różnymi switchami i za każdym razem wygląda to dokładnie tak samo.

Objawy są następujące:
- W pewnym momencie urządzenie traci łączność z siecią. Przestaje
odpowiadać na pingi, nie można się dostać do prostego serwera HTTP
(obsługującego webUI), a socket odbierający w danym momencie stream
audio przestaje otrzymywać dane.
- Co więcej, w tym samym momencie przestaje działać łączność sieciowa na
wszystkich urządzeniach podpiętych do tego samego switcha.
- Dioda ACT na gniazdku ethernetowym mojej płytki świeci ciągle, zamiast
migać w rytm przesyłanych pakietów.
- Co ciekawe problem często nie ustępuje po soft-resecie albo nawet
pełnym power cycle - po ponownym podpięciu zasilania dioda ACT błyśnie
parę razy, a w chwilę później znów zaczyna świecić. W takiej sytuacji
trzeba chwilę odczekać przed ponownym podłączeniem zasilania. Takie
zachowanie nie występuje jednak zawsze. Często zwykły, programowy reset
wystarcza w zupełności.
- Częstotliwość występowania problemu jest różna. Czasem występuje raz
na kilka dni, czasem kilka razy jednego dnia.

Co sprawdziłem do tej pory:
- Włączyłem opcję raportowania zajętości tej części sterty, która jest
wydzielona na użytek stosu TCP/IP. Nie zauważyłem, żeby problem
korelował z brakami miejsca na stercie. Zwiększenie rozmiaru sterty w
niczym nie rozwiązuje problem.
- Próbowałem podnieść rozmiary stosu dla tasków FreeRTOS-a związanych z
TCP/IP, ale nie przyniosło to żadnego efektu.
- Próbowałem manipulować rozmiarami rozmaitych buforów wykorzystywanych
przez TCP/IP, żeby oszczędzić pamięć. W niczym to nie pomogło.

Dodatkowo: jakiś czas temu opracowałem nową wersję płytki do tego
urządzenia, z dużo mocniejszym MCU (PIC32MZ2048). Tam nie zauważyłem
jeszcze nigdy podobnego objawu. Może jest to związane z większą ilością
zasobów sprzętowych - samo procesor jest znacznie szybszy, mogłem też
ustawić większe rozmiary sterty oraz jej części przeznaczonej dla zadań
TCP/IP.

Można by co prawda próbować zrzucić winę na fakt, że urządzenie jest
zbudowane na samodzielnie trawionej (dwustronnej) płytce. Jednak poza
tymi dziwnymi zawiasami nie występują absolutnie żadne problemy z
łącznością, nie zauważyłem ani jednego zgubionego pakietu podczas
normalnej pracy. Poza tym zbudowałem jeszcze kilka innych urządzeń z
DP83848 (w tym również z mikrokontrolerami STM32) na samodzielnie
trawionych płytkach i nigdy nie miałem z tego tytułu żadnych problemów.

Ktoś ma jakiś pomysł co do możliwej przyczyny? Szczególnie zastanawia
mnie to wywalanie łączności na wszystkich urządzeniach podpiętych do
tego switcha. W wolnej chwili spróbuję podpiąć Wiresharka i zobaczyć co
tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się z
czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

do góry

On 5.02.2024 20:34, Atlantis wrote:

> Ktoś ma jakiś pomysł co do możliwej przyczyny? Szczególnie zastanawia
> mnie to wywalanie łączności na wszystkich urządzeniach podpiętych do
> tego switcha. W wolnej chwili spróbuję podpiąć Wiresharka i zobaczyć co
> tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się z
> czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

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ć.

--
Mirek.

do góry

On Mon, 5 Feb 2024 20:57:52 +0100, Mirek <m...@n...dev> wrote:
> 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.

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.

--
Marek

do góry

On Mon, 5 Feb 2024 20:34:17 +0100, Atlantis <m...@w...pl>
wrote:
> tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się
> z
> czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

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?

--
Marek

do góry

On 5.02.2024 22:13, Marek wrote:

> 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.

do góry

Miałem kiedyś problem taki , że na mierniku agilent 34461A podpiętego do
LANu z inetem wywalało okienko z błędem. Chamski WEB error.

Wywalał się tylko wtedy gdy do sieci wpięty był modem/router LTE od
T-Mobila i jego implementacja IPv6.

kupiłem nawet na okazję debugowania tego switcha z mirroringiem portów.
Złapałem nawet całą sytuację na wiresharku i wysłałem do Agilenta.

Ale mieli na to wyjebane odpisując , że przy kolejnej rewizji softu zobaczą.

Może zatem u Ciebie coś podobnego. Jakaś dziwna jumbo ramka wypiernicza
phy lub maca. Albo jakiś inny problem się nakłada na brak odporności.

Powodzenia. Żeby cokolwiek zobaczyć trzebaby mieć switcha z mirrorem i
na tym porcie nagrywać.

Pozdrawiam
Adam Górski


> Od jakiegoś czasu rozwijam pewien projekt oparty na PIC32MX795F512,
> który korzysta z wbudowanego w ten mikrokontroler sterownika MAC, z
> zewnętrznym układem PHY (DP83848). W wielkim skrócie jest to stacjonarny
> odtwarzacz plików z audio, z funkcją odbierania streamów po HTTP.
>
> Firmware napisałem za pomocą bibliotek Harmony3 od Microchipa oraz
> FreeRTOS. O ile sama aplikacja działa całkiem nieźle, to nie mogę sobie
> poradzić z pewną uciążliwą przypadłością - co jakiś czas łączność
> sieciowa zawiesza się. I to w tak dziwny sposób, że zawias wywala
> łączność we wszystkich urządzeniach podłączonych do tego samego switcha.
> Jestem pewien, że przyczyną jest moja płytka, bo prowadziłem testy z
> kilkoma różnymi switchami i za każdym razem wygląda to dokładnie tak samo.
>
> Objawy są następujące:
> - W pewnym momencie urządzenie traci łączność z siecią. Przestaje
> odpowiadać na pingi, nie można się dostać do prostego serwera HTTP
> (obsługującego webUI), a socket odbierający w danym momencie stream
> audio przestaje otrzymywać dane.
> - Co więcej, w tym samym momencie przestaje działać łączność sieciowa na
> wszystkich urządzeniach podpiętych do tego samego switcha.
> - Dioda ACT na gniazdku ethernetowym mojej płytki świeci ciągle, zamiast
> migać w rytm przesyłanych pakietów.
> - Co ciekawe problem często nie ustępuje po soft-resecie albo nawet
> pełnym power cycle - po ponownym podpięciu zasilania dioda ACT błyśnie
> parę razy, a w chwilę później znów zaczyna świecić. W takiej sytuacji
> trzeba chwilę odczekać przed ponownym podłączeniem zasilania. Takie
> zachowanie nie występuje jednak zawsze. Często zwykły, programowy reset
> wystarcza w zupełności.
> - Częstotliwość występowania problemu jest różna. Czasem występuje raz
> na kilka dni, czasem kilka razy jednego dnia.
>
> Co sprawdziłem do tej pory:
> - Włączyłem opcję raportowania zajętości tej części sterty, która jest
> wydzielona na użytek stosu TCP/IP. Nie zauważyłem, żeby problem
> korelował z brakami miejsca na stercie. Zwiększenie rozmiaru sterty w
> niczym nie rozwiązuje problem.
> - Próbowałem podnieść rozmiary stosu dla tasków FreeRTOS-a związanych z
> TCP/IP, ale nie przyniosło to żadnego efektu.
> - Próbowałem manipulować rozmiarami rozmaitych buforów wykorzystywanych
> przez TCP/IP, żeby oszczędzić pamięć. W niczym to nie pomogło.
>
> Dodatkowo: jakiś czas temu opracowałem nową wersję płytki do tego
> urządzenia, z dużo mocniejszym MCU (PIC32MZ2048). Tam nie zauważyłem
> jeszcze nigdy podobnego objawu. Może jest to związane z większą ilością
> zasobów sprzętowych - samo procesor jest znacznie szybszy, mogłem też
> ustawić większe rozmiary sterty oraz jej części przeznaczonej dla zadań
> TCP/IP.
>
> Można by co prawda próbować zrzucić winę na fakt, że urządzenie jest
> zbudowane na samodzielnie trawionej (dwustronnej) płytce. Jednak poza
> tymi dziwnymi zawiasami nie występują absolutnie żadne problemy z
> łącznością, nie zauważyłem ani jednego zgubionego pakietu podczas
> normalnej pracy. Poza tym zbudowałem jeszcze kilka innych urządzeń z
> DP83848 (w tym również z mikrokontrolerami STM32) na samodzielnie
> trawionych płytkach i nigdy nie miałem z tego tytułu żadnych problemów.
>
> Ktoś ma jakiś pomysł co do możliwej przyczyny? Szczególnie zastanawia
> mnie to wywalanie łączności na wszystkich urządzeniach podpiętych do
> tego switcha. W wolnej chwili spróbuję podpiąć Wiresharka i zobaczyć co
> tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się z
> czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

do góry

On Tue, 6 Feb 2024 18:46:58 +0100, Adam
Górski<g...@w...pl> wrote:
> Miałem kiedyś problem taki , że na mierniku agilent 34461A
> podpiętego do
> LANu z inetem wywalało okienko z błędem. Chamski WEB error.

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

--
Marek

do góry

On 5.02.2024 22:09, Marek wrote:

> 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.

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.

--
Mirek.

do góry

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.

do góry

>> Miałem kiedyś problem taki , że na mierniku agilent 34461A podpiętego
>> do LANu z inetem wywalało okienko z błędem. Chamski WEB error.
>
> Co ma warstwa 7 OSI do warstwy 4?
> Ewidentnie problem jest raczej poniżej warstwy 5.
>

Ty mi powiedz.

Pozdrawiam

Adam Górski

do góry