Jak wspominałem w poprzednich wiadomościach, zabrałem się ostatnio za
uruchamianie "antycznego" linuksowego komputerka SBC (jeszcze sprzed
czasów Raspberry Pi) Sarge-at91. Polska konstrukcja na AT91RM9200,
działająca pod kontrolą Linuksa Angstrom. Mam dwa egzemplarze - jeden
złożony i uruchomiony, w drugim brakuje jeszcze kilku elementów.

Ostatnio podczas eksperymentów natknąłem się na ciekawą przypadłość. Za
nic nie byłem w stanie połączyć się z płytką za pomocą SSH. Proces
łączenia utyka na "expecting SSH2_MSG_KEX_DH_GEX_REPLY".
Początkowo chciałem to zrzucić na niekompatybilność pomiędzy zabytkowym
serwerem SSH na płytce, a współczesnym klientem. Googlując trafiłem
jednak na informację, że lekarstwem na podobną przypadłość (na zupełnie
innym sprzęcie) okazywała się zmiana parametru MTU na interfejsie
sieciowym serwera na mniejszą wartość. Faktycznie pomogło - zmiana MTU z
1500 na 567 umożliwiła zestawienie połączenia SSH. Wydaje mi się to
jednak dziwne, bo 1500 jest prawidłową wartością dla Ethernetu.

Z ciekawości postanowiłem zrobić jeszcze jedną rzecz - podpiąłem do USB
komputerka zewnętrzną kartę Ethernet i zestawiłem na niej połączenie.
Problem jak ręką odjął - teraz jestem w stanie połączyć się nawet przy
MTU=1500. Tak więc problem występuje jedynie na interfejsie sieciowym
AT91RM9200, z PHY STE100P. Dodatkowo wbudowany interfejs sieciowy z
jakiegoś powodu łączy się na 10Mbps, chociaż wydaje mi się, że AT91
powinien mieć już FastEthernet.

Ktoś ma jakiś pomysł co do możliwej przyczyny zachowania? Rozważania
mają charakter czysto "akademicki". Zabrałem się za uruchamianie tego
urządzenia z sentymentu, nie w praktycznym celu (od tego mam Raspberry
Pi). Jak mi się znudzi, wróci do szuflady.

Zwyczajnie zaintrygowało mnie dziwne zachowanie interfejsu sieciowego.
Łączy się, pobiera adres z DHCP, można przesyłać dane, odpowiedzi na
pingi przychodzą w obydwie strony, ale SSH się wywala o ile nie
zmniejszę MTU...

do góry

On 29/02/2024 21:28, Atlantis wrote:
> pingi przychodzą w obydwie strony, ale SSH się wywala o ile nie
> zmniejszę MTU...

Może zmniejszenie MTU spowodowało skrócenie ramki i w efekcie
statystycznie mniej błedów.

do góry

On 29.02.2024 22:14, heby wrote:

> Może zmniejszenie MTU spowodowało skrócenie ramki i w efekcie
> statystycznie mniej błedów.

Tylko to nie wygląda na efekt statystycznej akumulacji losowych błędów.
Połączenie SSH zawsze failuje w ten sam sposób, w dokładnie tym samym
punkcie.

No i do tego jeszcze dochodzi ta kwestia, że inne usługi sieciowe
działają poprawnie. Nie ma zgubionych pingów, byłem w stanie pobierać i
instalować pakiety przez opkg, serwer www też działa.

Tak generalnie z Ethernetem był jeszcze jeden drobny problem. Kernel
powinien pobrać z pamięci I2C adres MAC. Adres ten jest dostępny dla
u-boota (działa DHCP/TFTP) ale już Linux nie jest w stanie go odczytać:

at91_ether: Your bootloader did not configure a MAC address.
eth0: Link now 10-FullDuplex
eth0: AT91 ethernet at 0xfefbc000 int=24 10-FullDuplex (00:00:00:00:00:00)
eth0: STE100P PHY

Udało mi się to obejść ręcznie ustawiając MAC-a w /etc/network/interfaces.

Nie wiem czy te kwestie są ze sobą powiązane. Możliwe jednak, że mamy tu
do czynienia z objawem jakiegoś wspólnego problemu.

do góry

Atlantis napisał:

> Tylko to nie wygląda na efekt statystycznej akumulacji losowych błędów.
> Połączenie SSH zawsze failuje w ten sam sposób, w dokładnie tym samym
> punkcie.
>
> No i do tego jeszcze dochodzi ta kwestia, że inne usługi sieciowe
> działają poprawnie. Nie ma zgubionych pingów

Wszystkich? Co wykaże taki na przykład test:

#!/bin/sh
H=1.1.1.1 # lub co tam jest dostępne
for m in `seq 500 1500` ; do
ping -c1 -w 1 $H -s $m >/dev/null && echo -ne "+" || echo -e "\n-" $m
done

> byłem w stanie pobierać i instalować pakiety przez opkg, serwer www
> też działa.

