Conduit seems lost

Home Forums Conduit: AEP Model Conduit seems lost

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #12305
    Michael
    Participant

    After successfully using the Conduit for a few weeks, I have been unable to connect to my Conduit – via various methods- for most of the day.

    Using an mDot (on a UDK) running both an AT-commands app, as well as variations on some sample programs, I’ve had it direct-connected to a PC via crossover with no problem (using the “Debug windo in NodeRed for visibility).
    Subsequently, it’s been connected to a small, switch-based, LAN to several PCs (one acting as a “console” and the other as a “cloud”). As part of that setup, the IP address was changed. Again, that configuration worked – data made it to the cloud.

    It was working, that is, until this morning at which time, while monkeying with my mDot code (online compiler) I was no longer able to get the mDot to “Join”. I reverted to the AT .bin and I could manually get it to join.

    During the midst of my debugging I tried to NodeRed into the Conduit and was no longer able to.  The AT bin will not allow the mDot to connect to the Conduit any longer.

    I unwired my LAN, etc. and connected the Conduit directly to a PC, but I have a seemingly unresponsive unit. I’ve tried resetting (short and long) but now I’m still stuck. (I do get a response via the USB but I don’t know what do there.)

    I’ve also reset the box several times, unplugged it for over a minute and re-powered it.

    What steps do you recommend?
    Did the long (hard) reset change the IP address the Conduit is running on back to its default – 192.168.2.1?

    -Mike

    • This topic was modified 8 years ago by Michael.
    • This topic was modified 8 years ago by Michael.
    #12310
    Bryan Tran
    Moderator

    Hi Michael,

    Q1: I unwired my LAN, etc. and connected the Conduit directly to a PC, but I have a seemingly unresponsive unit. I’ve tried resetting (short and long) but now I’m still stuck. (I do get a response via the USB but I don’t know what do there.)

    MTS: Can you plug in the USB cable into the USB debug port on the front of the Conduit. And then power off/on at the Conduit. Wait until you get a login prompt. Try to login with your credential and see if you are able to log in.

    http://www.multitech.net/developer/products/conduit/connecting-to-the-debug-interface/

    If you are able to login, please issue the following command to find out the current ip address of the Conduit.

    ifconfig

    Then type:

    /opt/lora/lora-network-server –version

    cat /var/config/lora/lora-network-server.conf

    On the mDot, type:

    ATI

    AT&V

    Post those output here for analysis.

    Q2: Did the long (hard) reset change the IP address the Conduit is running on back to its default – 192.168.2.1?

    MTS: Yes. It will reverted back to default – 192.168.2.1.

    It is a lot easier if you create a support case at – http://www.multitech.com/support for long trouble shooting.

    Thank you,

    BT

    #12311
    Bryan Tran
    Moderator

    Michael,

    That is a double dash with version.

    /opt/lora/lora-network-server –version

    Thanks,

    BT

    #12313
    Michael
    Participant

    BTW: The instructions on never mention at which point to power up the unit.

    #12314
    Michael
    Participant

    >> Wait until you get a login prompt. Try to login with your credential and see if you are able to log in.

    I never see a log-in prompt. Here’s what I get:

    Setting up User-Space Watchdog
    
         _        _____     ____
        / \      | ____|   |  _ \
       / _ \     |  _|     | |_) |
      / ___ \  _ | |___  _ |  __/_
     /_/   \_\(_)|_____|(_)|_|  (_)
    
    MultiTech Systems Application Execution Platform with mLinux GNU/Linux
    
    mLinux 3.1.0 mtcdt /dev/ttyS0
    
    Version: 1.1.2
    Date: 2016-01-13T09:59:04
    mtcdt login: path ends at json object.  increase depth or add --jsobj option
    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
    udhcpc (v1.22.1) started
    Sending discover...
    Sending discover...
    Sending discover...
    .
    .
    .

    The last few lines repeat over and over.

    • This reply was modified 8 years ago by Michael.
    • This reply was modified 8 years ago by Michael.
    #12317
    Jeff Hatch
    Keymaster

    Michael,

    If you hit enter when in the debug console does it give you a login or password prompt. You should be able to login at the debug console and get command line access. Your device has been defaulted back to factory settings. The “Sending discover…” output is the DHCP client trying to get an address. When it fails it reverts the address on the Ethernet interface back to 192.168.2.1. You should be able to connect to your Conduit by directly connecting it to a PC on 192.168.2.1 via SSH or the Web UI.

    If you cannot connect over either the Web UI or SSH, but can login to the debug console, we can help you debug what is going on.

    Jeff

    #12332
    Michael
    Participant

    OK, it’s wasn’t mentioned to hit enter. Besides, I had tried that, but the login opportunity vanishes quickly so I though it was not actually available.
    (IOW it goes into that “Sending discover…” mode as I mentioned)

    So…I pressed enter and got:

    mtcdt login:

    and typing admin for both the login and password (quickly!) I received back:

    admin@mtcdt:~#

    However, again, the “Sending discover…” mode starts up.
    Is that expected?

    (edit: OK, looks like you indicated that it is – even after logging in?)

    • This reply was modified 8 years ago by Michael.
    • This reply was modified 8 years ago by Michael.
    #12335
    Michael
    Participant

    It seems I am now able to get into the unit via Web UI (after getting all the admin credentials and IP stuff squared away) so I started “from scratch” with my experimentation.

    AT commands are OK now.
    Moving on to “real code”.

    Not sure what (but I think I know “who”!) got the unit so hosed up to start with.

    Thanks a lot.

    Mike

    #12336
    Jeff Hatch
    Keymaster

    Michael,

    Once you successfully logged in and got the “admin@mtcdt:~#” you are at the debug console prompt. The debug console logs everything coming out from the boot, and it also logs the output of the “call home” functionality that you are seeing doing the DHCP requests. In future versions we may prevent it from logging to the console.

    When you are logged in can you do a “ifconfig -a” and a “route -n” to show what address is on your Ethernet interface and to display what routing is available on the device? From that we can tell whether or not the device needs to be directly connected to or not.

    Jeff

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.