Retired
- Joined
- Oct 28, 2013
- Messages
- 536
- Reaction score
- 103
Everybody knows that issue, when running the pServer on a local instance with one or more adapters:
Cert runs on e.g. 192.168.178.20,
GlobalManager connects to the IP of Cert,
MachineManager, the witch it is, obtains its IP from the binding system, which in this case (if automatically being set) will choose the adapter with the lowest or suitable matrix (e.g. WLAN adapter with a different IP than the local ethernet adapter with its local IP (192.168.178.20)),
and this will stop all continuing processes from linking properly with each module.
There should be a possibility changing this, as either outsourcing it to a dll file or having a bypass/fix applying directly on that crappy network protocol binding system, which does not exist anymore on windows 10, or narrowed down af.
Did anyone achieved there anything?
A temp, but also an unsatisfying, fix for this is either using the dynamic IP (public) of the adapter, or simply disabling the corresponding adapter before booting the server - and reactivating it.
Cert runs on e.g. 192.168.178.20,
GlobalManager connects to the IP of Cert,
MachineManager, the witch it is, obtains its IP from the binding system, which in this case (if automatically being set) will choose the adapter with the lowest or suitable matrix (e.g. WLAN adapter with a different IP than the local ethernet adapter with its local IP (192.168.178.20)),
and this will stop all continuing processes from linking properly with each module.
There should be a possibility changing this, as either outsourcing it to a dll file or having a bypass/fix applying directly on that crappy network protocol binding system, which does not exist anymore on windows 10, or narrowed down af.
Did anyone achieved there anything?
A temp, but also an unsatisfying, fix for this is either using the dynamic IP (public) of the adapter, or simply disabling the corresponding adapter before booting the server - and reactivating it.