Jump to content

lsemprini

Member
  • Posts

    143
  • Joined

  • Last visited

Everything posted by lsemprini

  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.
  16. Yes good point -- whatever TOT is doing is not specific to the ssh port or ssh traffic bytes, but apparently still specific to the general pattern of when and how much data is sent/received. I remember the Awful Firewall of China long ago used heuristics based on packet size/timing to try to thwart VPN. Wonder if TOT is trying to do the same for some reason. I don't think it's related to DHCP lease time (either between me and router or router and ISP) because when the ssh gets killed (which it sometimes does 10 times in 1 minute), no other long-lived TCP connection is affected in any way. And also because the frequency of drops is so random (sometimes hours go by between drops, sometimes seconds) and one would expect a DHCP lease problem to happen at regular intervals.
  17. I have a TOT Fiber connection in Pai that is otherwise very reliable and fast (600Mbps down and up speedtest in Thailand, consistently, HTTPS traffic never has problems) But whenever I try to ssh to my server in the US, it appears that TOT is CONSTANTLY killing my ssh TCP connection at random intervals, regardless of whether the ssh TCP session is idle or busy transferring data. Sometimes ssh windows/connections can survive for 48 hours unmolested, sometimes minutes, and sometimes they are killed seconds after connection. There is ZERO correlation between the killing and whether or not I am (or my household is) currently using a lot of bandwidth. And also ZERO correlation between the killing and whether or not my computer (or household) currently has a lot of TCP connections open. This appears to be specific to TOT: I used to have a second CAT connection (as recently as late 2022) and CAT didn't cut my ssh sessions (sadly CAT is no longer available at my new house). And I am using the same local computer to test, same ssh software, same remote server. And it appears to be specific to ssh protocol: only my ssh, scp, and rsyncs get killed. When I download large files with HTTP/HTTPS I do not see random kills. I have tried VPN just to see if that might jar the problem away, no dice. Perhaps it is some kind of ill-advised effort by TOT to kill a certain kind of traffic that is spilling over to ssh traffic? Anyone else seeing this? Did you find a solution?
  18. I wonder if it's purely market forces (customer dislike of individually-rated fee structure) that has caused AXA/April/Luma/Allianz/LMG to remain community-rated even though technically they could get away with charging individually-rated at any time, or some other factors? Also I'm still very curious to hear people's experiences of which Thai companies "have a less than sterling reputation for paying out on claims and a tendency to decide something is a pre-existing condition after [policy start, for non-medically-valid reasons]." It would be nice if there were some third-party keeping track of claim payment rates for many companies with a good sample size, but since there isn't we must rely on anecdotes.
  19. Another section of my policy wording says "Renewal Premium: Renewal or reinstatements as OIC has been approved." So that more or less confirms that the Registrar is OIC.
  20. Thanks, very useful. Which companies have you heard are worse than others? About premium raises, my policy just says "The Company may adjust the insurance premium upon completion of the Policy Year to reflect the level of risk and the increasing age of the insured. However, the Insurance Premium to be adjusted shall remain at the rate which has been approved by the Registrar." The Registrar is not defined but is presumably the OIC. I read all 46 pages and couldn't find anything directly said rates could be raised based on claims, unless one wants to interpret the word "risk" in the previous sentence that way, or interpret it as that the Registrar (OIC) would approve such a raise.
  21. Interesting. So why do you (presumably) prefer the policies issued by companies outside Thailand? Are there particular terms that are better? Which ones? Something else? I ended up with an AXA policy from AA that is community-rated, so I'm guessing it's not just the community vs. individually rated distinction that pushes you to foreign companies.
  22. What do you mean by 'international policies' ? Do you mean policies from non-Thai companies? Do you mean policies that only work in other countries? AA is still offering policies from Allianz Ayudhaya (Thai company), Luma (Thai company), April Group (French multinational), and LMG (from Liberty Mutual in the USA) which work in Thailand and offer either full or emergency-only coverage in other countries (not US though).
  23. Interesting thought. Do you or someone you know have experience with that, and how did it go?
  24. Good question. I don't have all the details since I only looked at certain companies. I edited the post to note that typically the foreign-owned insurance companies are more likely to offer community-rated plans, though not always so it's important to check the fine print. When I looked recently, AXA, Luma, April, Allianz Ayudhaya had at least some community-rated plans and Pacific Cross had individually-rated plans. But each company might also offer the other type, and things might change at any time, so better just check the fine print.
×
×
  • Create New...