Kyp

No, that was related to back end systems, not the game. I can look this afternoon.

That is to say if it wasn't just the last few hours because we've had an issue at the server layer today that might have been preventing you.

I would make sure the game's client install folder, and the launchnet7 folders are set up as exceptions in any such software so it completely ignores them, then try to cap (if you don't see anything)

Are you running any antivirus software? Wireshark is sniffing at the interface layer, typically and if you're not seeing any traffic to 'sunrise.net-7.org' or replies from it, that's what we'd need to see, but if you never see anything going out to that, it would smell of AV / software firewall interception (and/or proxy server if applicable to your situation)

Ok I think we're outta the woods now. There'll be a forums update probably sometime tomorrow necessitating some downtime here so make sure you're a member of the facebook/follow the page if you want to check in on status

Ok game's coming back up. There may be one more bump tonight, we shall see. I have one more major thing to fix.

It will be. Access has been restored to me, and I'm working on fixing up a few things that needed it, as well as some maintenance, so you're all not just inflicted with that in a day or two. *elevator music* (I'd estimate about an hour, but not exact)

It may be a bit, sorry folks. I'm not sure what they did, but they rendered a bunch of stuff inaccessible even to me for the moment.

I am aware, was working with the vendor on something and I think they caused an unintentional issue. I have advised them and am waiting for further response.

For what it's worth this is likely a similar QoL "traffic shaping" to prevent the device (read: connection) from idly chewing resources on the starlink side. That is to say, your traffic is being deprioritized to a point that the server thinks you've gone "link dead" and then drops you off.

It's likely from that description some sorta data cap before they're changing the behavior of the traffic in some way based on those kind of symptoms. We are not requiring you to perform any sort of advanced networking technique. We provide some of those options, like the ability to use proxies and so on but otherwise it's just the .exe communicating with our game server via UDP packets. Most modern games aren't really going to have these types of problems because they are using TCP communication protocols to begin with so it looks as though they're trying to deflect some blame to me. That said, because of what what the emulator is and how it got built the ability to cleanly communicate using UDP is required to play. Let us know if it works on your sister's connection. I would expect it will if it is in fact waiting on data.

I'm not specifically sure what they are referring to. On our side the port you're communicating with is controlled via that net7proxy.exe app, your client continues to connect over the same source port. All you *should* need are UDP 3500-3808 or so. So you should be getting a response if you've allowed it out past any antivirus/firewall and allowing it to receive reply traffic. The server does not care what tries those ports, per se, it simply authenticates proper game clients and lets them in to play. We're not really doing any network magic. While we do NAT some of the internet traffic over to our IPs internally that's all happening behind the firewall and as far as the game client is concerned it's still talking to the same public address. I would go back to them (if you had some kind of case open) and ask them to explain what Natting they are referring to. For reference (depending on your knowledge level) NAT (Network Address Translation) is just what separates internal and public networks by and large because the same 3 networks are typically shared by many companies and end-user internal networks, Class A (10.x), Class B (172.x), or Class C (192.x) internal segments. NAT is the process of a network device like your router flipping it from your internal addresses and sending it out to your public interface using the public IP assigned by your ISP.

Understood, but I think the main difference is gonna be situations where there are larger amounts of latency and/or mobile internet because it's going to drop 'unimportant' packets with battery saver options and things like that. UDP is kind of fire and forget network traffic so either the destination receives or it doesn't. If you didn't change anything between the sessions, it could be some sort of data limit, it could be them believing they're mitigating bad traffic. Sorry I don't really have better news on the subject.

Is T-Mobile in the regular ISP market these days? If you're using mobile internet, that may well be part of it. Many of them drop UDP traffic which as I think was stated earlier here if I'm not confusing with another thread. If that's the case it's going to fail. I did attempt to search our firewall and do not see any blocks for your provided IP address but there is no way to trace the UDP traffic between each system thanks to the protocol being what it is. I would suggest connecting via a different internet connection with the same source PC if possible for a sanity check but it's feeling this way. I see it in your output as well as in a lookup of AS advertisements that the IP segment belonged to T-Mobile. If you're using a hotspot-style wifi to run the game you're probably going to have a fair bit of a struggle. It was designed long ago.

Not exactly sure when I'll get to this but game probably needs a restart anyway and I have some maintenance to apply to things that would otherwise interrupt the game anyway, so gonna take advantage of the routine timing to stay current. Anyway, I'll make my usual announcements in game.

Yeah this would be your internal IP address behind your LAN which won't be useful. You'll have to get the public IP address. https://www.whatismyip.com/ Get the IPv4 which will be what your router is communicating out to the internet with and provide that, we can use that to look. Right after you get this, try it and post the time, IP and I'll check the current log.

Probably need IPv4 addr, whatismyip or similar services can give it to you easily if needed.

This is just the security mechanism dropping pings, not your system. If you want to send me your public IP address I can try to look in logs and see if you're getting dropped for some reason or if I can trace a login, just send me the IP, the time range and the time zone you are in and I will see if I can track something down to at least confirm for sure it is not any server-side mechanism stopping the activity.

and at this point it logs you in to the point where you see the galaxy map, correct? Can you enable the debug launch option, this should create a text file with the interchange that may be helpful, outside of this it would get to the point of capturing packets to see or if you want to send your public IP address I can try to make sure nothing is causing it to be blocked but I suspect not if it gets you through the authentication portion. Loading the in-game relies very little on the server and is just about receiving the confirmation from it that it "knows where you are" so to speak in that sector so the right art can be loaded around you.

A public VPN service like that might work. Ultimately as Zack said it will come down to whether a network will permit traffic using UDP which the game server does.

also, the code is not code signed due to the expense of purchasing certs like that vs. not wanting to ask everyone for more donations each year to keep things running. This can cause Antivirus tools to think 'bad guy' as well.

Disable packet optimization and prototype reordering unless you know you need them, those are for special networking scenarios. That said, the rest of it.. waiting for the server almost looks like something is intercepting traffic back to your computer. So what Karu is saying is where net7 is installed there is a net7proxy.exe, so if you have a virus scanner or firewall make sure the directory you installed our stuff in is exempt, as well as the directory where E&B itself is installed. These are old games and without an exception in such tools, some of the things happening might be considered 'bad guy' type behavior.

It should be resolved now, this wasn't an issue with any local certificate being installed as long as your computer trusts the certs for the Certificate Authority "Let's Encrypt". Most computers will out of the box, unless they've got a customized OS for security or other reasons like that.

I believe there's an FAQ pinned here somewheres, but that could be a couple of different things. The most common being that it's pointed to "e&b.exe" instead of "client.exe" in the launcher, wherever those are installed. "e&b.exe" was the EA official patch. It also could be that same authlogin file that is not correct, it is under your client folder somewhere wherever you installed it but that file is used to get the client to connect to the patch portal it's supposed to be using, the reason it gives the out of date, until you update is that the original version points to EA's systems and the latest version points to our 'patch.net-7.org'.

Thanks, Yes, I am aware as of this am due to a heads up from Woodstock. I am looking at it, this is not the certificate I have associated so not sure what is going on (yet). I'll try to get it sorted out but you *should* be able to bypass this, I think.