-- [ Picked text/plain from multipart/alternative ] >> A few years ago I was going through low-end-cheap-crap-router-hell, and >> tried to run behind a Belkin router. I never got the Steam master servers >> list to pick me up. Never, even if I put my box in the dmz. dLink was >> similarly evil. Switched to Netgear and it worked for a while, but my open >> nap server was maxing out the routing table because I had a 1000 user >> opennap server, and this would stop incoming connections until there was a >> free spot in the table. I switched to Linksys, which has a bigger routing >> table, and all of my problems went away. I'm still of the opinion that some >> routers block something or otherwise block/corrupt packets that other >> routers don't, and is a big part of the problem of servers not appearing on >> the master list.
---------------------------------------------------------------------- Thats the problem as we speak right now. Right now, no matter where you go for support for this issue, you hear all these "fixes" which I have personally proven all wrong. One common theme is the types of routers/firewalls that are causing the SMSL (Steam Master Server List) to not display the server are more business-like/advanced user routers/firewalls. The ones that allow it are more homeish/geek squad recommended routers/firewalls. Also, it almost all cases, the DMZ always work. Anything using a NAT translation causes the server to connect to the master server but not display the information in the browser. This all makes sense since obviously, the more advanced user oriented firewalls/routers are meant to help keep the server/network behind it safer, when the more basic routers just help keep the simple "spyware from my myspace account" away to the best of its ability. The NAT translations changing the packets or whatnot is a relatively new idea toward this issue, which I have not seen on the net suggested. If A. we can find out whats "different" about the SMSL's packets, B. Why NAT translation is changing or ignoring parts of the packet and C. what can be fixed, then this issue may be dead. Like stated by Mike Munoz, a packet sniff on the incoming and outgoing side of the router/firewall and examining the packets is the first step. This would have to be tested against a firewall/router that works and one that doesn't to find out what problems are occuring. Then and only then will this issue be killed. Anyone up for the challenge? -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
