• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DHCP/DNS issue: Couldn't access NetPI3 out-of-the-box
#1
Initially, when I connected my new NetPI3 to my LAN, I wasn't able to access it by the described instructions (opening the browser and enter the "name" mentioned on the sticker). I also couldn't "ping" it because the "name" could not be resolved.

After some debugging, I could resolve the issue by reconfiguring my router (pfsense): The DHCP-Server didn't automatically update the DNS entries. I can't remember the very details, because already some days past since then, but may claim is: I think that the way to initially access the NetPI3 is not working under all circumstances (possibly including some "pretty popular" ones, as my "pfsense" setup was quite virgin).

Question: Are you aware of that? If not, would it help if I reproduce the issue and provide more information on this?

Another possibly related question: In one of the forum posts you mention the Tcp/Udp ports opened by the NetPI3. According to that post, bonjour is running as well. Why? Can it be used as another option to initially access the NetPI3?
  Reply
#2
130 Wrote:Question: Are you aware of that? If not, would it help if I reproduce the issue and provide more information on this?

Since netPI is not the only device that we are providing with the very same DHCP function, I want to reinsure if anybody in the development is aware of such a problem. I will return back to you with results when I have more information
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
130 Wrote:Another possibly related question: In one of the forum posts you mention the Tcp/Udp ports opened by the NetPI3. According to that post, bonjour is running as well. Why? Can it be used as another option to initially access the NetPI3?

Yes you can use a detection function across the bonjour service as well. I tested a detection with a scanner software from company Hobbiyst Software. It works pretty well. It is available for multiple OSs, I tested the Windows version.
If you are in a company network and your network mask is about 255.255.0.0 the scanning procedure take long long time. So make sure you are in a 255.255.255.0 network. Then it is pretty fast.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#4
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}`)
}
})
  Reply
#5
Wow great work which I feel took a long time to execute it. Thank you very much in the name of the whole forum.

To be honest we have not evaluated Hostname resolutions as in-deep ever as you did. But now you gathered further informations that could help others having similar problems.

For all those where Hostname resolution does not work at all ... they have always the possibility to ask their IT team (or a short look into the router) along with the MAC-Address which IP address has been assigned to netPI and then finally address netPI with its IP address instead of the Hostname.

One remark: Hostname netPI starts with //NTxxxxxxxxxx . The following "B" is already part of the MAC-Address.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#6
I have linux and windows both and the http://NTxxxxxxxxxx does not work on the firefox and the internet explorer browser. I have the pfsense router in which I enable DHCP service. But by adding " .local " in the name, it works.
Alternatively, by finding the IP address of the netPI by accessing the router's ARP table, logging in can be performed by just typing the IP in the browser.
Thanks!
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  443 port issue LucioFiam 5 2,144 November-21st-2022, 05:39 PM
Last Post: LucioFiam
  Wi-fi in Access Point mode Renato75 7 4,649 June-3rd-2022, 12:59 PM
Last Post: Armin@netPI
  NetPI wifi access to WPA2-Enterprise MikeP 4 4,254 September-3rd-2021, 02:56 PM
Last Post: MikeP
  Node red web UI issue DSongra 3 3,151 July-22nd-2021, 02:47 PM
Last Post: Armin@netPI
  [SOLVED]DHCP server not working m-yoshikawa 24 13,619 June-11th-2021, 07:04 AM
Last Post: tad
  netPI RTE 3: access from several comm. masters tad 3 4,025 June-3rd-2021, 12:03 PM
Last Post: Armin@netPI
  Access to RTC from my own container application tad 1 3,521 March-19th-2021, 02:58 PM
Last Post: Armin@netPI
  netPI _Node red issue SAhire@hilscher.local 1 2,035 September-23rd-2020, 08:00 AM
Last Post: Armin@netPI
  Bluetooth Access MGharat 10 8,536 February-25th-2020, 12:58 PM
Last Post: DSongra
Wink How to access Root Directory Rajesh3128 8 5,069 October-16th-2019, 11:19 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)