Interesting UDP port issues

My wife and I both use SL on our sufficiently-broad cable modem connection at home. Since update 1.6.10, I've noticed that if one of us is already logged into SL, the other can't connect. The client appears to hang at "Verifying protocol version"

After doing some sniffing on our linux NAT box, I discovered that if the outbound UDP ports that SL uses (12034-12036) are already in use by one of our client machines behind the NAT box, the NAT box remaps the outbound ports of the second box to something else. This is normal and expected behavior from a NAT box, and the second client usually ends up with ports just above 1024 (like 1025-1027).

When sniffing packets, I could see them leaving the second client on relatively low port numbers, but never getting anything back from the user server. When I added a rule to map any SL packets to a high port number (in the 13000 range), everything started working fine.

I understand that both TCP and UDP ports below 1024 tend to be reserved for special system processes, and therefore shouldn't be bound to by a "userland" process like SL. But AFAIK, anything above 1024 is fair game for any program. I've looked in the threads and seen others with this problem, and seen various work arounds. But considering that most consumer NAT devices (such as broadband routers and whatnot) tend to do the exact same behavior as my linux NAT box, and remap already-used ports to something just above 1024... why don't the SL servers accept any packets with a source-port in this range? It'd solve a lot of headaches for households with more than one SL user.

I just had this problem today when I showed my wife SL. I'm using a Linksys Router to share my cable connection. Is it Port Triggering or Port Forwarding that I need to mess with to get both machines working with SL?

Have you seen this page?

hey im glad someone broght this up. Catherine good job on pointing us to this page .. the instructions here worked for me fror a very long time. unfortunatly after the update before last, this solution stopped working for me on my normal second computer and i had to resort to using my very old laptop for my second teminal(which i rarely need unless one of my RL SL friends stop by). perhaps someone my have an idea on an alternate solution. asigned ports mabbee? (im sure you want the specs from the computer, im sorry i can get them right now. ill post them soon)

Just to let people know, I'm running a Netgear router, and have 3 computers that run Second Life concurrently, without needing to remap or forward ports. Since routers are now pretty cheap, you might think about replacing it if the latest firmware update isn't working for you. It may save you a lot of headaches. Afterall, what purpose does a router serve if it can't route properly?

Sargus: If you have only one publicly-routable IP (as most home users on broadband connections will), then your Netgear router is re-mapping ports for you transparently. And if you're able to run 3 clients simultaneously, then you're probably lucky enough that this device has a re-mapping algorithm that puts the re-mapped ports "close to" the original ports.

But there are a whole host of devices already in use on the market that don't use that algorithm (Broda's Linksys, for example). And I don't think "Buy a new router" is a good solution since the problem doesn't seem to me to really be the fault of this pretty standard port re-mapping algorithm. It's tried and true-- been around for ages (in internet time), and will probably continue to be the de-facto standard. New applications (like SecondLife) should readily work with such things. (And, Sargus, how can you be certain a future firmware upgrade won't break functionality for you?)

(And Broda, if Catherine's instructions don't work for you, I really don't know how to fix your problem with your Linksys, unfortunately.)

I guess my point was that not allowing a client to have an outbound port outside the 12,000-13,050 range seems awfully arbitrary to me. I mean, really, what's the point? Wouldn't it be easier from a support perspective not to have to force your potentially paying customers to hopefully have the patience to look for a work-around like the one Catherine linked, and if they can find it, have the technical know-how to actually do it? (And yes-- I know they're easy instructions, but I know a lot of woefully computer-illiterate people who wouldn't have a chance of following them correctly.)