Jump to content

lsemprini

Member
  • Posts

    143
  • Joined

  • Last visited

Recent Profile Visitors

3352 profile views

lsemprini's Achievements

Senior Member

Senior Member (5/14)

  • Dedicated Rare
  • 5 Reactions Given
  • 10 Posts
  • First Post
  • Conversation Starter

Recent Badges

47

Reputation

  1. For future reference, out of the ~20 shops I called/visited, the only one that even has Waves in their fleet is the very nice people at Yayee rental on soi 88 https://maps.app.goo.gl/h8W8F4KkyRy89nCw5 but their bike was out when I was looking (and one of the owners was using the other one!). Seems like a business opportunity for rental places.
  2. I have ridden a Dream in Thailand for the last 20 years and simply prefer the clutchless gear bikes for several reasons (but Dream is effectively discontinued, so Wave is the only model I have a chance to find). One is just that I'm used to them and so easier and safer right out of the shop. Another is more control of engine braking going down hills, though that matters more up in the mountains where I live (there are quite a few places where I live where one simply cannot go with an auto bike, because you will certainly slip out on dirt roads downhill; the Waves/Dreams also have significantly larger wheels and more clearance). Another is that the design of the Wave/Dream allows me to easily carry my big bag because the space between the front edge of the seat and the handlebars/fairing is much larger on those bikes compared with the autos, and I DO plan to carry my big bag some in Hua Hin. Another is it's just a bit annoying how much extra noise one is forced to make with the auto bikes at slower speeds, because the bike chooses the gearing, not the driver. None of those are critical but I'd still prefer the bike type that I am familiar with. The autos let us be lazy and have more storage space, which is nice, but not worth it for me.
  3. Looking to rent a Dream/Wave/Shogun/... type non-automatic clutchless motorbike for a week or two. Seems nearly impossible to find, but maybe someone still has them. I just called every rental place listed on Google for Soi 88 and Soi 94, no dice. Thanks
  4. All good questions. I believe my server and client are both OK because as I mentioned in the OP, I never had problems when connecting to the same server from the same client (same laptop computer, software, setup) over a CAT connection. Only when switching to a TOT connection do I get the endless drops. My old house used to have 2 fiber connections so I was able to switch back and forth instantaneously and the pattern was clear. And now in my new house where I have only a TOT connection, I am seeing the same drops that I saw with TOT in the old house.
  5. It would appear that I am not behind a CGNAT because my fiber ONU's external IP is the same as my whatismyip.com ip Just curious, what weirdness does CGNAT cause that regular on-premisis NAT doesn't also cause? On a related topic, my external TOT IP address changes, but only about once per week (I have been tracking it). So that is DEFINITELY not the source of the hundreds of ssh drops per day that I often see.
  6. Yup thanks, ozimoron suggested that above and I tried both the ssh-level and TCP-level options to disable timeout, but sadly that didn't fix it. In my case, the connection drop happens regardless of whether the connection is idle or actively sending data back and forth.
  7. Yes it was not a company VPN, but rather a VPN server running on a relative's external router at a home address in the US. Normally when I am using that VPN server, I don't experience any new drops of long-running TCP connections (in other words, that VPN doesn't add any new drops that wouldn't also be there without the VPN). But when I used that VPN recently, I was still seeing ssh drop just as often as explained in the OP. So either the drops are from something as yet unidentified on my PC or in my TOT router, or the drops are from something in TOT's network that targets traffic based on packet size/timing (since the VPN traffic no longer looks like ssh traffic, but still has the same general pattern of packets over time). Another thing I noticed recently was that the drops happen a heck of a lot more during the daytime and especially early evening, which tends to point more to TOT's network since that is the busy time, and not so much late at night. But will collect more data there. Apropos tgw's earlier theory, I suppose it is possible that TOT's network redirects all my HTTPS requests to some edge caching server which has good and proper connectivity with the rest of the internet, whereas TOT's network directs other traffic (like ssh) to some faulty network that drops TCP connections left and right. I could try to set up some random server on the internet at a random TCP port to see if TOT drops those connections too.
  8. Another datapoint: I tried turning off my Avast antivirus (because I noticed the horrible thing was intercepting all https traffic via a hack driver and substituting its own certificate so it could spy on my traffic, so who knows what else it was doing to other outgoing TCP connections). Initially that seemed to make a difference, but psyche! the drops were soon back. So no go there either.
  9. Another datapoint: I had a wired TP-Link Archer AC1200 router between my computer and the ISP's ZTE F612 modem/ONU (but everything gigabit ethernet, no WiFi). I temporarily eliminated the AC1200 and connected direct to the ZTE, same problem.
  10. Well I can do that, but as I mentioned, all other network access continues smoothly (even long HTTP downloads continue) while the ssh is killed left and right, often many times per second. So it seems unlikely to be at layer 1 since it uniquely affects the ssh traffic.
  11. Also random datapoint is that the server is running ssh on port 2233 instead of 22 (not within my control).
  12. I did try screen for some operations, but it doesn't work for all the things I need to do (keep a long rsync from my house computer for off-site backups running, for example). And of course screen messes up anything that uses fancy terminal/curses stuff. I don't think it's a server issue, because I never had the problem from my old CAT connection, and the admins of my shared hosting server did look at logs at one point and simply saw the sshd disconnect without any particular error (i.e. it looked like a normal client disconnect to the server). They verified that there is no process killing going on on the server side (which they would only do for out-of-memory, but not even that is happening).
  13. Interesting idea, but in the case of a flaky router we would expect to see all TCP connections affected the same, right? I am able to keep big HTTP downloads (even those running in a command-line wget process with a single HTTPS connection, as opposed to a browser that might have a pool of open TCP connections to a given server) flowing with no problem even when ssh shells are killed left and right during the same download.
  14. I already established that using the CAT ISP does not show this problem. I suspect it would be the same with my AIS 4G connection via hotspot, but sadly I can't use that all the time due to limited speed and data cap. I could test temporarily but not sure if that adds much new data. I already normally connect my computer to the TOT router using gigabit ethernet (I get full 600Mbps up/down to Thai speedtest server), so WiFi is not the source of the problem (no WiFi in use anywhere). Any other ideas?
  15. Great idea, but sadly no dice. I added the ServerAliveInterval 10 ~/.ssh/config and still seeing connections cut. I also added ServerAliveCountMax 9999999 just to make sure lack of ServerAlive responses isn't causing the client to disconnect, and also "TCPKeepAlive no" for same thing at TCP level (see man ssh_config), but same behavior. That was on cygwin ssh command-line. And on my other client (Windows putty) I did the same thing: set 10 second keepalive (there is no ServerAliveCountMax setting sadly) and no TCP keepalives. And shell was still killed just as randomly.
×
×
  • Create New...