You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I count 10 issues and pull requests relating to handling port and/or IP address rewriting and unblocking.
These are almost invariably about IPv4 NAT modifying or blocking IP/port tuples at one end or the other. I could be a wag and shout "IPv6, already!", but I've already been doing that for 5 years, and we still haven't gotten past IPv4.
The problem that I see is that most of these issues/PRs address some narrow part of the problem specific to the reporter's network, and thus aren't broadly useful enough for inclusion into Mosh. I'd like to suggest that we come up with some more-general scheme for managing this issue.
My thoughts on this are ill-formed so far, but I have two ideas that I want to float:
I think maybe we can abstract the needed capabilities into three four parts:
I went over our issues and PRs to find things related to this issue.
Issues that are covered by this general concept: #48, #469, #494, #537, #602
And PRs: #287, #417, #497, #530, #572
The problems of port multiplexing and roaming between multiple server addresses touch on this as well.
An observation: when I wrote the change for #572, I certainly felt that there were other similar PRs solving it differently, and it seemed to reduce to the lack of a server-side config file. The client-side config piggybacks on .ssh/config, but not completely. And my change was a small step to having server-side config within the ssh constraints as well.
I count 10 issues and pull requests relating to handling port and/or IP address rewriting and unblocking.
These are almost invariably about IPv4 NAT modifying or blocking IP/port tuples at one end or the other. I could be a wag and shout "IPv6, already!", but I've already been doing that for 5 years, and we still haven't gotten past IPv4.
The problem that I see is that most of these issues/PRs address some narrow part of the problem specific to the reporter's network, and thus aren't broadly useful enough for inclusion into Mosh. I'd like to suggest that we come up with some more-general scheme for managing this issue.
My thoughts on this are ill-formed so far, but I have two ideas that I want to float:
threefour parts:All of this applies to both mosh-client and mosh-server.
The text was updated successfully, but these errors were encountered: