Connection refused


#1

I have several web servers, some of them are free, some are paid, the paid ones are at Hostmonster.

The free ones work ok for model hosting but they are slow and limited, but when I try to use Hostmonster I get Connection Refused
I have spoken to the people at Hostmonster and they said the IP may be blocked for me.

Can someone please tell me the IP address of the server that calls for the model files on my site so I can quote this IP to them and they will tell me if it is being blocked or not.


#2

If i understand High Fidelity right, then every user thats logging in with interface.exe on your domain and is in range of objects that are stored on the server the try to load. In other words, whole internet need access to the model files. And why are the blocking ip’s ?.

But maby am wrong @Adrian


#3

@Richardus You are probably be right about every user getting it from my web server, I think thats the distributed load idea, so I need to understand what happens at the time of up loading the model for the first time.
I thought it is uploaded thru hifi’s system so in the first instance its the hifi server that registers the model and sets it on my domain ready to be served, but if its always served from the my web server then hifi would just need to store the address and details.

I dont know exactly why they block some IPs but I imagine there are some black lists for various reasons, its possible that they foresee users doing exactly what I want to do and potentially serve the content robotically to too many people, they might consider it a sharing platform and they have rules against file sharing systems being hosted on their gear.

In which case I simply need to find a better hosting system.


#4

@Adrian - that’s correct, any model you place in any location is served from the URL you specify when you place the model. Interface caches models, but, it clears (at last check) cache on each shutdown. If you’re hosting models from a service having transfer limits you could run into issues (or limits on peak connections per second/minute/hour etc). For models the assignment-client only sends a reference to parameters of model (location, rotation etc) and a link to get the model data. If 100 AVs show up in your domain for the first time during their session, then 100 requests for each model the AV needs to render will be sent to your model server source. It can be a substantial data stream even for 1 AV.

Voxels and Metavoxels source from machine where your assignment-client for the domain runs. Metavoxels, especially, can be problematic as the data stream is huge, is not cached and can saturate a low outbound bandwidth connection. Something to keep in mind for those using metavoxels. I watched an AV having connection issues repeatedly hammer my public metavoxel server as it reconnected every 10 to 20 seconds and had to download the metavoxel data each time. Hopefully caching and size reduction of metavoxel data is on the radar somewhere - if not, I’m considering going back to mesh terrain until that’s solved.


#5

Upload a model, need to admit i never used that, always did upload it to my own webspace. I would say if you upload it so it get in the entitiy list to select as object it must be stored at High Fidelity storage.

Get a bit confused… :wink:
Because your domain server only tell the client you can find the model@…som adress…
So connection refused dont make sense for me. its not your interface.exe or firefwall thats doing weird ? is nobody seeing the objects ?


#6

Not sure if related, but a while ago I was unsucessfully trying to run a script from my server (Hostgator). Huffman did some quick traffic analysis (I think using WireShark) and noticed that Interface didn’t seem to be sending an ‘ACK’ packet at the correct time, a situation that some web servers seemed to baulk at whilst others ignored and continued with the connection. I switched to using S3 for hosting scripts and didn’t look into it any further.

I don’t know if this is still the case, but thought I’d mention it here just in case it helps.

  • davedub

#7

This is still an issue for me, I still need the answer to the original question please

Thank you.


#8

The models files come from the IP of the server they are stored on. e.g. I have the assets that you can get to stored on Amazon. Yet that could be stored on your own server. So the IP is where ever you host them


#9

Just to make it clear. You’re hosting your content somewhere - it doesn’t matter but yours is at hostmonster, so that’s where.

Making this up for example

You, myself and another TP to your domain.

I have IP 1.2.3.4, you have 1.2.3.5 and other has 1.2.3.6

For all entities you’ve placed that have a url pointed to hostmonster it will receive a request from each of those IP addresses. When Interface iterates the entity list it feeds back a reference to where an entity can be pulled.

In case of built in entities (more akin to prims in SL as an analogy) - those are simply described so in that case the content sort of comes from entity server.

At least that’s my understanding of it and it’s what I see in my web server logs.


#10

Thanks @chris and @OmegaHeron , I get that the models are served from my web server to the client, but hifi servers must be communicating with my webserver to make that happens first.

My error occurs when I first try to bring the model onto my domain, there must be some activity from hifi systems to add and or register the model onto my domain. it never gets added, something goes wrong at this point.

here is the log entry from my host error log:

ModSecurity: Access denied with code 406 (phase 2). Match of “beginsWith /?automatorsecretkey” against “Request_URI” required. [file “/etc/httpd/modsecurity.d/eig_rules.conf”] [line “420”] [id “900095”] [msg “Bad UA :: Fake Mozilla Agent”]

I contacted my host and the support guy never heard of fake mozilla agent before.
I still hold hope for a solution.


#11

The log fragment from your web server says it all and that someone from its support structure couldn’t give you a simple answer is bothersome.

Translated to human that says. Web server is running a module called, ModSecurity. ModSecurity is configured to look at what the browser connecting to it claims to be (software type/version) and, if unknown tell it to go away. It’s that simple.

Whatever, presumably Interface, is sending as its user agent string is not acceptable to your host’s web server.

msg :: Bad UA :: Fake Mozilla Agent To plain language = Bad User Agent called Fake Mozilla Agent. Likely a default value set for user agent string. While this means it’s a problem to workout with whatever is sending a “Bad UA” it’s pretty unforgivable that their support couldn’t tell you what that means.


#12

Here is an explanation of why ModSecurity is denying the connection;

https://bugs.launchpad.net/mudlet/+bug/1366781

Interface Identifies its user agent string as “Mozilla/5.0” that is, with the default set of ModSecurity rules seen as a bad (fake) user agent and denies request. Now you know the why. The more difficult question become how to fix. One of the following would have to happen. Patch Interface to have a UA string your host accepts, disable ModSecurity or find another host.

If Interface had QT set its UA string to something like "Mozilla/5.0 (HighFidelity/<major version number>.<minor version number>)" or something similar, it would likely solve the problem and, eventually, it will be a much greater problem with added users who will run into this issue as well. @b @philip @chris


#13

Added a worklist report on this - you might want to follow it @Adrian

https://worklist.net/20277