On 13.03.2024 20:33, Atlantis wrote:

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

--
Mirek

do góry

On 13.03.2024 22:19, Mirek wrote:

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

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.

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

do góry

On Thu, 14 Mar 2024 09:47:44 +0100, Atlantis wrote:
> On 13.03.2024 22:19, Mirek wrote:
>> 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 ?
>
> No i to jest właśnie zastanawiające. MAC jest dziwny i zdecydowanie nie
> należy do samego urządzenia.

Taki protokół?

https://osqa-ask.wireshark.org/questions/4799/spanni
ng-tree-for-bridges_01-flooding-my-network/
jeś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.

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

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

> Najbardziej jednak zastanawia mnie fakt, że problem najwyraźniej jest
> związany z najniższą warstwą.

Bo wychodzi, ze najnizsza ...

J.

do góry

On 14.03.2024 09:47, Atlantis wrote:

> Tak więc raczej nie wygląda na to, żeby interfejsy były fizycznie
> zapychane powodzią ramek broadcastowych.
>
No dobra, a jakiekolwiek pakiety wtedy dochodzą?
Są jakiekolwiek prawidłowe pakiety od tego urządzenia?

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

> 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 a jesteś w stanie podejrzeć komunikację pomiędzy PIC a PHY? - ciekawe
co tam się wtedy dzieje.

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

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.

--
Mirek

do góry