Dlaczego Windows 7 / PuTTY odrzuca połączenia TCP nawet przy bardzo krótkich przerwach w pracy?

15

Mam małą sieć lokalną, która łączy się w niewoli Wi-Fi, i używam jej sshw OS X z -oServerAliveInterval=240PuTTY 0.62 w Windows 7 Professional do nawiązywania połączeń z moim Linode, Hetzner i innymi serwerami.

Za pomocą PuTTY wybieram ConnectionSending of null packets to keep session activedo 240. Enable TCP keepalives (SO_KEEPALIVE option)Domyślnie jest wyłączone.

Kiedy mój internet jest chwilowo wyłączony przez około minutę (trzeba ponownie uwierzytelnić na portalu dostępowym), PuTTY prawie zawsze traci wszystkie otwarte sesje ssh, które mam, a zwłaszcza te, w których była jakakolwiek aktywność, ale OpenSSH na OS X nigdy nie traci żadnych sesji, dopóki mój Internet jest ponownie włączony w ciągu około minuty lub dwóch, nawet jeśli faktycznie próbuję wpisać coś w ssh i nie widzę odpowiedzi przez całe 60 sekund, dopóki moje połączenie nie zostanie ponownie aktywne. (Więc wiem na pewno, że stany NAT są zawsze zachowywane).

Czy mogę powstrzymać system Windows / PuTTY przed zapobiegawczym odrzucaniem dobrych połączeń?

Wydaje mi się, że SO_KEEPALIVE lub niektóre z nich są domyślnie włączone w systemie Windows, a limit czasu na wykrywanie nieaktualnych połączeń jest zdecydowanie za mały. Chciałbym zwiększyć go do wartości przekraczającej kilka sekund, podobnie jak system OS X jest odporny na te krótkie tymczasowe przerwy, o ile przerwa wynosi tylko kilkaset sekund i jest mniejsza niż wartość -oServerAliveInterval(razy ServerAliveCountMax).

cnst
źródło
Piszę tylko, żeby powiedzieć, że mam ten sam problem i głosować ... będę obserwować to pytanie. Zakładam, że ma to coś wspólnego z implementacją sterownika sieciowego w systemie Windows.
allquixotic
Używam szpachli od 10 lat i od początku nie szukałem rozwiązania tego problemu. Ten punkt bólu można złagodzić, a nie rozwiązać. Putty wymaga 100,00% niezawodnego połączenia z Internetem i 0,00% upuszczonych pakietów. W nowym świecie internetowym, który zawsze jest wypryskany, kit staje się coraz mniej przydatny w miarę upływu lat, ponieważ może działać tylko przez kilka minut, zanim przerwiesz pracę, i będziesz musiał ponownie uruchomić kit, ponownie połączyć , a następnie wybierz miejsce, w którym zostało przerwane, zniszcz uszkodzone pliki i spróbuj wykonać swoją pracę przed następną awarią.
Eric Leschinski
@EricLeschinski, jesteś w błędzie. Ograniczenie opisane w tym pytaniu działa dobrze, nie miałem przerwanych połączeń IPv4 od bardzo, bardzo długiego czasu. (Poza przypadkami, w których zmienia się cały adres IPv4, lub śpię itp. - w tych przypadkach moshjest lepszą alternatywą.)
cnst

Odpowiedzi:

8

http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-timeout


Wygląda na to, że TcpMaxDataRetransmissions(REG_DWORD) bezpośrednio na to wpływa. Wartość można dodać za HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameterspomocą regedit.exe(domyślnie brakuje klucza, więc najpierw musisz go dodać, aby go zmienić). Po rozbrojeniu - 5. Dodaj go, ustaw przynajmniej na f(15) i uruchom ponownie.


Domyślna wartość 5 wydaje się dość nieodpowiednia do utrzymywania połączeń podczas krótkich i tymczasowych awarii sieci; upłynie limit czasu w ciągu kilku sekund. Dodałem ten TcpMaxDataRetransmissionsklucz do rejestru i ustawiłem jego wartość na f(15), ponownie uruchomiłem maszynę i po zrobieniu sysctl net.inet.ip.forwarding=0na routerze tuż przed wpisaniem znaku w PuTTY, otrzymałem echo znaku po włączeniu przekazywania dalej na moim routerze po odczekaniu 5 minut (przetestowałem go, aby ustalić, że wartość 0x0000000c (12) powoduje zerwanie połączenia dokładnie 7 minut po pierwszej próbie wysłania pakietu podczas awarii). Przed ponownym uruchomieniem PuTTY natychmiast przekroczył limit połączenia w ciągu kilku sekund. Pamiętaj, że wymagane było ponowne uruchomienie komputera - przynajmniej w systemie Windows 7 Professional,sama zmiana rejestru nie ma wpływu ani na istniejące, ani na nowe połączenia ! W systemie Windows nic się nie zmienia!

Podczas gdy na nią, może również dodawać i zestaw KeepAliveIntervaldo 60000dziesiętnych (60 sek) z domyślnego wyłączonym wartości 1000(1 sek), ale to nie powinno mieć żadnego wpływu w moim przypadku określonego jak wyżej, ponieważ utrzymywanie aktywności TCP nie zostały włączone.

cnst
źródło