Hojo Warf Posted March 23, 2023 Share Posted March 23, 2023 I installed a new router on Tuesday… Since then, I am being randomly logged out. Anywhere between 30 minutes to 2 hours. I have went to 5 different regions, 3 quiet, 2 small crowd. Happens in all those places. First I freeze and a few minutes later I get logged out with a msg saying the region is experiencing…. I don’t loose internet and everything else is working fine, I just get logged out from SL. I have never had this issue until the day I put in my new router. Everything was fine before. However, Tuesday and Wednesday were maintenance days but it is also happening today. This happens regardless of whether I am on the SL viewer or Firestorm. I checked my router and it is not blocking anything at all. My computer firewall is the same as it was before the new router when everything was working fine. I’m connected through Ethernet, not on wifi So far I rebooted and changed the DNS to the google free DNS server and it’s still happening. If it’s not SL and my new router, what else should I do? Thank you for your help Link to comment Share on other sites More sharing options...
MarissaOrloff Posted March 28, 2023 Share Posted March 28, 2023 What brand of router is it and what is the chipset of your ethernet card? Link to comment Share on other sites More sharing options...
Hojo Warf Posted March 29, 2023 Author Share Posted March 29, 2023 Netgear R6350 AC1750 Would the chipset of my card matter? There are two different computers with different cards that this is occurring on. Thanks in advance Link to comment Share on other sites More sharing options...
Henri Beauchamp Posted March 30, 2023 Share Posted March 30, 2023 14 hours ago, Hojo Warf said: Netgear R6350 AC1750 It's a WiFi router. WiFi is extremely sensitive to waves reflections and absorptions; there are even some recent ”WiFi radar” applications to detect people and their movements in a room ! This is even more prominent an issue with newest WiFi standards employing the 5GHz band (same radio waves band as what some military radars are using !). With such routers, the radio link quality can be affected by moving your computer by a dozen of centimeters, rotating the router antennas, closing or opening a door, moving a chair in the room, or having someone moving in the room. My advice is therefore to try and find a better place for your router (one in direct view of your computer, if possible)... And if you want a 100% reliable connection, do not use WiFi: use a good old Ethernet cable ! Link to comment Share on other sites More sharing options...
Profaitchikenz Haiku Posted March 30, 2023 Share Posted March 30, 2023 If it's not possible to get a cable for the router connection and it's also not possible to move the PC or router closer together, there is a third option which I have managed to make work for a few months while I was in lodgings working away from home. Get a plug-in WiFi extender, these just go into a wall socket and have one or two little antennas on them. Get it recognised by the router and position it as close to the PC as possible (usually the WiFi antenna on a Tower or desktop PC will be around the back), and it should give you a more robust wireless link. Link to comment Share on other sites More sharing options...
Hojo Warf Posted March 30, 2023 Author Share Posted March 30, 2023 Thanks for the responses but as I said in the initial post none of the computers involved are on WIFI. This is all with wired connections. 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 30, 2023 Share Posted March 30, 2023 Aren't there logs in the Second Life viewers that help explain "random disconnections"? 1 Link to comment Share on other sites More sharing options...
Hojo Warf Posted March 30, 2023 Author Share Posted March 30, 2023 2 hours ago, Love Zhaoying said: Aren't there logs in the Second Life viewers that help explain "random disconnections"? Ah yes there are. I'll see if they are of any help. Hopefully I can read it. Link to comment Share on other sites More sharing options...
Ardy Lay Posted March 30, 2023 Share Posted March 30, 2023 Sounds like UDP "connections" going stale. Opening ports/sockets on your firewall should never be necessary unless you use some weird thing that does not automatically allow replies to outbound traffic, or you have added more than the default restrictions on inbound traffic. I'd would think it's more likely there is some thing in the path that is either discarding your UDP traffic to make room for "more important" TCP traffic on a congested link or there is some "address conservation" taking place and too may flows are being allocated to too few outside-global IPv4 addresses causing port depletion, which triggers premature recycling of ports. (NAT, PAT, CGN, CGNAT... the beast goes by many names.) One thing you can try to see if it's any of the above giving your UDP packets the second-class treatment, is a VPN. Try to use a VPN server that is closer to the hosts running SL than you are. Make sure you use a VPN protocol that is not just more UDP packets wrapping your UDP packets. What you are looking for here is an "upgrade to first-class" as a TCP user. 1 Link to comment Share on other sites More sharing options...
Henri Beauchamp Posted March 30, 2023 Share Posted March 30, 2023 (edited) 3 hours ago, Hojo Warf said: This is all with wired connections. Did you check the cable then ? It may happen that an Ethernet connector got bad contacts... In this case, you will probably be able to see it by looking at the LEDs on the Ethernet connectors of your computer or router: if they go off, then there is a bad contact (try and titillate the plugs: if the LEDs flicker, it's the sign of a bad contact). This would also show in the system log of your OS (but since you do not say which OS you are using, I cannot point you at the right log): the Ethernet driver will report the link going down and back up after some time. In any case, the symptoms you describe correspond to a connection loss: it could be a bad routing or a congestion somewhere on the route to SL servers (seen during DDoS attacks), your ISP's link going down (two minutes without a link are enough to cause the viewer to time out), a bad cable, or a hardware fault... To confirm it is not specific to the viewer, try and load a web page in a browser as soon as you notice the ”freeze” in SL: if the site does not load, it's a sign the problem is indeed at the Internet link level. Edited March 30, 2023 by Henri Beauchamp Link to comment Share on other sites More sharing options...
Hojo Warf Posted March 30, 2023 Author Share Posted March 30, 2023 All valid points, Henri and Ardy, thanks! These are things I can look into. The thing is it happens independently to me and my fiancee. We are both on the same router on different computers in different rooms. We both get disconnections that we didn't get before the new router but never at the same time. If there was a packet interruption beyond the router wouldn't we both get disconnected at the same time? Link to comment Share on other sites More sharing options...
Henri Beauchamp Posted March 30, 2023 Share Posted March 30, 2023 3 minutes ago, Hojo Warf said: The thing is it happens independently to me and my fiancee. We are both on the same router on different computers in different rooms. We both get disconnections that we didn't get before the new router but never at the same time. If there was a packet interruption beyond the router wouldn't we both get disconnected at the same time? Thing is, a short disconnection/reconnection may happen and go unnoticed, e.g. if you do not try and move your avatar while disconnected (you won't perceive the ”freeze” then, since the viewer would continue rendering like if nothing happened), and the glitch duration is less than 2 minutes or so (exact timing depends on last packets received by the viewer from the server(s), and on viewer hard-coded timeout). But yes, in principle, it should happen to you both at the same time, should the routing or ISP link be involved. I'd have a closer look at the physical connection (plugs) reliability at the router level, then: maybe your Ethernet cables contacts are a bit worn out, and the new router sockets are less tolerant to this than your old router... This would explain you both experience disconnections at different times. Also, did you try and put your old router in place of the new one, to verify the latter is indeed involved or not ? Link to comment Share on other sites More sharing options...
Hojo Warf Posted March 30, 2023 Author Share Posted March 30, 2023 Here is a partial log of the disconnect if anyone can read it. 2023-03-30T23:07:45Z INFO # newview/lltoolpie.cpp(186) LLToolPie::handleMouseDown : pick_rigged is 0 pick time elapsed 0.0003786s 2023-03-30T23:07:55Z INFO # newview/llviewerdisplay.cpp(243) display_stats : FPS: 77.90 2023-03-30T23:07:55Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(434) LLCore::HttpPolicy::stageAfterCompletion : HTTP request 0000026D6DCF5570 failed after 5 retries. Reason: Timeout was reached (Easy_28) 2023-03-30T23:07:55Z WARNING #CoreHTTP# llmessage/llcorehttputil.cpp(282) LLCoreHttpUtil::HttpCoroHandler::onCompleted : Possible failure [Easy_28] cannot POST url 'https://simhost-0241427d9ea53b667.agni.secondlife.io:12043/cap/de395b3f-e651-fe90-acb3-e84cad44afb3' because Timeout was reached 2023-03-30T23:08:05Z INFO # newview/llviewerdisplay.cpp(243) display_stats : FPS: 78.10 2023-03-30T23:08:08Z INFO # llmessage/llcircuit.cpp(1223) LLCircuitData::dumpResendCountAndReset : Circuit: 35.167.249.75:13043 resent 66 packets 2023-03-30T23:08:11Z INFO # llfilesystem/lldiskcache.cpp(150) LLDiskCache::purge : Purging cache to a maximum of 2147483648 bytes 2023-03-30T23:08:13Z INFO # newview/llviewerdisplay.cpp(257) display_stats : MEMORY: 1598MB 2023-03-30T23:08:13Z INFO # llcommon/llmemory.cpp(155) LLMemory::logMemoryInfo : Current allocated physical memory(KB): 1637124KB 2023-03-30T23:08:13Z INFO # llcommon/llmemory.cpp(156) LLMemory::logMemoryInfo : Current allocated page size (KB): 2878020KB 2023-03-30T23:08:13Z INFO # llcommon/llmemory.cpp(157) LLMemory::logMemoryInfo : Current available physical memory(KB): 15140092KB 2023-03-30T23:08:13Z INFO # llcommon/llmemory.cpp(158) LLMemory::logMemoryInfo : Current max usable memory(KB): 16777216KB 2023-03-30T23:08:13Z INFO # newview/llworld.cpp(529) LLWorld::addRegion : Add region with handle: 836728348975872 on host 54.184.239.121:13017 2023-03-30T23:08:13Z INFO # newview/llworld.cpp(539) LLWorld::addRegion : Region already exists and is alive, using existing region 2023-03-30T23:08:13Z INFO # newview/llworld.cpp(1679) process_enable_simulator : simulator_enable() Enabling 54.184.239.121:13017 with code 173962189 2023-03-30T23:08:15Z INFO # newview/llviewerdisplay.cpp(243) display_stats : FPS: 77.90 2023-03-30T23:08:18Z INFO # llcommon/llmemory.cpp(155) LLMemory::logMemoryInfo : Current allocated physical memory(KB): 1637124KB 2023-03-30T23:08:18Z INFO # llcommon/llmemory.cpp(156) LLMemory::logMemoryInfo : Current allocated page size (KB): 2878020KB 2023-03-30T23:08:18Z INFO # llcommon/llmemory.cpp(157) LLMemory::logMemoryInfo : Current available physical memory(KB): 15140092KB 2023-03-30T23:08:18Z INFO # llcommon/llmemory.cpp(158) LLMemory::logMemoryInfo : Current max usable memory(KB): 16777216KB 2023-03-30T23:08:18Z INFO #AssetStorage# newview/llviewerassetstorage.cpp(679) LLViewerAssetStorage::logAssetStorageInfo : Active coros 0 2023-03-30T23:08:18Z INFO #AssetStorage# newview/llviewerassetstorage.cpp(680) LLViewerAssetStorage::logAssetStorageInfo : mPendingDownloads size 0 2023-03-30T23:08:18Z INFO #AssetStorage# newview/llviewerassetstorage.cpp(681) LLViewerAssetStorage::logAssetStorageInfo : mCountStarted 139 2023-03-30T23:08:18Z INFO #AssetStorage# newview/llviewerassetstorage.cpp(682) LLViewerAssetStorage::logAssetStorageInfo : mCountCompleted 139 2023-03-30T23:08:18Z INFO #AssetStorage# newview/llviewerassetstorage.cpp(683) LLViewerAssetStorage::logAssetStorageInfo : mCountSucceeded 139 2023-03-30T23:08:18Z INFO #AssetStorage# newview/llviewerassetstorage.cpp(684) LLViewerAssetStorage::logAssetStorageInfo : mTotalBytesFetched 2815240 2023-03-30T23:08:25Z INFO # newview/lltoolpie.cpp(186) LLToolPie::handleMouseDown : pick_rigged is 0 pick time elapsed 0.0004741s 2023-03-30T23:08:25Z INFO # newview/llviewerdisplay.cpp(243) display_stats : FPS: 78.20 2023-03-30T23:08:27Z INFO # newview/lltoolpie.cpp(186) LLToolPie::handleMouseDown : pick_rigged is 0 pick time elapsed 0.0004906s 2023-03-30T23:08:29Z INFO # newview/lltoolpie.cpp(186) LLToolPie::handleMouseDown : pick_rigged is 0 pick time elapsed 0.0004932s 2023-03-30T23:08:32Z INFO # llui/llfloater.cpp(773) LLFloater::closeFloater : Closing floater toolbox floater 2023-03-30T23:08:34Z WARNING # llmessage/llcircuit.cpp(1074) LLCircuitData::checkCircuitTimeout : LLCircuitData::checkCircuitTimeout for 35.167.249.75:13043 last ping 104.947s seconds ago. 2023-03-30T23:08:34Z WARNING # llmessage/llcircuit.cpp(1084) LLCircuitData::checkCircuitTimeout : LLCircuitData::checkCircuitTimeout for 35.167.249.75:13043 still dead, dropping. 2023-03-30T23:08:34Z INFO # llmessage/llcircuit.cpp(467) LLCircuit::removeCircuitData : LLCircuit::removeCircuitData for 35.167.249.75:13043 2023-03-30T23:08:34Z WARNING #Messaging# llmessage/message.cpp(1134) LLMessageSystem::sendMessage : ONCE: sendMessage - Trying to send AgentUpdate on unknown circuit 35.167.249.75:13043 2023-03-30T23:08:34Z WARNING # newview/lltoastalertpanel.cpp(201) LLToastAlertPanel::LLToastAlertPanel : Alert: You have been logged out of Second Life. This region may be experiencing trouble. Please check your connection to the Internet. Link to comment Share on other sites More sharing options...
Ardy Lay Posted March 31, 2023 Share Posted March 31, 2023 On 3/23/2023 at 3:20 PM, Hojo Warf said: I installed a new router on Tuesday… Since then, I am being randomly logged out. Yeah.... that seems very suspect. Link to comment Share on other sites More sharing options...
animats Posted March 31, 2023 Share Posted March 31, 2023 Huh. The viewer is not reaching the sim at [54.184.239.121] via HTTP on port 12043. That's TCP, not UDP, and it's outgoing from the viewer, so that should just work. Here's the manual for that router: Netgear R6350 AC1750. You might try setting "NAT filtering" to "Open" instead of "Secure" as a test. (This does mean that some external attacks can try to reach your local computers.) Also, that router has an optional porno and bad words filter. See page 57 of the manual to make sure that's turned off. 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 31, 2023 Share Posted March 31, 2023 7 hours ago, Hojo Warf said: Here is a partial log of the disconnect if anyone can read it. Yes, we have experts who can help! Thank you for supplying the log. Link to comment Share on other sites More sharing options...
Henri Beauchamp Posted March 31, 2023 Share Posted March 31, 2023 (edited) 3 hours ago, animats said: Also, that router has an optional porno and bad words filter. See page 57 of the manual to make sure that's turned off. LOL ! Yes, please, turn that sh*t off ! Everything that does deep packet inspection is likely to badly interfere with ”unusual” or uncommon network traffic, and I doubt very much Netgear made their router aware of SL network packets structure... Another potential issue would be a poor NAT implementation in your router, that would not be capable of maintaining high enough a number of simultaneously opened ports for the same IP: SL viewers open a lot of ports to the same IP, and if one socket gets closed because the router table got full and dropped it, you get a disconnection... This happened already in the past with cheap WiFi routers, and one could wonder why a modern router would not properly implement NAT with full 65535 simultaneous ports per connection tracking, but with IPv6 becoming more common, we might see NAT support (which is used by IPv4 only) become ”lighter” (read: incomplete) in modern routers firmware... You could diagnose such an issue by reducing the number of simultaneous connections settings in the viewer (simultaneous mesh and texture fetches in network settings) and the draw distance (to reduce the number of connected neighbor regions). Edited March 31, 2023 by Henri Beauchamp 1 Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted April 3, 2023 Lindens Share Posted April 3, 2023 On 3/31/2023 at 6:16 AM, animats said: Huh. The viewer is not reaching the sim at [54.184.239.121] via HTTP on port 12043. That's TCP, not UDP, and it's outgoing from the viewer, so that should just work. No, his log is correct, 13043. That's a valid UDP port for a simulator on a simhost. It just *looks* suspiciously like a viewer capabilities port. Link to comment Share on other sites More sharing options...
animats Posted April 3, 2023 Share Posted April 3, 2023 On 3/30/2023 at 4:36 PM, Hojo Warf said: 2023-03-30T23:07:55Z WARNING #CoreHTTP# llmessage/llcorehttputil.cpp(282) LLCoreHttpUtil::HttpCoroHandler::onCompleted : Possible failure [Easy_28] cannot POST url 'https://simhost-0241427d9ea53b667.agni.secondlife.io:12043/cap/de395b3f-e651-fe90-acb3-e84cad44afb3' because Timeout was reached That's a failed HTTP request. It's to [54.184.239.121] , which is the IP address of simhost-0241427d9ea53b667.agni.secondlife.io. On 3/30/2023 at 4:36 PM, Hojo Warf said: 2023-03-30T23:08:34Z WARNING # llmessage/llcircuit.cpp(1074) LLCircuitData::checkCircuitTimeout : LLCircuitData::checkCircuitTimeout for 35.167.249.75:13043 last ping 104.947s seconds ago. That's a failed UDP message. So it's failing for both HTTP over TCP and for SL messages over UDP. 1 Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted April 3, 2023 Lindens Share Posted April 3, 2023 1 hour ago, animats said: That's a failed HTTP request. It's to [54.184.239.121] , which is the IP address of simhost-0241427d9ea53b667.agni.secondlife.io. That's a failed UDP message. So it's failing for both HTTP over TCP and for SL messages over UDP. Yep, but one is expected (the first, it's the long poll event queue) and one is not (sad udp). All indications are that UDP is being blocked hard. I'm looking at the router setup in this case or a very, very bad NAT implementation that moved away from the original port. AV/firewall on the host could be at fault as well but it's the router that has changed so look there. Addendum: looking at the manual for the router, 'NAT Filtering' looks a bit suspicious. Link to comment Share on other sites More sharing options...
Hojo Warf Posted April 3, 2023 Author Share Posted April 3, 2023 Thank you for the responses. I appreciate it! I noticed though that the link given for the router manual actually links to the manual for R6700. The correct link to the manual is R6350 manual Here is the WAN security page for the router. What do you suggest that I change here? Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted April 3, 2023 Lindens Share Posted April 3, 2023 Set 'NAT Filtering' to 'Open'. 1 Link to comment Share on other sites More sharing options...
Hojo Warf Posted April 3, 2023 Author Share Posted April 3, 2023 4 minutes ago, Monty Linden said: Set 'NAT Filtering' to 'Open'. Awesome. Thanks so much! I was ready to return this router to the store. I am switching that now. What about SIP ALG? I looked it up and many sources say to turn it off for VOIP. Should I disable that as well? Link to comment Share on other sites More sharing options...
Lindens Monty Linden Posted April 3, 2023 Lindens Share Posted April 3, 2023 You can try it 'off' and see if it helps. It's another 'helpful' feature that thinks it knows how to rewrite packets. It shouldn't be trying on SL streams but you never know. There are likely other clever features that might get in the way. So you may need to wade through a few dozen screens to get rid of the blocking feature(s). Link to comment Share on other sites More sharing options...
Ardy Lay Posted April 3, 2023 Share Posted April 3, 2023 I have turned off SIP ALG on thousands of "broadband routers" and "firewalls". That feature is a relic of the past from when "SIP servers" were clueless to the existence of NAT and Session Border Controllers did not yet exist. SIP ALG helped one SIP User Agent communicate with one SIP User Agent or Server through NAT or PAT. I have never seen it help two, and, today, ALG function is counter-productive in that the B2BUA and SIP Server software all seems to take care of NAT/PAT weirdness itself. Adding ALG, or, as Cisco called it, "SIP Fixup", to the mix makes all UAs inside the ALG look like a single UA to the Server. CHAOS follows. Link to comment Share on other sites More sharing options...
Facebook
Instagram
Twitter
YouTube
Flickr
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now