In the legacy IIDX (exe format), there is a problem with the functionality to specify a connection server.
The issue affects communications other than those to services.eamuse.konami.fun or services. , resulting in the alteration of all results from the gethostbyname function.
Due to this design, there are situations where it is not possible to connect, depending on the server's implementation.
Additionally, for IIDX14-17, it is more rational to hook the ea3_boot function and modify the value of /ea3/network/services.
M:eamuse-hook: my_gethostbyname: 'ea3.example.com' to ip 192.0.2.1:8080
M:eamuse-hook: my_gethostbyname: 'time.google.com' to ip 192.0.2.1:8080
M:eamuse-hook: my_gethostbyname: 'localhost' to ip 192.0.2.1:8080
M:eamuse-hook: my_gethostbyname: 'services.eamuse.konami.fun' to ip 192.0.2.1:8080
Domains such as ea3.example.com, localhost, and time.google.com are incorrectly resolved to the IP address 192.0.2.1.
In cases where services.get and other modules require different server IP addresses, connection becomes impossible.
Furthermore, in this example, specifying localhost for keepalive is intended to ping oneself.
If the server at 192.0.2.1 does not allow ICMP, the keepalive request fails, resulting in a connection error.
In the legacy IIDX (exe format), there is a problem with the functionality to specify a connection server.
The issue affects communications other than those to `services.eamuse.konami.fun` or `services.` , resulting in the alteration of all results from the gethostbyname function.
Due to this design, there are situations where it is not possible to connect, depending on the server's implementation.
Additionally, for IIDX14-17, it is more rational to hook the ea3_boot function and modify the value of `/ea3/network/services`.
## Example
Assume the following IP addresses:
- `example.com`: `192.0.2.1`
- `ea3.example.com`: `192.0.2.2`
- `localhost`: `127.0.0.1`
### Configuration
```
eamuse.server=http://example.com:8080
```
### `services.get` Response
```xml
<response>
<services status="0" expire="10800" fault="0">
<item name="cardmng" url="http://ea3.example.com:8080/ea3/+" />
<item name="facility" url="http://ea3.example.com:8080/ea3/+" />
<item name="message" url="http://ea3.example.com:8080/ea3/+" />
<item name="package" url="http://ea3.example.com:8080/ea3/+" />
<item name="pcbevent" url="http://ea3.example.com:8080/ea3/+" />
<item name="pcbtracker" url="http://ea3.example.com:8080/ea3/+" />
<item name="posevent" url="http://ea3.example.com:8080/ea3/+" />
<item name="pkglist" url="http://ea3.example.com:8080/ea3/+" />
<item name="local" url="http://ea3.example.com:8080/ea3/+" />
<item name="system" url="http://ea3.example.com:8080/ea3/+" />
<item name="ntp" url="ntp://time.google.com/" />
<item name="keepalive" url="ping://localhost/?ga=localhost&ma=localhost&pa=localhost&ia=localhost&t1=2&t2=10" />
</services>
</response>
```
### Resulting logs
```
M:eamuse-hook: my_gethostbyname: 'ea3.example.com' to ip 192.0.2.1:8080
M:eamuse-hook: my_gethostbyname: 'time.google.com' to ip 192.0.2.1:8080
M:eamuse-hook: my_gethostbyname: 'localhost' to ip 192.0.2.1:8080
M:eamuse-hook: my_gethostbyname: 'services.eamuse.konami.fun' to ip 192.0.2.1:8080
```
Domains such as `ea3.example.com`, `localhost`, and `time.google.com` are incorrectly resolved to the IP address `192.0.2.1`.
In cases where `services.get` and other modules require different server IP addresses, connection becomes impossible.
Furthermore, in this example, specifying `localhost` for keepalive is intended to ping oneself.
If the server at `192.0.2.1` does not allow ICMP, the keepalive request fails, resulting in a connection error.
Thank you for putting effort into the detailed report and providing an example.
I suppose you are specifically referring to this part of the code which doesn't string compare to services.eamuse.konami.fun but always returns the address that's configured on bemanitools.
Noticing the comment there, it seems there is an issue on Windows10 (and newer?) that was addressed by always just returning the address. I agree that's not a great solution and might cause odd issues in use-cases like yours now.
Additionally, for IIDX14-17, it is more rational to hook the ea3_boot function and modify the value of /ea3/network/services.
Great suggestion for an improvement. Would improve the code at least for these four versions significantly. We already have other games doing that, iirc jubeat 1 and popn music. So these might be a good place to start copy-pasting the code from.
Triaging the issue with your inputs and some initial thoughts how to address this probably meaningfully:
Avoid hooking these functions on AVS games that have ea3_boot. This avoids duct-taping edge cases on these versions at least, see the win10 issue comment
This should reduce the footprint for older games 9-13, so my_inet_addr hook is probably not needed (needs testing though)
Make my_gethostbyname do proper filtering of services.eamuse.konami.fun again and debug/test what's up with the win10 issue there and how that materializes again. I am wondering why any IP address had to resolve to the eamuse server address. This sounds weird. Why not just return the IP address that's provided there?
It appears that you already found your way around the code base by pointing out the potential source of the issue. Would you be willing to pick this issue up and try to address it with the guidance given above?
It seems fairly scoped and I am happy to support you in getting this implemented, tested, reviewed and merged.
Thank you for putting effort into the detailed report and providing an example.
I suppose you are specifically referring to [this part](https://github.com/djhackersdev/bemanitools/blob/ce1a004bf635a815a48d8fd1b5e248e7f4e670d0/src/main/iidxhook-util/eamuse.c#L110) of the code which doesn't string compare to `services.eamuse.konami.fun` but always returns the address that's configured on bemanitools.
Noticing the comment there, it seems there is an issue on Windows10 (and newer?) that was addressed by always just returning the address. I agree that's not a great solution and might cause odd issues in use-cases like yours now.
> Additionally, for IIDX14-17, it is more rational to hook the ea3_boot function and modify the value of /ea3/network/services.
Great suggestion for an improvement. Would improve the code at least for these four versions significantly. We already have other games doing that, iirc jubeat 1 and popn music. So these might be a good place to start copy-pasting the code from.
Triaging the issue with your inputs and some initial thoughts how to address this probably meaningfully:
* Avoid hooking these functions on AVS games that have ea3_boot. This avoids duct-taping edge cases on these versions at least, see the [win10 issue comment](https://github.com/djhackersdev/bemanitools/blob/ce1a004bf635a815a48d8fd1b5e248e7f4e670d0/src/main/iidxhook-util/eamuse.c#L110)
* This should reduce the footprint for older games 9-13, so `my_inet_addr` hook is probably not needed (needs testing though)
* Make `my_gethostbyname` do proper filtering of `services.eamuse.konami.fun` again and debug/test what's up with the win10 issue there and how that materializes again. I am wondering why any IP address had to resolve to the eamuse server address. This sounds weird. Why not just return the IP address that's provided there?
It appears that you already found your way around the code base by pointing out the potential source of the issue. Would you be willing to pick this issue up and try to address it with the guidance given above?
It seems fairly scoped and I am happy to support you in getting this implemented, tested, reviewed and merged.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In the legacy IIDX (exe format), there is a problem with the functionality to specify a connection server.
The issue affects communications other than those to
services.eamuse.konami.funorservices., resulting in the alteration of all results from the gethostbyname function.Due to this design, there are situations where it is not possible to connect, depending on the server's implementation.
Additionally, for IIDX14-17, it is more rational to hook the ea3_boot function and modify the value of
/ea3/network/services.Example
Assume the following IP addresses:
example.com:192.0.2.1ea3.example.com:192.0.2.2localhost:127.0.0.1Configuration
services.getResponseResulting logs
Domains such as
ea3.example.com,localhost, andtime.google.comare incorrectly resolved to the IP address192.0.2.1.In cases where
services.getand other modules require different server IP addresses, connection becomes impossible.Furthermore, in this example, specifying
localhostfor keepalive is intended to ping oneself.If the server at
192.0.2.1does not allow ICMP, the keepalive request fails, resulting in a connection error.Thank you for putting effort into the detailed report and providing an example.
I suppose you are specifically referring to this part of the code which doesn't string compare to
services.eamuse.konami.funbut always returns the address that's configured on bemanitools.Noticing the comment there, it seems there is an issue on Windows10 (and newer?) that was addressed by always just returning the address. I agree that's not a great solution and might cause odd issues in use-cases like yours now.
Great suggestion for an improvement. Would improve the code at least for these four versions significantly. We already have other games doing that, iirc jubeat 1 and popn music. So these might be a good place to start copy-pasting the code from.
Triaging the issue with your inputs and some initial thoughts how to address this probably meaningfully:
my_inet_addrhook is probably not needed (needs testing though)my_gethostbynamedo proper filtering ofservices.eamuse.konami.funagain and debug/test what's up with the win10 issue there and how that materializes again. I am wondering why any IP address had to resolve to the eamuse server address. This sounds weird. Why not just return the IP address that's provided there?It appears that you already found your way around the code base by pointing out the potential source of the issue. Would you be willing to pick this issue up and try to address it with the guidance given above?
It seems fairly scoped and I am happy to support you in getting this implemented, tested, reviewed and merged.