Can't find MODM7AE70

Discussion to talk about software related topics only.
matts
Posts: 2
Joined: Thu Nov 21, 2019 10:23 am

Can't find MODM7AE70

Post by matts »

I'm currently in the process of evaluating the MODM7AE70 and while trying to create a simple NetBurner project I can't seem to connect to my dev board. The dev board is directly connected to the computer and the search device option returns an empty list. I also tried the Scan for devices option in the NBFind window which is also unable to find my device. However, when using this I can see one of the RJ45 connector LEDs blink on the MODM7AE70. Running IPSetup from the NBEclipse IDE does absolutely nothing. I'm also unable to use the Discover NetBurner Devices option since my computer isn't and can't be connected to the Internet. I have disabled local network protections and antiviruses to no avail.

What could I do to solve this problem?
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Can't find MODM7AE70

Post by TomNB »

Hello Matt,

There are a couple of ways:
1. You can try the local discover program. I am attaching it.

2. You could put the module on any network with Internet access and use the discovery server to set an IP address

3. Some windows configurations and settings, as well as firewall and antivirus programs (which I know you said were disabled) can block packets that are not on the same subnet as your PC. If that is the case for yours, connecting the module to a network with a dhcp server would likely make it discoverable.

4. It can be configured through the serial port.
Attachments
localdiscover.zip
(3.66 MiB) Downloaded 199 times
matts
Posts: 2
Joined: Thu Nov 21, 2019 10:23 am

Re: Can't find MODM7AE70

Post by matts »

Hello Tom,

I tried your local discover program but the result is the same. As for option 2 and 3, I'm not able for security reason to connect any unauthorized device to my work network. How would I be able to configure the device through the serial port?

Thank you
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Can't find MODM7AE70

Post by TomNB »

Hello,

If localdiscovery is not working, there may something on your PC blocking the broadcast packets. Also, we have made some recent changes to the software that should help with this type of situation by using AutoIP addresses. It will be part of our upcoming 3.2 tools release due out before the end of the year. This is one of the reasons we switched from utility programs to configure and update the device, to a web based one from the device itself. I will add a lot of details here because I think it will be helpful to others.

Run our MTTTY serial program, or some other type of serial terminal
Press the reset button on the dev board
When you see the message "Type 'A' to abort", type the 'A' character
You should now see a message saying your are in serial configuration, and a '>' prompt. Typing "help" will give you a list of commands.

The serial config mimics the tree structure of the config web page. At any time you can type "ls" to see the next branch, or a "?" to see all the values of the current branch and those below it. The tab key will cycle through the next set of branches. Names are case sensitive. For example, type "Config" and you will go to the Config branch.

The place you want to get to is the network interface. Choose each of the branches to get to: Config.Sys.NetIf.Ethernet0.IPv4.
Now type a ? to see the current settings and variable names. For example:

Config.Sys.NetIf.Ethernet0.IPv4.>?{
"IPv4":{
"ActiveAddr":"10.1.1.78",
"ActiveDNS1":"10.1.1.1",
"ActiveDNS2":"0.0.0.0",
"ActiveGate":"10.1.1.1",
"ActiveMask":"255.255.252.0",
"AutoIPAddr":"169.254.132.143",
"AutoIPEn":true,
"Mode":{
"Choices":"DHCP,DHCP w Fallback,Static,Disabled",
"Value":"DHCP"
},
"StaticAddr":"10.1.1.199",
"StaticDNS1":"0.0.0.0",
"StaticDNS2":"0.0.0.0",
"StaticGate":"0.0.0.0",
"StaticMask":"255.255.255.0"
}
}

So you are going to need to set at least the IP address, mask and Mode. In the above you can see the Mode choices, and the current setting is DHCP. So type Mode to get to the Mode branch. Any branch that has choices also has a value branch. So now type Value. You should now be at:
Config.Sys.NetIf.Ethernet0.IPv4.Mode.Value>. The equal sign '=' sets a value. Type ="Static" to change the mode to Static.

Typing ".." moves up a branch. so move up to Config.Sys.NetIf.Ethernet0.IPv4>
Type StaticAddr, and set the value. For example, ="10.1.1.1"
Go up a level to IPv4, then to StaticMask and set its value
Go up a level to IPv4 again, then type a ? to verify the values are what you want

Now you need to save your modifications. You can go all the way to the top of the tree by typing a \ and enter. Now type the word save. Reboot the device for the settings to take effect. In a web browser, type the device's IP address followed by :20034 to access the config page. For example, 10.1.1.199:20034. You should see a page like the one below:
ConfigPage.jpg
ConfigPage.jpg (90.16 KiB) Viewed 3939 times

