firewall ports...

I'm trying to open up the firewall ports needed to play SL, but because of my particular software, it is turning into a huge pain...

I went to the knowledge base and go the port numbers...but has anyone been able to find more info about those, like are they TCP/UDP, inbound/outbound, and can they be secondary connections?

Thanks for any help...I really wanna try this game!

The ports are all UDP, and since UDP is connectionless, you need to open them both inbound and outbound.

What is a "secondary connection"?

New range is 66.150.244.0/23 (all IP addresses from 66.150.244.0 to 66.150.245.255)

if by "secondary connection" you mean a bounced/relayed connection, then i'm betting the answer is no, although i can't say with 100% certainty.

Char, are these IP ranges still accurate? Does it include ALL LL/SL servers, or just the sims?

I'm setting up a server for use with email-RPC, and I want to lock it down as much as possible. I would like to restrict it to only accept incoming mail from SL servers (and my backup exchangers, but that's not an LL issue.)

Problem is, I need to ensure that the list I use includes ALL IP addresses that a valid SL-generated email-rpc message might come from. Including any relays that the systems might use to offload mail loads.

'cause I need an answer

I think e-mail is only delivered by data.agni.lindenlab.com (66.150.244.192).

Well, if they only have one mail server, with no backup exchangers or smart relays, that would certainly explain the 4-hour delays in email-rpc messages from time to time.

I believe that their mail server also not only retries to deliver a message no more frequently than once every four hours (useless as a means of "RPC", but I don't believe it even honors any backup exchangers in use by the intended recipient.

I've tested this by turning off my SMTP server, and sending myself an email-RPC message. I then wait about 10-15 minutes and then turn the SMTP server back on. I find when I test this that not only does the message not come through my backup exchangers (which, I'd like to add, I'm paying for for a reason), it finally gets delivered 4 hours later.

That's standard behavior with mail servers. 4 hours is reasonable. You're not supposed to send a lot of e-mails anyway; send one when the object is rezzed and use XML-RPC for everything else. Even if it means that you have to send dummy messages so that your objects can always "reply" if they want to tell you something

Which is why I have two backup mail exchangers that attempt to re-send every 10-15 minutes.

If the LL mail server were RFC compliant and recognized my backup exchangers, this would be a non-issue.

But as it is, with no outbound xml-RPC for channel notification, this throws a 4-hour kink in any program I write just because somebody felt like re-booting a router at just the wrong time.