WU 1.8.0.1 - Network detection issue

[Sklo:D 2,210]

The new network detection is causing a lot issues.

 

I guess not much details needed, everyone with some knowledge knows that 127.0.0.1 can never be unreachable, as it is the machine itself.

[address: /127.0.0.1] Network is unreachable: connect

 

Doing that under Windows 10. Windows could be the issue here as it has not got any local loopback network interface, but linux has. So maybe not a problem under linux.

Edited September 8, 2018 by Sklo:D

[Retrograde 12,013]

I think we've got a report of this as well, I've added this just incase its the same (or worse, something different) 

[Keenan 5,539]

This was developed and tested under Windows 10

 

Could you give more information? Like what you've set your server info to? And have you tried it with Auto Network disabled?

[Keenan 5,539]

The source for the library I wrote that brings the majority of this into WU is here: https://github.com/xorith/nethelper

 

There are some fairly simple validators that are designed to be expanded upon if need be. This is only used when Auto Network is enabled though, otherwise it'll use what is defined in the configuration.

 

For local host, I use the standard Java call of

internalAddress = InetAddress.getLoopbackAddress();

 

It should also be noted that running as a local server bypasses all of this fanciness. I may put the port validation in, but I also wanted to revamp how we launch local play (and even LAN play) to be more user-friendly in a future release.

 

The main complaint I've heard  is one I'll admit I did by design thinking no one would mind, and will be changing before beta goes live. That is I don't favor the port given like I do with the address given. If you put in an address, I'll try to use that first before trying to find the first available Internet-reachable address. With ports, I use defined ranges which I intend to make configurable in the future (but I may do that now as well).

 

The idea being if I give each port needed for Steam play a decent range, it should find one even if the default is in use at the time. We had this issue when nVidia started using one of our original default ports, and I wanted to avoid that in the future.

 

So far though, this is the first instance I've heard of where it can't bind to the local loop back address.

[Sklo:D 2,210]

 

27 minutes ago, Keenan said:

The source for the library I wrote that brings the majority of this into WU is here: https://github.com/xorith/nethelper

 

There are some fairly simple validators that are designed to be expanded upon if need be. This is only used when Auto Network is enabled though, otherwise it'll use what is defined in the configuration.

 

For local host, I use the standard Java call of

internalAddress = InetAddress.getLoopbackAddress();

 

It should also be noted that running as a local server bypasses all of this fanciness. I may put the port validation in, but I also wanted to revamp how we launch local play (and even LAN play) to be more user-friendly in a future release.

 

The main complaint I've heard  is one I'll admit I did by design thinking no one would mind, and will be changing before beta goes live. That is I don't favor the port given like I do with the address given. If you put in an address, I'll try to use that first before trying to find the first available Internet-reachable address. With ports, I use defined ranges which I intend to make configurable in the future (but I may do that now as well).

 

The idea being if I give each port needed for Steam play a decent range, it should find one even if the default is in use at the time. We had this issue when nVidia started using one of our original default ports, and I wanted to avoid that in the future.

 

So far though, this is the first instance I've heard of where it can't bind to the local loop back address.

 

OK did some more testing, really seems to be strange.

 

First something I noticed the AUTO-Portforward checkbox doesn't save or update correctly and is always enabled on server console restart, even if disabled and saved before. It is for sure very cool and useful for all people without server environment, but with a pfsense firewall I don't need that, since I know what I do and I would sleep a lot better if this would be disabled. Also UPNP is blocked on my linux VMs via iptables, so well, maybe not a big risk for me.

 

The next thing is that this seems to be some kind of validation problem. It only happens if I use the ip address 127.0.0.1 as INTERNAL and/or EXTERNAL server ip address, with automatic network detection DISABLED. It works with automatic network detection enabled, because I assume the settings are ignored.

 

 

The gui also tells me that my IP is invalid, but well 127.0.0.1 can never be invalid.

 

[09:01:59 PM] WARNING com.wurmonline.server.gui.WurmServerGuiController: The value for External IP is invalid:
[address: /127.0.0.1] Network is unreachable: connect

Edited September 8, 2018 by Sklo:D

[Sklo:D 2,210]

Found the issue:

 

You are doing a connection test in the internet validator, which makes sense, but you are doing that for external and internal ip addresses, but in many use cases it doesn't make sense to have an internet connection on the internal ip address. In many cases it has no connection to the internet and it also doesn't need connection to the internet. (eg many servers on one OS or just a single island) Not a big problem for me since I only have multiple servers on one OS on my local test machine, our live environment runs 8 or 9 VMs and everything is seperated.

 

coffee.keenan.network.validators.address.InternetValidator

@Override
    public boolean validate(final InetAddress address, final IConfiguration configuration) {
        try (final SocketChannel socket = SocketChannel.open()) {
            socket.socket().setSoTimeout(configuration.getTimeout());
            socket.bind(new InetSocketAddress(address, 0));
            socket.connect(new InetSocketAddress(configuration.getTestUrl(), configuration.getTestPort()));
        }
        catch (Exception e) {
            this.exception = e;
            return false;
        }
        return true;
    }
    

Edited September 8, 2018 by Sklo:D

[Keenan 5,539]

It shouldn't validate on internal, so I'll check that, as well as the PNP option not remembering it's state.

 

Thanks.

[Keenan 5,539]

So with the PNP setting, it should be using the value that's saved into server properties. I designed it to be on by default if it's not there, but it should save and update if modified. the properties key for the table is 'ENABLE_PNP_PORT_FORWARD' which is the same as the wurm.ini setting you can use to force it to be off by default in there. I added the ini option for server admins who may not want to deal with modifying their Sqlite databases.

 

Are you certain the option is being saved (i.e. clicking Save)?

[Sklo:D 2,210]

21 minutes ago, Keenan said:

So with the PNP setting, it should be using the value that's saved into server properties. I designed it to be on by default if it's not there, but it should save and update if modified. the properties key for the table is 'ENABLE_PNP_PORT_FORWARD' which is the same as the wurm.ini setting you can use to force it to be off by default in there. I added the ini option for server admins who may not want to deal with modifying their Sqlite databases.

 

Are you certain the option is being saved (i.e. clicking Save)?

 

The row in the table Serverproperties is added indeed, but always with the value true, no matter which state the checkbox is when clicking on save.

"ENABLE_PNP_PORT_FORWARD"    "true"

 

Setting the value to false in the database does NOT change the checkbox either, still shows as CHECKED on startup.

 

Edited September 8, 2018 by Sklo:D

[Keenan 5,539]

Thanks for checking on that. Planning on a beta update tonight (eastern US) or tomorrow with these fixes and one bdew found with character creation.

 

I figured I changed enough to break some things. I do appreciate the extra eyes.

[Sklo:D 2,210]

18 hours ago, Keenan said:

Thanks for checking on that. Planning on a beta update tonight (eastern US) or tomorrow with these fixes and one bdew found with character creation.

 

I figured I changed enough to break some things. I do appreciate the extra eyes.

 

I can confirm this issue to be fixed in Wurm Unlimited server version 1.8.0.2, but character creation issue is NOT fixed.

Internal server address can now be 127.0.0.1

Edited September 9, 2018 by Sklo:D