Problems connecting to AEP Conduit

[Eduardo Garcia]

Hello:

I am trying to connect to my Multiconnect Conduit by following the “Getting Started” guide. I try to go to ‘192.168.2.1’ but the page does not load!
I can SSH using Cygwin into the Conduit and using the password ‘Root’ get into it, but I am unsure of what to to with this. I would like to use the web interface.

Thank you for your time,

-Ed

[Darrik Spaude]

Hi Ed,

Which model do you have? The AEP model has a web interface, but the mLinux model does not. The AEP model includes “210A” in the model name while the mLinux model includes “210L” in the model name.

Best Regards,
Darrik

[Eduardo Garcia]

Hi Darrik:

You are completely right! Mine is 210L, I did not notice. Is there a way to change the firmware to AEP, or should I look into changing hardware?

Thank you for your fast reply!

-Ed

[Darrik Spaude]

If you are planning on using DeviceHQ, then you should consider the 210A model instead. If not, then consider creating a support case at https://support.multitech.com/ (use the same MultiTech ID at the Support Portal as here on multitech.net).

Best Regards,
Darrik

[Michael Selzler]

I am unable to access the AEP interface; the browser times out attempting to pull up the login page. I’ve followed the “Getting Started with AEP” including installing a Mini SIM card (which was not included with the Conduit). The status LED is blinking twice with a short pause, then repeating. My conduit is a “201A” type model. Any suggestions would be greatly appreciated.
Thanks,
Mike

[Jeff Hatch]

Michael,

There is a debug port that you can connect to behind the plate with the MutiTech logo on it. That port is connected to the Linux console output, and can be logged into with admin/admin. Make sure that the output before the login prompt says mentions AEP. That would be the first step to make sure that the correct firmware has been installed.

If you have the correct firmware, you should be able to get to /var/log/messages and see if there are any errors when you try to login.

I’m assuming that you are trying to get to the UI through the ethernet interface on 192.168.2.1.

Jeff Hatch

[Michael Selzler]

Jeff,

Via the debug port I’m able to capture a lot of startup information which for the most part looks okay (unless I’m missing something). The message file also contains nothing obvious to me. I could send the captured text file, but it is over 1200 lines of text. Here is something that I do see being repeated:

mtcdt login: udhcpc (v1.22.1) started
Sending discover…
Sending discover…
Sending discover…
Usage: /etc/udhcpc.d/lanup {bound|renew|deconfig}
run-parts: /etc/udhcpc.d/lanup exited with code 1
No lease, failing

I also saw this:

Reading accessory cards data
jffs2: notice: (168) check_node_data: wrong data CRC in data node at 0x0a2e5ee8: read 0x206ce7ab,
calculated 0xa43b2c4.
Adding accessory cards data

Yes, I’m attempting to access the UI via the http://192.168.2.1.

Thanks for your help!
Mike

[Jeff Hatch]

Michael,

The udhcpc stuff you’re seeing in the logs may be related to your problem. That functionality is part of our proportioning features that communicate with our DeviceHQ server. It is automatically enabled, but you can disable it by editing the /var/config/db.json file and changing the following from:

“firstTimeSetup” : true,

to:

“firstTimeSetup” : false,

When you make that change, reset the device.

The “call home” feature may be causing delays when you are trying to connect to the Conduit because it is taking over the ethernet interface trying to get an address from a DHCP server. I have never seen that feature completely prevent connection though.

Jeff

[Neil MacMullen]

