IP address works but duet3.local/ doesn't?

[warbunnies]

I have a duet 3 with a pi4 hooked up. Just got it. The only thing I have done so far is change the wpa_supplicant file to match networks being used.

Everything worked perfectly on my home network, then I took it in to work and ran into problems. I thought it wasn't working period but we got our IT guy involved and apparently it did connect after like 4 minutes but you could only connect with the ip address and the duet3.local/ did not work. It would be nicer if it did.

I'm curious if anyone has any ideas on why this would happen?

[Veti]

@warbunnies said in IP address works but duet3.local/ doesn't?:

duet3.local

that only works if the dns and dhcp server supports it.
odds are that the one at work does not, as that is more of a home router feature not a business feature.

[A Former User]

.local isn't that a multicast DNS thing; i.e. only requires client support?

If using Windows try installing Apple Bonjour to support mDNS. To rely on your local router you probably have a different dns suffix (which is likely in the client searched list) so try just duet3 or duet3. to avoid mDNS if the client doesn't support it.

[warbunnies]

@Veti thank you! i will admit that network stuff is not my area.

@bearer thank you! those 2 suggestions did not produce results but hopefully that is enough information to get our IT guy on the right track.

[A Former User]

@warbunnies said in IP address works but duet3.local/ doesn't?:

to get our IT guy on the right track.

if your client computer and the Duet3/Pi4 isn't on the same subnet then the whole .local thing will likely not work without the network helping out forwarding the mDNS stuff (unlikely in a enterprise network)

if IT wanna assign a hostname to the Pi from their DHCP server you need to change the hostname on the Pi back to localhost otherwise it will ignore any DHCP hostname options. and if the hostname is not "duet3" then config.g needs to be updated and M550 should match the hostname. (not sure if that is FQDN or just the hostname, but suspect hostname)

[warbunnies]

@bearer

Looks like I got some reading to do.

[A Former User]

@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 iirc

Then type in localhost and reboot. (IF you need to have hostname managed by IT)

[droftarts]

@warbunnies see this note, too: https://duet3d.dozuki.com/Wiki/Setting_up_networking_on_Duet#Section_A_note_about_mDNS_local_network_discovery

Ian

[Veti]

depending on the size of the company you could have different subnets limiting broadcasts.
or guest vlan tagging on switches.
network access control
etc.

[OwenD]

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.

[A Former User]

@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.

[chrishamm]

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.

[A Former User]

@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.

[OwenD]

@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.

[chrishamm]

@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.

[A Former User]

@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