niedziałające SSH

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.

Atlantis 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

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.

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

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?

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?

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

Pan Mirek napisał:

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

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

Atlantis napisał:

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

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

Przełączyłem się jeszcze na kartę sieciową na USB i powtórzyłem test. Przeszedł w 100% poprawnie, bez minusów.

Atlantis napisał:

Tego się spodziewałem. Test można robić w obie strony, to znaczy pingować urządzenie z zewnątrz. Wyniki są powtarzalne, choć w większych sieciach zdarzają czasem się losowe niedostarczenia pakietu. Ten arczeologiczny przypadek bardzo ciekawy, z uwagi na tak niskie wartości.

Bo tam masz wyżej PPPoE i on musi zapakować twoją ramkę i wsadzić z opakowaniem w 1500.

No ale chwila - ruter nie może podzielić pakietu? Powinno wszystko działać, co najwyżej mniej wydajnie.

Pan Mirek napisał:

Może nie może, ja tam nie wiem, nie ja go robiłem.

Być może nawet wszystkie strony WWW działają, ale kto by wszystkie sprawdził. Usługi korzystające z transmisji UDP przeważnie nie działają.

No dobrze. Zrozumiałbym, gdyby chodziło o połączenie z serwerem w Internecie, gdzie pakiety muszę przejść przez różne routery. Ale tutaj mowa o serwerze (płytka SBC), który jest podpięty do tego samego switcha, w tej samej sieci co klient. Obydwa urządzenia łączą się przez Ethernet. Czyżby AT91RM9200 miał mieć jakąś dziwnie niestandardową implementację Ethernetu?

Stawiam, że to może być to. Objawy pasują idealnie.

Faktycznie, o tym nie pomyślałem. Przez weekend, w wolnej chwili sprawdzę co pokazuje oscyloskop.

Atlantis napisał:

Objawy należy poznać dokładnie. Test z pingami powinien być wykonany wielokrotnie. Jeśli za każdym razem minusy pojawiają się w miejscu trzochę innych plusów, to podejrzenia kol. Marudnego mogą być słuszne. Jeśli wyniki są powtarzalne, to jest inny przypadek.

Jarek

Jeszcze mi się przypomniało z naprawy starego switcha: sprawdź, czy najzwyczajniej masz dobre luty. Ethernet potrafi się sprzęgać pojemnościowo przez uszkodzone ściezki/luty i objawy są takie, że działa, ale trochę.

Przecież tego typu problem rujnowałby w ogóle połączenia nie tylko ssh. a autor postu sugeruje (tak zrozumiałe, że problem jest wyłącznie z ssh a inne połączenia do innych hostów na inne usługi działają bez problemu. Tego typu problem od razu byłby widoczny w statystykach błędów na interfejsie.