Additional comments:

1. Typing a ? will display the values for the current branch and all underneath it. For example, from the Config branch you would see all configuration settings.

2. The config system makes use of JSON objects, which can be downloaded or uploaded to a device. This can be very useful in production. Instead of having to configure each device parameter, you can just upload a JSON object with your settings.

3. The config system is not just for system settings. The AppData section is there for you to use in your applications to store things. You can easily create your own branches and elements. They will be part of the same JSON object, so if you had something like limits or calibration values, they would be loaded along with the system settings. There are examples of this in your dev kit.
KE5FX
Posts: 22
Joined: Tue Dec 10, 2019 11:17 pm

Re: Can't find MODM7AE70

Post by KE5FX »

Looks like I'm in a similar boat here. Just got a new MODM7AE70 evaluation kit, and It seems to be working fine, but ipfind.exe is missing in action and the nbfind functionality in the IDE doesn't work. Specifically, after jumping through the various NNDK installation hoops there's no sign of the ipsetup.exe utility anywhere in the directory tree, and the nbfind window in NBEclipse fails to find the board.

The find program in c:\nburn\pctools\find\python finds a spurious entry at 169.254.72.86 regardless of whether the board is plugged in or not:

However, the board is found successfully by (discover dot netburner dot com):

Running the localdiscover.exe utility that you posted elsewhere on the support forum also works OK:

Finally, I can ping it at 192.168.1.13 and access the factory demo application at http://[fe80::203:f4ff:fe0b:8521]/index.html .

