Server Bugs

Go to the map in any viewer (except the CoolVL Viewer which does NOT show tiles for invalid regions). Type something like Pompeii and see how ancient map tiles are still there. For sims long gone. Sims that have been moved. Etc. Ghost map tiles have existed from the day we moved into the cloud. Can we finally get rid of them?

Overview of the problem We are experiencing a persistent communication failure when our automated vendor within Second Life (through a POST request with LLHttpRequest) tries to communicate with our backend server located at https://factorycasas.es/Radio/Crear_Emisora.php . Every transaction attempt from Second Life consistently results in an HTTP Status Code 499 (Customer closed the request/Timeout) on the LSL side, while conventional web browsers, API testing tools (such as Postman) and external HTTP clients can successfully access the endpoint, obtaining a 200 OK status in less than 50 milliseconds. Technical environment and architecture Target endpoint: [ https://factorycasas.es/Radio/Crear_Emisora .php] SSL/TLS configuration: Valid certificate (Certbot/Let's Encrypt) with the complete intermediate chain configured correctly. Backend optimization: The PHP script implements asynchronous execution in the background (fastcgi_finish_request (), ignore_user_abort () and CLI workers) to ensure that the HTTP 200 response is sent to the client instantly, eliminating any internal processing bottleneck. Symptoms and Diagnostic Findings LSL behavior: When executing LLHttpRequest from a scripted object in the world, the request was blocked for approximately 25 seconds and was abruptly interrupted with HTTP 499, returning an empty response body (body: “”). Network Interception Test: When testing the endpoint using external web clients or curl from external networks, the response is immediate (HTTP/ 1.1 200 OK). When monitoring network traffic using tcpdump on the VPS pointing to Linden Lab's known outbound IP ranges (64.129.x.x, 216.82.x.x, 162.243.x.x), incoming TLS handshakes or packets coming from Second Life regions are not recorded or appear to be completely discarded, strongly suggesting that outbound traffic from the SL simulator is being filtered, blocked or limited before reaching the server's public interface, or that the domain Destination /IP has been unintentionally marked or restricted in the simulator's outbound firewall. Alternative access: Other domains hosted outside this VPS or specific network perimeter successfully receive callbacks (LLHttpRequest) from the exact same region without throwing error 499. Request for assistance Since external HTTP access to factorycasas.es operates normally for all global traffic, with the exception of requests from Second Life simulator nodes, we kindly request your collaboration to: Check if the domain factorycasas.es or the associated IP address of the VPS is currently restricted, rate-limited, or blacklisted within Linden Lab's outgoing proxy/firewall infrastructure. Review possible output routing problems or incompatibilities in SSL/TLS ciphers between the simulator's HTTP client library and our server configuration. Thank you in advance for your time and technical support. I am at your disposal for any clarification.

Most ObjectUpdate messages are fine, but after several hours of running, I got a few that were one byte oversize. and one that was 12 bytes oversize.. This is message number 0xc, or High 12 in SL message number form. My experimental Sharpview is picky about this - such messages are discarded. Dropping these may be causing another problem for Sharpview, but it's too soon to tell. The size comes from the message template. Message template is from https://github.com/secondlife/master-message-template/blob/master/message_template.msg This seems to be new. I haven't seen wrongly sized messages on the main grid much in years. This was detected in the test regions running Riders Test Channel 2026-09-16.35125851769.

URGENT SECURITY VULNERABILITY – UNAUTHORIZED EJECTS AND FALSE OBJECT ATTRIBUTION I am reporting what appears to be a serious security vulnerability in Second Life involving unauthorized parcel ejects. Residents are being forcibly ejected from parcels by users who do not appear to have the required land ownership, estate, or administrative permissions. This is not limited to a single incident or a single parcel. Multiple residents and lands appear to be affected. A particularly concerning aspect is that the system appears to attribute the action to an innocent object. When an eject occurs, the victim or nearby residents may see a local chat message such as: “The object 'Void - Demure Lashes (Avalon)' at Dearheart (196,46,2338) cannot teleport the parcel owner home.” The referenced object is a cosmetic attachment with no eject or teleport function. There is nothing in the object intended to eject, teleport, or remove users from the parcel. Nevertheless, the system displays the object as if it were involved in the action. This creates the appearance that a legitimate object caused the eject, while the actual source of the action appears to be something else. In one ongoing case, a resident has reportedly been ejected repeatedly, potentially dozens of times per day, across different locations. Entire groups of visitors on a parcel have also been forcibly ejected without authorization. We have already submitted multiple Abuse Reports and contacted Live Support, but the underlying issue remains unresolved. We urgently request that Linden Lab investigate this as a potential Second Life security vulnerability or exploit, rather than treating each incident as an individual land-management issue. Please review the server-side logs associated with the affected parcels and accounts, including: • The exact timestamps of the eject events • The account or system component actually triggering the eject • The permissions involved • The source of the eject request • Why an unrelated object is being displayed as responsible • Whether the same mechanism is being used across multiple regions and parcels If possible, please reproduce the behavior in a controlled environment and investigate how a resident without the appropriate permissions can cause another resident to be removed from a parcel. This issue is creating serious harassment and security concerns for residents and landowners. We need the technical/security team to identify the underlying cause, fix the vulnerability, and prevent unauthorized users from abusing this functionality. This report concerns a suspected platform-level security vulnerability, not a normal parcel eject performed by an authorized land manager.

