Hostname resolution

[jakned]

Hi, we are running Perspective app on multiple Raspberry Pi touchscreens and I since I have some application logic tied to a location, I use their hostname to display different views.

Now I have been running that for year now and I wanted to have a wifi connection as a backup in case network cable fails. Thats when the hostname resolution problems started. This is a code i use to determine the hostname:
InetAddress.getByName(ip).getHostName()

While this works on one active NIC, when the Pi has both wifi and eth, the code fails to resolve the hostname.

What could i do to have both wifi and eth running and still have the hostname resolution working?

Thanks

[Kevin.Herron]

Try InetAddress.getLocalHost().getHostName() and see if that gets you a better result.

[jakned]

Hi Kevin, thanks. I might have been not specific enough. I need to resolve a hostname of the Pi running the Perspective app. The getLocalHost gets me a hostname of the server running the script.

[Kevin.Herron]

Ahh, yeah... not sure then. You may need to hardcode a lookup table instead.

Not sure if it's possible or advised to have reverse DNS lookups point multiple IP at the same hostname, but I'm not an expert there.

[pturmel]

@jakned

since I have some application logic tied to a location

This is reason #1 to not use Perspective for fixed-location HMIs. The code you are trying to run (in Perspective) actually runs in the gateway, which won't have any insight into the client's route tables.

Vision can do this, and can interrogate more reliable unique info, like local MAC addresses.

Mobile Client MAC Address

In a real Vision client, you can obtain the local MAC addresses with the following script: from java.net import NetworkInterface # Get list of local mac address as strings def myMacIds(): macs = [ni.hardwareAddress for ni in NetworkInterface.getNetworkInterfaces() if ni.hardwareAddress] return [":".join(["%02x" % (b & 0xff) for b in mac]) for mac in macs] Also, again in a real Vision client, you can obtain the outbound network interface and the corresponding local IP address the clien…

[tgarrison]

Pass in a url parameter to identify the screen assuming it’s not a security problem for your situation.

Or assign each Pi it’s own Perspective login.

Or assign static IPs for both network interfaces, and use that instead of the hostname.

[jakned]

Thanks Phil for suggestion. All our development is now in Perspective.

[jakned]

I was considering also these options but the only one i can do is the one with ip addresses. I am also thinking about using nslookup from the underlying os that runs the gateway. Nslookup on the server works fine.

I opted for hostnames instead of IP addresses because i can replace the device without involving network team since i am the one configuring the hostname.

[pascal.fragnoud]

Maybe I misunderstand, but could you use the [System]Gateway/SystemName tag to do this ?

[dkhayes117]

I think he wants the hostname of the client, not gateway.

[pturmel]

@jakned

only one i can do is the one with ip addresses

If your IT group ever puts NAT between your HMIs and the gateway, Ignition will only see the NAT common IP. (Perhaps this is happening on your wifi path?)

@jakned

I opted for hostnames instead of IP addresses because i can replace the device without involving network team

Nowhere does a client tell Perspective what its host name is. The gateway must use reverse DNS on the source IP to look them up in your gateway's IT infrastructure. So your IT still has put hostnames into the infrastructure.

A Vision client can interrogate its local client environment for the hostname and pass it to the gateway. It is one of the other reliable unique identifiers that Vision can use that Perspective cannot.

@jakned

All our development is now in Perspective.

This is a huge mistake, IMNSHO. At least for applications that need fixed-location HMIs. (And a few other things.)

[pascal.fragnoud]

I was under the impression he wanted to change a displayed view based on the gateway, but as I said, I may have misunderstood.

edit: Oh wait, I see where I went wrong. I thought the RPIs were his gateways, but they're the HMIs.

[pturmel]

@pascal.fragnoud

based on the gateway

No, he has fixed-location HMIs that can't be disambiguated by IP when connecting over wi-fi. Which breaks the logic for which machine's information to display/control.

[jakned]

@pturmel

So your IT still has put hostnames into the infrastructure.

Not exactly. Not sure what magic is behing this, but when I deploy the Pi, I set the hostname and it ends up in the DNS. That means I dont have to ask IT to create a new reservation or a DNS record. I just take another one and give it the same hostname.

[pturmel]

@jakned

I set the hostname and it ends up in the DNS.

That means your IT has set up your DHCP server for your LAN to push client-supplied hostnames into your LAN's reverse-DNS. Which is why it works for your LAN.

Does your wifi DHCP do this too?