[Jeff Hatch]

Martin,

The mLinux 4 release is getting complicated for reasons that I can’t go into right now. It is based on Yocto 2.2 (Morty). Please file a support portal case at https://support.multitech.com if you are doing development that is targeted for mLinux 4. You should be able to get toolchain support for mLinux 4 at the least.

Jeff

[Jeff Hatch]

Alois & Martin,

Thank you for pointing this out. A ticket has been filed to fix this content.

Thank You again,

Jeff

[Jeff Hatch]

Albert,

Please file a portal case at support.multitech.com. They will be able to give you more dedicated help.

Jeff

[Jeff Hatch]

Albert,

Thank you for clarifying. I definitely recommend talking to the provider first to see what they are allowing for incoming traffic. Then proceed from there.

Jeff

[Jeff Hatch]

Manoj,

Under http://www.multitech.net/developer/downloads/ there is a Conduit: mLinux Model section, and the mLinux MTCDT 3.3.6 download is located in that section.

Jeff

[Jeff Hatch]

Albert,

Have you enabled access via WAN for HTTPS and SSH on the Conduit? Under Administartion->Access Configuration there are Web Server and SSH panes where you can enable via HTTPS and WAN.

Jeff

[Jeff Hatch]

Manoj,

Here at Multitech we have had occasional issues with openembedded.org’s git when doing builds because our Intrusion Detection will shun the site due to some attack it has detected coming from that site’s web server. It usually goes away after a little while, but I have had our IT folks “clear” the shun and that has helped.

Jeff

[Jeff Hatch]

Luis,

The reason the npm install is failing is most likely that Node-RED has dependencies that need to be built locally on the Conduit. The Conduit does not have the build utilities installed because it does not have enough room on the device.

The new releases coming out for Conduit support Node-RED 0.15.3 and that is the farthest it can go on Node-RED due to the fact that node-js does not support the CPU instruction set (armv5) of the Conduit beyond version 0.10.48.

To summarize, Conduit cannot run anything beyond Node-RED 0.15.3, and node-js 0.10.48.

Jeff

[Jeff Hatch]

Sai,

Please file a support portal case at https://support.multitech.com

Thank You,

Jeff

[Jeff Hatch]

Paul,

Here’s what is working for me.

1) Wi-Fi as WAN enabled
2) No Saved Wi-Fi Networks checked
3) After a reboot go to the Wireless->Wi-Fi as WAN again, hit Refresh on the Available Wi-Fi Networks pane, and after about 15 or so seconds I got a list of networks detected with the scan.

So, leave Wi-Fi as WAN enabled and un-check any Saved Networks. If that doesn’t work try “iw dev wlan0 scan”. I was able to execute that command and see all the info one each available network.

I am not sure what is going on with the Web UI. If you know the SSID and network name of the network, you can add it manually under Add Network on the Saved Wi-Fi Networks pane.

Jeff

• This reply was modified 7 years, 4 months ago by Jeff Hatch.

[Jeff Hatch]

John,