(This is on Windows 7 x64, and there's no change when enabling/disabling Windows Firewall.)

Tried to post images of the results above but the BBS won't let me, despite offering the img tag. :?

Honestly, out of four different boards I've evaluated for this project, this is the worst OOBE so far. Not to mention the annoyance of having to Google for Java startup errors in your Eclipse build due to your failure to distribute the appropriate JRE.
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Can't find MODM7AE70

Post by TomNB »

Hello KE5FX,

I am sorry this has been a frustrating experience for you, and I appreciate you posting here so we can discuss the situation. I think issue may extend from the change in configuration and discovery between our 2.x set of tools, and the new 3.x tools. We include a mixture to try and provide tools for existing 2.x customers who also want to move to 3.x.

The 2.x tools used the following tools for discovery, configuration, and updates:
IPSetup, NBFind, Find, and Autoupdate. These are all windows utilities, and the utility handled a big part of the task. For example, IPSetup talked to the flash memory on the device to do the IP configuration settings, and autoupdate processed the image before sending it to the device's application space.

For 3.x, we wanted to provide platform independent methods for device configuration, discovery, and updates. Each device is capable of handling it's own configuration and updates. For example, any web browser on any platform can talk to the device and configure it's IP settings. You can update the application in the device using the same interface.

For discovery, there are two main methods:
1. If you have Internet connectivity, use discover dot netburner dot com. You said that worked, and it is the easiest. You can also specify your own discovery server if you do not with to use ours.

2. If you do not have Internet connectivity, such as a laptop with a direct connection to the device, a utility is needed, which is localdiscover.exe. You mentioned that worked as well.

The discovery feature in NBEclipse should be working, so we would like to look into that further with you and find out exactly which tool set you are using. Direct connections to a device that does not have an IP address, or can get one from a DHCP server, it tricky in windows, but we believe we have a fix for that by recognizing autoip addresses. That change is probably not in the tool set you currently have.

Regarding the JRE, we do not distribute the Oracle java due to the license terms. But we should provide more guidance. The 3.x tools should work with any 64-bit java version. If you don't mind replying, was the issue 32-bit vs 64-bit in your situation?

Thank you again for your time
KE5FX
Posts: 22
Joined: Tue Dec 10, 2019 11:17 pm

Re: Can't find MODM7AE70

Post by KE5FX »

TomNB wrote: Wed Dec 11, 2019 9:25 am Hello KE5FX,

I am sorry this has been a frustrating experience for you, and I appreciate you posting here so we can discuss the situation. I think issue may extend from the change in configuration and discovery between our 2.x set of tools, and the new 3.x tools. We include a mixture to try and provide tools for existing 2.x customers who also want to move to 3.x.
I do like the hardware so far, but haven't yet had time to come up to speed on the toolset. I'm hoping I haven't begun my familiarization process at a time when device discovery is being "migrated to the cloud" at the expense of local control. Doesn't sound like that's the case, but that impression is hard to avoid when the very first steps in the instructions don't work because the local tools are missing or nonfunctional.
The 2.x tools used the following tools for discovery, configuration, and updates:
IPSetup, NBFind, Find, and Autoupdate. These are all windows utilities, and the utility handled a big part of the task. For example, IPSetup talked to the flash memory on the device to do the IP configuration settings, and autoupdate processed the image before sending it to the device's application space.
So why do the instructions still call out these utilities, and why is the NBFind pane still present in NBEclipse? (Although, reading further below, it sounds like NBFind should have worked.)
For 3.x, we wanted to provide platform independent methods for device configuration, discovery, and updates. Each device is capable of handling it's own configuration and updates. For example, any web browser on any platform can talk to the device and configure it's IP settings. You can update the application in the device using the same interface.
That's great, but I have to do this under program control, rather than via a web page hosted on the device or anywhere else. I don't necessarily need to provision the IP address, but I have to be able to discover the device and install or upgrade the application that it runs.
For discovery, there are two main methods:
1. If you have Internet connectivity, use discover dot netburner dot com. You said that worked, and it is the easiest. You can also specify your own discovery server if you do not with to use ours.
The way applications have traditionally discovered DHCP-configured devices is by sending a broadcast packet and listening for replies, as in \nburn\pctools\find\find.cpp. Does that no longer work? I compiled find.cpp and granted it firewall access, but it doesn't find the device.

At one point yesterday, I could have sworn that find (dot) py did locate the board and report its IP address, in addition to the spurious entry in the 169.254.x.x range that it always returns. So it appears that the board has stopped responding to UDP discovery broadcasts, even though it continues to serve its web pages as expected.
2. If you do not have Internet connectivity, such as a laptop with a direct connection to the device, a utility is needed, which is localdiscover.exe. You mentioned that worked as well.
Hmm, this might be a good clue. The precompiled localdiscover.exe that you posted above (Nov 21) still successfully finds the board, bringing up a web page with the info:

Code: Select all

00:03:F4:0B:85:21	192.168.1.13	Config	Web
169.254.133.33	Config	Web
fe80::203:f4ff:fe0b:8521	Config	Web
However, when I compile \nburn\pctools\LocalDiscovery\VisualCppVersion\main.cpp with

Code: Select all

cl main.cpp shell32.lib
and run main.exe, the Web page that it launches says

Code: Select all

There are no devices currently known on your network.
The discovery feature in NBEclipse should be working, so we would like to look into that further with you and find out exactly which tool set you are using. Direct connections to a device that does not have an IP address, or can get one from a DHCP server, it tricky in windows, but we believe we have a fix for that by recognizing autoip addresses. That change is probably not in the tool set you currently have.
The device definitely has a valid address, and is working OK, but I agree that it sounds like I may have installed the wrong toolset by mistake, given that your executables work and mine don't. The version I installed came from NNDK-3.1.0-installer.exe from support (dot) netburner (dot) com/SelfService/Tools.html. Should I try a different download?
Regarding the JRE, we do not distribute the Oracle java due to the license terms. But we should provide more guidance. The 3.x tools should work with any 64-bit java version. If you don't mind replying, was the issue 32-bit vs 64-bit in your situation?
Yes, I have an older 32-bit JRE on this machine that I'm scared to uninstall/upgrade or otherwise mess with because it was a pain to get it working with some other hardware in use here. NBEclipse worked fine once I installed jdk8u232-b09 from adoptopenjdk (dot) net.

I've had to install numerous versions of Eclipse on this PC at various times and this is the first time it didn't work right out of the box. Not sure if the usual practice is to install both 32- and 64-bit builds, or to bundle a JRE. I do appreciate that your Eclipse distribution is less bloated than everyone else's, though. :)
Thank you again for your time
Likewise! Just let me know if any further info is needed to figure out what's going on.
KE5FX
Posts: 22
Joined: Tue Dec 10, 2019 11:17 pm

Re: Can't find MODM7AE70

Post by KE5FX »

Update: it turns out that the behavior above occurs because the various 'find' utilities don't support at least some multihomed PCs reliably, including mine. The attached rewrite of find.cpp ('findall') seems to work well.
Attachments
findall.zip
(66.13 KiB) Downloaded 156 times
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Can't find MODM7AE70

Post by TomNB »

Hello KE5FX,

Thank you again for your comments, please see replies below:

I do like the hardware so far, but haven't yet had time to come up to speed on the toolset. I'm hoping I haven't begun my familiarization process at a time when device discovery is being "migrated to the cloud" at the expense of local control. Doesn't sound like that's the case, but that impression is hard to avoid when the very first steps in the instructions don't work because the local tools are missing or nonfunctional.
Not at all. We have many customers that run in environments that do not have Internet access, and non is needed to use our products. The local discovery utility did not come out as soon as it should have, and we did not correctly anticipate the issues with IPSetup not working at an intermediate measure. To be clear again, IPSetup should no longer be used. There is the multihome issue you mention with local discovery that we are looking into now, but we have not found any other issues in our testing and field feedback so far. The discovery server can still be very useful for those who want to discover a device on mobile and tablet platforms without having to install an app.
So why do the instructions still call out these utilities, and why is the NBFind pane still present in NBEclipse? (Although, reading further below, it sounds like NBFind should have worked.)
I agree with you on this and we will have to locate those places in the docs and correct them. Our recommended starting place is on the first page of the docs: https://www.netburner.com/NBDocs/Develo ... index.html. The current docs in pre-release also cover local discovery, and the utility shortcuts are being removed from nbeclipse. That said, we still do want to have the utilities available for those who wish to upgrade a 5441x based platform from 2.x to 3.x, as they will need to be able to identify and update units running 2.x software.
That's great, but I have to do this under program control, rather than via a web page hosted on the device or anywhere else. I don't necessarily need to provision the IP address, but I have to be able to discover the device and install or upgrade the application that it runs.
We do describe two utility methods in the Production and Deployment section: https://www.netburner.com/NBDocs/Develo ... d_dep.html. They are a windows utility called nbupdate, and a WGET utility that should be available on any platform. As mentioned earlier in this thread, you can actually configure not just any system parameter (eg IP address), but also any of your application variables. You can send all, or any branch of the config system tree using the JSON format. I will have to follow up with you on the eaiest way to combine this with device discovery
The way applications have traditionally discovered DHCP-configured devices is by sending a broadcast packet and listening for replies, as in \nburn\pctools\find\find.cpp. Does that no longer work? I compiled find.cpp and granted it firewall access, but it doesn't find the device.

At one point yesterday, I could have sworn that find (dot) py did locate the board and report its IP address, in addition to the spurious entry in the 169.254.x.x range that it always returns. So it appears that the board has stopped responding to UDP discovery broadcasts, even though it continues to serve its web pages as expected.
That should work. It seem from your follow-on post that there is an issue if your computer if multihomed and it goes out on a different subnet. We need to look into this more.

Hmm, this might be a good clue. The precompiled localdiscover.exe that you posted above (Nov 21) still successfully finds the board, bringing up a web page with the info:

Code: Select all

00:03:F4:0B:85:21	192.168.1.13	Config	Web
169.254.133.33	Config	Web
fe80::203:f4ff:fe0b:8521	Config	Web
However, when I compile \nburn\pctools\LocalDiscovery\VisualCppVersion\main.cpp with

Code: Select all

cl main.cpp shell32.lib
and run main.exe, the Web page that it launches says

Code: Select all

There are no devices currently known on your network.
I am not certain why that is, but will check to see if any code changes were made since the 3.1 release.

The device definitely has a valid address, and is working OK, but I agree that it sounds like I may have installed the wrong toolset by mistake, given that your executables work and mine don't. The version I installed came from NNDK-3.1.0-installer.exe from support (dot) netburner (dot) com/SelfService/Tools.html. Should I try a different download?
There have been changes since 3.1. I can't post system source here, but we will contact you through support to get you the latest code.
Yes, I have an older 32-bit JRE on this machine that I'm scared to uninstall/upgrade or otherwise mess with because it was a pain to get it working with some other hardware in use here. NBEclipse worked fine once I installed jdk8u232-b09 from adoptopenjdk (dot) net.

I've had to install numerous versions of Eclipse on this PC at various times and this is the first time it didn't work right out of the box. Not sure if the usual practice is to install both 32- and 64-bit builds, or to bundle a JRE. I do appreciate that your Eclipse distribution is less bloated than everyone else's, though. :)
Thank you. The various Eclipse releases on vendor tool sets specifically work on 32-bit or 64-bit, but not both in one release. I've had to run both 32-bit and 64-bit on my machine for quite some time and it has worked so far.
Thank you again for your time
Likewise! Just let me know if any further info is needed to figure out what's going on.
You are welcome and we will be in touch soon.
User avatar
pbreed
Posts: 1080
Joined: Thu Apr 24, 2008 3:58 pm

Re: Can't find MODM7AE70

Post by pbreed »

Under the nburn\pctools.....

section there is a find.

c/c++ and python version of device discovery.
Also a ipv6 python find.
Also there is localdiscovery written in Go.
The guts of all of these can be used by you to discover devices.

This gets harder to do if you have multiple interfaces, as you have to send the discover query packet out each interface.
This is easy in some languages, and hard in others.
Post Reply