Problem jest szeroki, ale też znany i uciążliwy, występuje w sieciach
operatorskich. Wychodzą tam z założenia, że skoro "fejzbuk działa",
to już niczego konfigurować nie trzeba.

--
Jarek

do góry

On 29.02.2024 23:06, Jarosław Sokołowski wrote:

> Wszystkich? Co wykaże taki na przykład test:
>
> #!/bin/sh
> H=1.1.1.1 # lub co tam jest dostępne
> for m in `seq 500 1500` ; do
> ping -c1 -w 1 $H -s $m >/dev/null && echo -ne "+" || echo -e "\n-" $m
> done
>

Nie to chyba nie jest problem przechodzenia czy nie większych pakietów,
tylko jakiś błąd czy niekompatybilność starego sshd z nowym klientem.
A że skrócenie pakietu pomaga to faktycznie ciekawe i trzeba by poczytać
u źródła tam co to rozwiązanie proponują.

--
Mirek

do góry

On 29.02.2024 23:06, Jarosław Sokołowski wrote:

> Wszystkich? Co wykaże taki na przykład test:

Hmm... Pierwszy minus pojawia się przy 676. Potem są jeszcze krótsze lub
dłuższe serie plusów, ale z każdą chwilą minusów jest coraz więcej. Tak
od około 850 idą właściwie już tylko one.
Jak to interpretować? Gdzie szukać przyczyny problemu? Sprzęt? Sterownik
karty sieciowej? Konfiguracja?

do góry

On 29.02.2024 23:45, Mirek wrote:

> Nie to chyba nie jest problem przechodzenia czy nie większych pakietów,
> tylko jakiś błąd czy niekompatybilność starego sshd z nowym klientem.

Tylko w takim razie dlaczego problem występuje tylko na jednym
interfejsie sieciowym (Ethernet wbudowany w AT91RM9200), a na innym
(karta sieciowa na USB) już nie, nawet jeśli MTU jest ustawione na 1500?

do góry

On 29/02/2024 23:53, Atlantis wrote:
> Jak to interpretować? Gdzie szukać przyczyny problemu? Sprzęt? Sterownik
> karty sieciowej? Konfiguracja?

A kwarc od ethernetu pracuje na takim f jakie ma na obudowie?

do góry

Pan Mirek napisał:

>> Wszystkich? Co wykaże taki na przykład test:
>>
>> #!/bin/sh
>> H=1.1.1.1 # lub co tam jest dostępne
>> for m in `seq 500 1500` ; do
>> ping -c1 -w 1 $H -s $m >/dev/null && echo -ne "+" || echo -e "\n-" $m
>> done
>
> Nie to chyba nie jest problem przechodzenia czy nie większych pakietów,
> tylko jakiś błąd czy niekompatybilność starego sshd z nowym klientem.

Przecież nie wiem co tam jest problemem, dlatego poprosiłem o test,
inaczej się nie dowiem.

> A że skrócenie pakietu pomaga to faktycznie ciekawe i trzeba by poczytać
> u źródła tam co to rozwiązanie proponują.

SSH bardzo często nie działa w wyniuku źle ustawionego MTU w poszczególnych
segmentach sieci. Ciągle się na to napotykam.

Nawet w domowych łączach internetowych to widać. Ja mam w domu GPON i
chiński router od operatora. Jego serwer DHCP sprzedaje klientom wartość
MTU 1492, tak jak tego wymaga reszta sieć -- i wtedy wszystko działa.
Znajomi mają podobne łącze, operator dał im prosty modem, a za nim postawił
router WiFi z MediaMarktu. On o sieci nie wie nic, rozgłasza 1500 i...
wiele rzeczy nie działa. No, strony WWW przeważnie da się oglądać.

--
Jarek

do góry

Atlantis napisał:

>> Wszystkich? Co wykaże taki na przykład test:
>
> Hmm... Pierwszy minus pojawia się przy 676.

I takie MTU powinno być na tym interfejsie. Że dziwnie małe? Trudno.

> Potem są jeszcze krótsze lub dłuższe serie plusów, ale z każdą chwilą
> minusów jest coraz więcej. Tak od około 850 idą właściwie już tylko one.
> Jak to interpretować? Gdzie szukać przyczyny problemu? Sprzęt? Sterownik
> karty sieciowej? Konfiguracja?

Jak napisałem wcześniej, problem jest szeroki, przyczyn może być wiele,
samemu trudno będzie coś z tym zrobić. Trzeba polubić. W technologii LTE
jest jakaś taka "ciekawa" wartość MTU, nie aż tak niska, ale niższa niż
1500, nie przypomnę sobie teraz dokładnej wartości. Modem widziany jest
w systemie jako interfejs ethernetowy. Wydawałoby się więc, że tam ma
być MTU 1500. Ale nie zawsze może, bo nie zawsze cosie po drodze radzą
sobie z fragmentacją i defragmentacją (to wszystko w uproszczeniu, niech
nikt się za nie mnie nie czepia).

--
Jarek

do góry