You could try “tcpdump -X -i ppp0”. This output is not showing you what the data is. There are also ways to filter (host ) on ports (port and IPs. The tcpdump on Conduit is the same as on any Linux machine.

Jeff

[Jeff Hatch]

John,

Have you tried tcpdump on ppp0? That might shed some light on what’s going on if the data isn’t encrypted.

Jeff

[Jeff Hatch]

John,

Are you doing encryption. Is this TCP or UDP? What messages are being sent to Azure? Is your connection good? If you have a signal that is weak, TCP will cause retransmissions at a high rate. Until these questions are answered one cannot even speculate. Even UDP will take overhead that will make the 8 LoRa packet characters much bigger. I am suspicious that it is either encryption or weak signal with retransmissions, or both.

Jeff

[Jeff Hatch]

Paul,

Can you disable WiFi as WAN, reboot, and then see if the scan works? There is a limitation in the WiFi module on the Conduit such that if WiFi station or AP is enabled it will not be able to do a scan. Make sure that AP is disabled.

Jeff

[Jeff Hatch]

Steve,

The Web UI uses the same “REST service” in that it is the same daemon, same code, same requests. That said, I understand your point. The limitation is that there are more than two ways that the API is used on the MTR, but the central focus was on the Web UI. In that case it is users hitting it via their web browsers. On a device like the MTR (embedded industrial router) there will be a limited number of services and functionality will be combined together like in this case.

The IP restriction will remain unless we (Multitech) can figure out a way to differentiate between browser traffic and clients hitting the API from a non-browser app. I’m sure there are ways to do this. On the other hand, it may be that we decide to drop the IP limitation.

Jeff

[Jeff Hatch]

Steve,

Actually, this behavior is quite common (not wanting the same user to be logged in from two IPs) on a lot of products. For instance, gmail will notify you when you log in from an IP that it doesn’t recognize. The key is to log out from the first IP when you are finished with your request. See:

Logging Out

On the other hand, MTR 4.0 that is going to be released in Q1 will have multiple user support, so you can create multiple users that will persist in the MTR API database.

Jeff

[Jeff Hatch]

Antonio,

That would be a problem. Your PC is trying to send packets to the Conduit over the WiFi interface because that is where it’s default route probably points to.

Jeff

[Jeff Hatch]

Antonio,

You will have to manually configure the Ethernet interface with a 192.168.2.x address. Once you do that you shouldn’t need a default gateway for that interface. What is the IP that the WiFi interface is getting? As long as that one is not 192.168.2.x the packets for the Conduit should be going through the Ethernet interface.

Jeff

[Jeff Hatch]

Antonio,

What is the IP on the Ethernet interface of your PC? If it isn’t a 192.168.2.0/24 address you’re PC will try to use the WiFi interface and that route to reach the Conduit.

Jeff

[Jeff Hatch]

Mikael,

I think I have found the culprit. The /etc/init.d/sshd script overwrites parts of the /etc/ssh/sshd_config file. I think this may be what is reverting your changes. I’m pretty sure you are right that making Remote Access configuration changes can trigger this overwrite. It will also happen on reboot.

Jeff

[Jeff Hatch]

Mikael,

For key authentication I believe that the lines you inserted are the defaults. If you inserted the lines you as you have displayed them in this thread, they are commented out and would have no affect anyway.

Jeff

[Jeff Hatch]

Massimiliano,

To move forward with this please create a Support Portal case at https://support.multitech.com/

Jeff

[Jeff Hatch]

Massimiliano,

In early Q1 2018 we will be releasing AEP 1.5.0. Among other things, Node-RED has been upgraded to version 0.15.3 which is the last version that supports the AEP Conduit’s CPU architecture (instruction set).

Jeff

[Jeff Hatch]

Florian,

Unfortunately other priorities delayed this release. It should be getting released in early Q1.

Sorry for the inconvenience,

Jeff

[Jeff Hatch]

Massimiliano,

Do you mean upgrade Node-RED to a newer version? Which version of Conduit are you running, and what version of Node-RED does it have?

Jeff

[Jeff Hatch]

Boyko,

Is Node-RED enabled when you log into the Web UI and look under Apps->Node-RED Apps?

Jeff

[Jeff Hatch]

Jonathan,

Did you upgrade from a previous version of firmware to 1.4.3 or did you get the Conduit with 1.4.3 installed? I have not been able to reproduce this issue. Neither has our test team which has tested this feature.

Jeff

[Jeff Hatch]

Kevin,

Please open a support portal case at https://support.multitech.com/ and they can help you upgrade to AEP.

Jeff

[Jeff Hatch]

Elina,

Is your Conduit on the same link as your PC or do you have the Conduit directly connected to your PC with an Ethernet cable? Can you ping your PC from the Conduit? Is it possible that there is another device, possibly a router, on the same network as the Conduit with 192.168.2.1 as its IP?

Jeff

[Jeff Hatch]

Elina,

The “Sending discover…” stuff is a part of a feature called “Call Home”. If your Conduit Ethernet interface is attached to a network with DHCP it will have gotten an address from the DHCP server. If it is not connected to a network with DHCP the default IP (192.168.2.1) will be set on the Ethernet interface.

To determine the IP address assigned by the DHCP server connect to the micro serial connection on the back of the Conduit,log in with the default credentials (admin/admin) and run the ifconfig command. It will list the eth0 IP that you will need to use to web into the Conduit.

Jeff

[Author]

Posts