I have had very similar problems. In my case, the issue appears to be that the conduit managed to assign itself the same IP address as my router (I checked this with ‘ifconfig -a’ via the usb debug interface mentioned above). At that point, no amount of fiddling with the dhcp and other ip parameters in db.json was able to get the system back to a sensible state; I tried turning off dhcp and setting a fixed ip address (see http://www.multitech.com/manuals/s000576_1.0.pdf, search for “fixedaddresses”) but this didn’t help.

The only resolution I could find was to set “firstTimeSetup” back to true which seems to have forced some additional configuration on the next reboot. I think Jeff’s advice above may be misleading – my observation is that ‘firsttimesetup’ is a transient flag which is automatically cleared on reboot.

It’s interesting that I couldn’t see any traffic via wireshark (filtered to conduit mac address rather than ip address) when the conduit was in this state despite the fact that ifconfig claimed a few packets had been sent.

[Jeff Hatch]

Michael and Neil,

When you manually change the firstTimeSetup you need to reset the device without saving and restarting from the Web UI or alternatively restart the Web server (lighttpd) before rebooting. The firstTimeSetup flag is being cached in the instance of the API on the Conduit, and may be a part of the “transient” behavior you are seeing. If you restart from the UI doing a “Save and Restart” your manual change will get overwritten with whatever was cached in the API.

Neil, what address did the Conduit assign itself? Part of what can cause confusion here is that the DHCP server and client are enabled by default when you first power up. If the Conduit got an address other than 192.168.2.1, it was not the Conduit that assigned the address to that interface. On the other hand, if it did not successfully get an address and it was still the default, you need to connect to the Conduit directly from a PC and assign a static IP before connecting your Conduit to another network. You need to be directly connected to the Conduit when you do this.

The whole reason for Conduit defaulting to 192.168.2.1 revolves around the idea that the Conduit is going to be a gateway device either for LoRa or Ethernet and us Cellular as a back haul. At least that was the original thinking behind the design. As Conduit gets used for different applications things like this behavior may “evolve” differently.

Jeff

[Neil MacMullen]

Jeff,
I set ‘firstTimeSetup’ to true by editing db.json using VI via teraterm. I saved the file and then reopened it to verify that I had made the change correctly. I then issued the ‘reboot’ command via teraterm. After rebooting, I logged back in and examined db.json and observed that ‘firstTimeSetup’ had been set back to false. Remember I had no access to the web UI since I couldn’t get it to assign itself a useful IP address! 😉

>what address did the Conduit assign itself

When I received the conduit from a colleague, it had already been configured to use DHCP and it managed to grab a sensible IP address from the router. It was only later that it got into this state.

My router is 192.168.99.1 and that is also the IP address that the conduit managed to grab (NOT 192.168.2.1). My best theory about how it got into the incorrect state is that it didn’t have visibility of the router when it was rebooted. (The conduit is plugged into a Wi-Fi capable switch which then connected via a rather flaky Wi-Fi link to the router.) At that point it may have remembered that the previous gateway was 192.168.99.1 and claimed this address since no other device appeared to be using it or it might possibly have seen one of the other devices on the switch with a 192.168.99.x address and decided that was an appropriate address range to use.

[Jeff Hatch]

Neil,

Is the router also the DHCP server? If not, then I think that your hypothesis likely explains how the Conduit got the address it did. The only way that the Conduit obtains an address dynamically on the Ethernet interface is through the DHCP client (in this case most likely through the call home functionality for remote provisioning that is enabled by the firstTimeSetup flag). The Conduit must have gotten the 192.168.99.1 address via DHCP.

As for the firstTimeSetup behavior, I will see if I have time today to experiment with that scenario. What you’ve reported is not what I would expect.

Jeff

[Neil MacMullen]

Thanks Jeff,
Yes, the router is the DHCP server but I think it highly unlikely it would have served its own address to a client! That leaves the question of how the conduit got that address. The network topology is….

Internet  ---- Router (DHCP server) <--- Wi-Fi link ---> Switch +---- Windows PC
                                                                +----Conduit

I’m almost certain that the switch I’m using does not have DHCP server capability and the Windows PC is also not set up to do this.

Now that the system is working I’m a bit reluctant to deliberately break it again but I may try some more experiments to see if I can reproduce the problem. Unfortunately though I’m unable to sniff the raw Ethernet traffic from the conduit so I only have limited visibility of what’s going on.

[Jeff Hatch]

Neil,

If you have a chance, take a look at the configured range of addresses that the DHCP server on the Conduit was set to give out. Maybe the 192.168.99.1 address was given out by that.

Jeff

[Author]

Posts