IP address works but duet3.local/ doesn't?
-
@bearer said in IP address works but duet3.local/ doesn't?:
change the hostname on the Pi back to localhost
In a shell on the pi
sudo raspi-config-> advanced -> hostname iircThen type in localhost and reboot. (IF you need to have hostname managed by IT)
-
-
depending on the size of the company you could have different subnets limiting broadcasts.
or guest vlan tagging on switches.
network access control
etc. -
I had a similar situation with a Linux box at work (not a printer) running Ubuntu
I tried all the recommendations in my searches regarding winbind settings etc.
The simple solution was to install Samba on the box.
This made the hostname available across the network.
Not sure how much overhead that would have on a Pi, but it worked for me. -
@OwenD interesting observation - just to clarify that was to solve a windows client resolving the hostname for the linux box?
it could well work for a windows centric network if WINS is configured correctly and DNS is all fubar.
-
On recent Windows 10 versions Bonjour is no longer needed because MS added native mDNS support at some point. I suspect @Veti is right, mDNS name resolution requires UDP broadcasts to work and they may not be wanted in corporate networks. For mDNS service discovery IGMP is required.
-
@chrishamm said in IP address works but duet3.local/ doesn't?:
mDNS name resolution requires UDP broadcasts to work and they may not be wanted in corporate networks.
If the Duet 3 is primarily targeted at business users it might not be the best fit to use mDNS? (IIRC the rationale behind no WiFi on the Duet 3 was the Ethernet affinity of the business users)
I guess the Pi amplifies the issue by ignoring any hostname (Option 12) sent by the DHCP server in its default configuration, not sure if the Duet3 does the same in stand alone mode?
In any case its easy enough to ask OP to check the IP (and netmask) of the Pi4 and his client computer to see if they're on the same subnet, if one is wireless and the other is wired odds are good for being separate subnets in a larger network.
-
@bearer
Yes that was the case.
The application on the Linux box could be accessed via the IP address ( from a windows client) but the Linux application could not be accessed using hostname.local from the same windows client.
Interestingly, prior to this I was running the Linux application in a VM on a windows box and had no such issues.
In my case installing Samba on the Linux box corrected whatever was misconfigured and required no tampering with the network settings. -
@bearer said in IP address works but duet3.local/ doesn't?:
If the Duet 3 is primarily targeted at business users it might not be the best fit to use mDNS? (IIRC the rationale behind no WiFi on the Duet 3 was the Ethernet affinity of the business users)
In bigger corporate networks the lack of mDNS is usually no big problem because you can use DHCP+DNS there. As far as I am aware regular Active Directory setups automatically create DNS records when an IP address is obtained via DHCP so you could for example enter http://duet3/ in the browser of another client computer and it would resolve the hostname right away.
I think mDNS is a good solution for smaller networks though.
-
@chrishamm said in IP address works but duet3.local/ doesn't?:
As far as I am aware regular Active Directory setups automatically create DNS records when an IP address is obtained via DHCP
if they create a dhcp reservation for another hostname than duet3 then it breaks because the pi ignores option 12 when the pi's hostname isn't localhost and op has already confirmed http://duet3/ doesn't work