Since today, group notices from my group are not delivered to members. What happens: I send a group notice (Groups > [group name] > Notices > Create New Notice > Send). Sometimes the viewer shows "Failed to send group notice", but the notice still appears in the group's Notices list. Other times no error is shown, and the notice also appears in the Notices list. In both cases, members do not receive it: no notice popup, no IM/offline notice, no email. I checked with several members, online and offline. Expected: members receive the notice as usual. Actual: the notice is saved in the group's Notices history but is never delivered. Group: [LECASTLE / secondlife:///app/group/608b39c2-fefb-f083-3da7-e73cf31884e7/about] Sender: thefrankcastle Resident Tried: waiting and resending, shorter text without special characters, no attachment. Same result. Screenshot of the error is attached.

Since around 1.5 weeks (22th/23th July, I would say), I become moved (after logging out on "my" Sim) on the log-in to various SafeHubs. This happens if I log in at the Sim, I was on at logout ... same as if I I try log in "at Home". It happening to me 100% on "Demelo" (RC LeTigre, Mainland, Full Region) ... ... if I log-out/in on "Fishergate" (RC Magnum, Mainland, Full Region) it happens rare, maybe 25% ... ... doing it on "Podyan" ("Second Life Server 2026-07-10.29122504250", Mainland, Homestead) it nearly never happens. "location not available" usual meaning, the Sim is down or overfilled or have other troubles. But the Sim is online and "normal" working ... people (and also my Bot/scripted Agent) are on it. If I try then from the SafeHub a Teleport-Home, it average fails. Doing a TP to one of the Sims around, it mostly gone right ... and I can walk over the Sim-border with no problems. Also doing first a TP to "somewhere" ... and then TPing to Home ... works ("as usual/typical"). The "log in"-problem is happening also to other people ... (where some complaining then also "why them are not allowed ...", as them think, they being banned). Also the Teleports are sometimes need very long time. Some people reporting, them was need multiple times to finally TP successfully ... (and sadly not all have that patience). After the "Rolling Restarts" last week (29th July ?), the Sim seems to was show the "Failed to grant capabilities"-error or so ... ... and someone was request a restart at the support ... and for "1 day" the log-in fail was gone (then it came back). As a little side-note: The mobile Viewer becomes redirected to the "Campwich Forest"-Sim ... this seems to be a "mobile Hotspot" and not a SafeHub ... and it is "Moderate"-rated only, not "adult".-rated, as "Demelo", which can cause problems about the appearance on an other rating.

I first became aware of this when I noticed my aircraft weren't going into "taxi" mode on landing. It was hard to chase down the origin of this behavior, but I eventually discovered that a script containing collision_start()/land_collision_start() event handlers was being TURNED OFF on region crossing... but only on rare occasions. I might cross 20 borders without this happening, or even 50 or more. It seems like it's more likely to happen in certain areas, such as the stretch of sims starting just south of Santa Catalina and continuing east across the Blake Sea to that giant four-sim airport in the Norwegian area. I suppose if they're homestead sims, that could explain why that particular area seems more susceptible to it. That has been by far the most reliable place for reproducing this bug. I grepped all of the scripts in the whole object for llSetScriptState() calls. There are none. (No reason there would be in the first place.) I found that removing an llSleep() call just after a collision_start() event caused the rate of the script halting to be greatly reduced. I theorize that the chain of events is something like this: Vehicle crosses sim border. Occasionally, this causes a spurious collision_start() or land_collision_start() event. (This happens well up in the air, obviously, so it isn't a "real" collision. Probably a race condition between the vehicle and avatar entering the sim in some stochastic order.) Something about the invocation of llSleep() when the vehicle is still actively being handed off fritzes something in the simulator; and it responds by halting the script, OR by failing to return control after llSleep()'s time has elapsed. Whatever the cause, the script's "Running" checkbox is disabled, and it is quite inert.

This was brought to my attention from one of the users of my experience based adult application which uses temp attaching at high altitude over land that has public scripts off.

After teleporting between two RC BlueSteel regions, I noticed that my viewer was still connected to both regions even after an hour later. Using Firestorm's nearby people list, I can still see specific people moving around as if they were in a region adjacent to the one I was in, well past the 60 second mark when my viewer normally disconnects from a region I left. Steps to reproduce (Firestorm viewer) Teleport to BlueSteel Sandbox 1 . Teleport a friend to you and have them remain there in BlueSteel Sandbox 1. Teleport to Sandbox Cordova . Wait at least 60 seconds. Open the Nearby People list (Ctrl + Shift + A) and look for your friend's name. If your friend is still in the Nearby People list, then you are still connected to BlueSteel Sandbox 1. You can even double-click their name to put your camera on them and see them move around. Teleport your friend to you and have them remain there in Sandbox Cordova. Teleport back to BlueSteel Sandbox 1 . Wait at least 60 seconds. Open the Nearby People list (Ctrl + Shift + A) again and look for your friend's name. Your friend's name should no longer be listed, indicating that you have disconnected from Sandbox Cordova.

On 02-July-2025 I received a $13L charge for a mesh upload - however as a lifetime Premium Plus member I believe that as of Feb/Mar 2025 there are no longer charges for mesh upload for Prem+ members. I'm not going to lose sleep over $13L but I wanted to report this in case it is a bug/regression. I have attached a copy of the transaction row from my $L transactions screen showing the charge.