I can understand that some element along the path from B to A is silently dropping packets larger than 1458. However, the other point that I am making is that when MTU is set to the default 1500 (as reported by ifconfig) then, the command ssh -p PPPP user@host fails (selecting automatically for mac umac-64-etm@xxxxxxxxxxx), while the command ssh -m umac-64-etm@xxxxxxxxxxx -p PPPP user@host succeeds. In this sense, both commands are executed with MTU=1500 but ssh does behave differently in these two situations without me having to change anything in my network configuration. Thus a reasonable (?) guess is that perhaps ssh does not set all the necessary flags and options correctly when umac-64-etm@xxxxxxxxxxx is set automatically during the negotiation, but does set all the necessary flags and options correctly when the same mac is specified as a command line parameter. Perhaps my guess is incorrect (after all I have no real knowledge on this matter), but I thought it would be best if I report this. My apologies if this is spamming the mailing list. Best regards, Dimitris On Tue, May 31, 2016 at 12:20 PM, Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> wrote: > > On Tue 2016-05-31 10:59:51 -0400, Dimitris Diochnos wrote: > > On another note, lowering the MTU size (which was another workaround for > > [1]) also allows me to pass successfully the key exchange phase in the > > direction where I normally have an issue (that is, country B --> country > > A). The maximum MTU size that would allow me to pass the key exchange > > negotiation was 1458 (that is, with a size of 1459 the key exchange got > > stuck). > > This is the relevant hint for your connection. It sounds like some > element along the network path from B to A is silently dropping packets > that are larger than 1458, and your network stack has not detected this > situation. > > When you force the MAC algorithm to be the specific one, you are > probably making the ssh handshake negotiation packets each be small > enough to fit into the smaller MTU. > > As such, i think this is a networking configuration issue, and not > something for ssh to try to fix. Maybe the fix belongs in your TCP > stack, or in your network configuration? > > Sounds frustrating! > > --dkg _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
