February-12th-2018, 07:15 AM
Because I'm interested in such things myself, I've done some experiments.
My current assumption is that accessing the NetPI3 by "http://NTBxxxxxxxxxx" always works on Windows and Linux (if Avahi is running). If it doesn't work on MacOS and iOS your DHCP server (e.g. router) may not support the required mechanisms. In that case, using "http://NTBxxxxxxxxxx.local" should help. On Android devices, without support from the DHCP server, you may be out of luck.
[b]I don't claim that this is the absolute truth, this is just a conclusion based on the observations of the following experiments:
I setup a test-firewall on which I installed a PFSense from scratch. For the router's LAN network I enabled DHCP. Other than that, I left all the settings as they were. IOW: PFSense was configured with everything set to "default".
I tested with the following devices, all connected to the LAN network (Router <-> Switch <-> WLAN Access point): NetPI3 was connected to the Switch by cable, while all other devices run over WLAN:
- MacBookPro, MacOS 10.13.3
- Windows 10, running on MacBookPro with VMWare Fusion
- Ubuntu 64 Bit, 17.10, running on MacBookPro with VMWare Fusion
- Raspberry Pi 3, Raspian
- iPhone 6, iOS 11.2.5
- Galaxy S6, Android
I tried to 'ping' the NetPi3 from each of the PC OSs and used a Web browser on the Smartphone OSs. I did so with two different names:
1) NTB827NTBxxxxxxxxxx (e.g. ping NTB827NTBxxxxxxxxxx)
2) NTB827NTBxxxxxxxxxx.local
An 'x' indicates that accessing the NetPI3 failed, i.e. the NetPI3's IP address couldn't be resolved.
| NTBxx | NTBxx.local | Client
| OK | OK | Windows 10
| x | OK | MacOS
| OK | OK | Ubuntu 10.17
| OK(1) | OK | Raspian
| x | OK | iOS
| x | x | Android
(1) On the first attempt, it didn't work, but later it did. Maybe there was a network connection issue when I tried initially.
Next, I enabled PFSense's “Register DHCP leases in the DNS resolver”. With that option set, the NetPI3’s IP address was successfully resolved on all tested client by it’s name: NTBxxxxxxxxxx. This change did not influence the behaviour when using NTBxxxxxxxxxx.local.
| NTBxx | NTBxx.local | Client
| OK | OK | Windows 10
| OK | OK | MacOS
| OK | OK | Ubuntu 10.17
| OK | OK | Raspian
| OK | OK | iOS
| OK | x | Android
Based on this experiments and by looking at the Wireshark traces, I would say that: If the router supports DHCP client names, resolving the NetPI3's name works on all (tested) clients by old-style DNS. Without proper support from the "Router" (PFSense in my case), the NetPI3's name can't be resolved by DNS. Fortunately, it is still accessible on Windows thanks to NetBIOS name services and on Linux and MacOS by MDSN (Bonjour/AVAHI), although, on MacOS and iOS, that's only the case if appending the ".local" to the NetPI3's name. Stopping the 'avahi' service (MDNS) on Raspian causes the name resolving to stop from working.
I claim that not resolving the "DHCP client names" is not a PFSense-only issue. I think I run into the same issue when the NetPI3 was connected to a network of a big well known company and I tried to access the it by MacOS. I can't be sure that it was the same issue, as I did not debug it using Wireshark. Also, at that time, I wasn't aware of the ".local" trick. Therefore, back than, I really couldn't access the NetPI3 :-(
Maybe a hint of the ".local" trick on the small piece of paper you ship along with the NetPI3 could be helpful for MacOS users.
Another useful thing could be a tiny Node script like this:
var bonjour = require('bonjour')()
// browse for all NTB devices
// The search approach is probably not very robust, but it worked with the one device I own. Possible caveats:
// - 'sftp-ssh' service type is actually now we are looking for. We are looking for http services. Moreover, the
// advertised 'ssh' service seems actually being available. At least the promised service can't be reached.
// Maybe they user port knocking? Otherwise, this service may only be available at development time for Hilscher
// engineers? However, I could imagine that Hilscher may remove this advertisement in the future or replace it
// with a more appropriate one ('http')
// - The code assumes only one "service.referer.address". I haven't studied the details of possible response
// structures. Instead, I just checked what my device returns and hope that it's the same for all such devices, which
// may not be true and thus, the code may throw an exception
// - I actually don't know if all these Hilscher device names really start with (or 'include') "NTB"... Again:
// this is what my device returns and hopefully it's the same for all such device types
bonjour.find({ type: 'sftp-ssh' }, function (service) {
if (service.name.includes('NTB')) {
console.log('Found an NTB device:', `https://${service.referer.address}`)
}
})
My current assumption is that accessing the NetPI3 by "http://NTBxxxxxxxxxx" always works on Windows and Linux (if Avahi is running). If it doesn't work on MacOS and iOS your DHCP server (e.g. router) may not support the required mechanisms. In that case, using "http://NTBxxxxxxxxxx.local" should help. On Android devices, without support from the DHCP server, you may be out of luck.
[b]I don't claim that this is the absolute truth, this is just a conclusion based on the observations of the following experiments:
I setup a test-firewall on which I installed a PFSense from scratch. For the router's LAN network I enabled DHCP. Other than that, I left all the settings as they were. IOW: PFSense was configured with everything set to "default".
I tested with the following devices, all connected to the LAN network (Router <-> Switch <-> WLAN Access point): NetPI3 was connected to the Switch by cable, while all other devices run over WLAN:
- MacBookPro, MacOS 10.13.3
- Windows 10, running on MacBookPro with VMWare Fusion
- Ubuntu 64 Bit, 17.10, running on MacBookPro with VMWare Fusion
- Raspberry Pi 3, Raspian
- iPhone 6, iOS 11.2.5
- Galaxy S6, Android
I tried to 'ping' the NetPi3 from each of the PC OSs and used a Web browser on the Smartphone OSs. I did so with two different names:
1) NTB827NTBxxxxxxxxxx (e.g. ping NTB827NTBxxxxxxxxxx)
2) NTB827NTBxxxxxxxxxx.local
An 'x' indicates that accessing the NetPI3 failed, i.e. the NetPI3's IP address couldn't be resolved.
| NTBxx | NTBxx.local | Client
| OK | OK | Windows 10
| x | OK | MacOS
| OK | OK | Ubuntu 10.17
| OK(1) | OK | Raspian
| x | OK | iOS
| x | x | Android
(1) On the first attempt, it didn't work, but later it did. Maybe there was a network connection issue when I tried initially.
Next, I enabled PFSense's “Register DHCP leases in the DNS resolver”. With that option set, the NetPI3’s IP address was successfully resolved on all tested client by it’s name: NTBxxxxxxxxxx. This change did not influence the behaviour when using NTBxxxxxxxxxx.local.
| NTBxx | NTBxx.local | Client
| OK | OK | Windows 10
| OK | OK | MacOS
| OK | OK | Ubuntu 10.17
| OK | OK | Raspian
| OK | OK | iOS
| OK | x | Android
Based on this experiments and by looking at the Wireshark traces, I would say that: If the router supports DHCP client names, resolving the NetPI3's name works on all (tested) clients by old-style DNS. Without proper support from the "Router" (PFSense in my case), the NetPI3's name can't be resolved by DNS. Fortunately, it is still accessible on Windows thanks to NetBIOS name services and on Linux and MacOS by MDSN (Bonjour/AVAHI), although, on MacOS and iOS, that's only the case if appending the ".local" to the NetPI3's name. Stopping the 'avahi' service (MDNS) on Raspian causes the name resolving to stop from working.
I claim that not resolving the "DHCP client names" is not a PFSense-only issue. I think I run into the same issue when the NetPI3 was connected to a network of a big well known company and I tried to access the it by MacOS. I can't be sure that it was the same issue, as I did not debug it using Wireshark. Also, at that time, I wasn't aware of the ".local" trick. Therefore, back than, I really couldn't access the NetPI3 :-(
Maybe a hint of the ".local" trick on the small piece of paper you ship along with the NetPI3 could be helpful for MacOS users.
Another useful thing could be a tiny Node script like this:
var bonjour = require('bonjour')()
// browse for all NTB devices
// The search approach is probably not very robust, but it worked with the one device I own. Possible caveats:
// - 'sftp-ssh' service type is actually now we are looking for. We are looking for http services. Moreover, the
// advertised 'ssh' service seems actually being available. At least the promised service can't be reached.
// Maybe they user port knocking? Otherwise, this service may only be available at development time for Hilscher
// engineers? However, I could imagine that Hilscher may remove this advertisement in the future or replace it
// with a more appropriate one ('http')
// - The code assumes only one "service.referer.address". I haven't studied the details of possible response
// structures. Instead, I just checked what my device returns and hope that it's the same for all such devices, which
// may not be true and thus, the code may throw an exception
// - I actually don't know if all these Hilscher device names really start with (or 'include') "NTB"... Again:
// this is what my device returns and hopefully it's the same for all such device types
bonjour.find({ type: 'sftp-ssh' }, function (service) {
if (service.name.includes('NTB')) {
console.log('Found an NTB device:', `https://${service.referer.address}`)
}
})
