Jeff Hatch

Forum Replies Created

Viewing 22 posts - 601 through 622 (of 622 total)
  • Author
    Posts
  • in reply to: Problems connecting to AEP Conduit #10520
    Jeff Hatch
    Keymaster

    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

    in reply to: accessing nodeRED 'http in' nodes using http (not https) #10499
    Jeff Hatch
    Keymaster

    Brian,

    What type of flow are you running, what nodes? Also, in the upcoming 1.1.x AEP release Node-RED has been upgraded to version 11.1, and node-js to version 10.40 (farthest we could go with the processor). My experience with this upgrade has been a lot more stability and better performance.

    Jeff Hatch

    in reply to: Connection refused after auto-flash #10494
    Jeff Hatch
    Keymaster

    Tom,

    File an issue in the MultiTech Portal with support. It looks like there are probably some hardware issues with that unit. Filing the issue will get you started in the process to get a replacement.

    Jeff

    in reply to: accessing nodeRED 'http in' nodes using http (not https) #10493
    Jeff Hatch
    Keymaster

    Brian,

    As Lawrence says, on a typical Node-RED installation you would use the settings.js to specify this type of configuration information. There is currently discussion to create a solution to this problem on the Conduit. It is hoped that there will be a solution implemented and released towards the end of Q1 2016. That this happens by that time is dependent on other priorities and project work.

    There is a chance that you could create your own file with the necessary configuration, read it in with a file node, and process the data with a function node. Once again, in this case you will need to be aware of the firmware upgrade, and keep the file in /var/config where it will persist.

    Jeff

    in reply to: Connection refused after auto-flash #10471
    Jeff Hatch
    Keymaster

    Tom,

    One possibility is that the rootfs file got corrupted on download. Did you run an md5 and check the hash against whats in the md5sums.txt? There have been observed instances where the rootfs file got corrupted, but it still “installed”, and significant portions of the file system were missing. If the file appears to be correct then you could try to re-flash the unit.

    Jeff

    in reply to: Connection refused after auto-flash #10436
    Jeff Hatch
    Keymaster

    Tom,

    The interface information looks good. Since there were no established listens from the “netstat -na” it appears that sshd is not getting started for some reason. You can verify this with a “ps -auxww | grep ssh”. On the mLinux model you should be able to do an “/etc/init.d/sshd restart” if sshd is not running or to restart it. If that does not get sshd up and running check /var/log/messages and hopefully it logs something. If it is not running you could try running sshd by hand at the command line with the “-d” option to find out why it is not coming up. The debug options range from -d -d1, -d2 to -d3, with increased verbosity.

    Jeff

    in reply to: Connection refused after auto-flash #10433
    Jeff Hatch
    Keymaster

    Tom,

    Any chance now that you have the debug console hooked up that you can capture the console output when the unit reboots? It’s possible that related errors might come out in that output. Also, take a look in /var/log/messages and see if there are any networking related errors.

    One last thing to make sure that the ethernet interface is up, could you do an “ifconfig -a” and make sure that the eth0 interface is up and has the correct address?

    Jeff

    in reply to: Connection refused after auto-flash #10430
    Jeff Hatch
    Keymaster

    Tom,

    It looks like you have networking. The “No such file or directory” errors are for IPv6 stuff. I have the same output from “netstat” on my Conduit. I was hoping to see output from “netstat -na” that will tell us what ports listens are on. In addition to the output you already generated there will be additional listings at the top like:

    admin@mtcdt:/var/config# netstat -na
    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       
    tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      
    tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      
    tcp        0      0 0.0.0.0:1880            0.0.0.0:*               LISTEN      
    tcp        0      0 127.0.0.1:1881          0.0.0.0:*               LISTEN      
    tcp        0      0 127.0.0.1:1882          0.0.0.0:*               LISTEN      
    tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      
    tcp        0      0 127.0.0.1:1883          0.0.0.0:*               LISTEN      
    tcp        0      0 192.168.2.1:22          192.168.2.200:49724     ESTABLISHED 
    tcp        0      0 127.0.0.1:1883          127.0.0.1:60482         ESTABLISHED 
    tcp        0      0 127.0.0.1:45297         127.0.0.1:9000          TIME_WAIT   
    tcp        0      0 127.0.0.1:60482         127.0.0.1:1883          ESTABLISHED 
    tcp        0      0 127.0.0.1:43899         127.0.0.1:80            TIME_WAIT  

    Thanks,

    Jeff

    in reply to: Connection refused after auto-flash #10428
    Jeff Hatch
    Keymaster

    Tom,

    Could you make sure that ssh is running with a ps, and get the output of the “netstat -na” command if you can? Connection refused errors usually mean that nothing is listening on port 22.

    You will probably also need to define a gateway in the /etc/network/interfaces if you are going to connect from a different subnet than 192.168.2.x.

    in reply to: Running openVPN client on Conduit? #10208
    Jeff Hatch
    Keymaster

    Brian,

    One more important thing to note:

    Before you upgrade the Conduit firmware, make sure to save your openVPN configuration off the Conduit. You will have to re-install openVPN and reconfigure it after a firmware upgrade as the firmware upgrade for AEP re-flashes the entire FS.

    This may change in the future, but for now that is the way it is.

    Jeff Hatch

    in reply to: Running openVPN client on Conduit? #10204
    Jeff Hatch
    Keymaster

    Brian,

    I do not see anything in particular preventing you from doing this. I’m assuming that this is an AEP Conduit, so installing openVPN may be a little trickier that our mLinux Conduit, but it is probably still doable.

    The VPN connection will be initiated by the Conduit via the ppp interface, correct? I have never done much analysis on what the additional bandwidth the VPN would use, so you might also want to factor that into your data usage. There may be very little difference, though, between HTTPS and the VPN. In fact a long running VPN connection might have lower bandwidth requirements than a bunch of HTTPS sessions.

    The big trick will be getting the OpenVPN installed and working.

    Jeff

    in reply to: mLinux FTP #10173
    Jeff Hatch
    Keymaster

    Guus,

    Have you tried using scp? The ssh daemon is installed and already configured. The scp utility is available and much more secure than using FTP.

    Jeff

    in reply to: Configuring conduit through GPRS/3G #10105
    Jeff Hatch
    Keymaster

    Lorenzo,

    Have you followed the Getting Started With AEP steps outlined here?

    There could be many reasons that you cannot access the Web UI through the Cellular interface. It would be easier to set up the access through the ethernet LAN first.

    Jeff

    in reply to: Connecting to Node RED #10048
    Jeff Hatch
    Keymaster

    Jim,

    When I restart node-red I get similar errors, but not the same pertaining to the stunnel proxy not being able to connect on the localhost port:

    Nov 18 21:36:16 mtcdt daemon.info stunnel: LOG6[65]: SSL accepted: previous session reused
    Nov 18 21:36:16 mtcdt daemon.info stunnel: LOG6[65]: s_connect: connecting 127.0.0.1:1881
    Nov 18 21:36:16 mtcdt daemon.err stunnel: LOG3[65]: s_connect: connect 127.0.0.1:1881: Connection refused (111)
    Nov 18 21:36:16 mtcdt daemon.info stunnel: LOG6[65]: s_connect: connecting 127.0.0.1:1882
    Nov 18 21:36:16 mtcdt daemon.info stunnel: LOG6[66]: SSL accepted: previous session reused
    Nov 18 21:36:16 mtcdt daemon.info stunnel: LOG6[66]: s_connect: connecting 127.0.0.1:1881
    Nov 18 21:36:16 mtcdt daemon.err stunnel: LOG3[66]: s_connect: connect 127.0.0.1:1881: Connection refused (111)
    

    It almost seems like the connecting host is dropping the connection according to the log. Have you tried logging in from a different host or different browser?

    Jeff

    in reply to: IPTables Rules #10036
    Jeff Hatch
    Keymaster

    Jonathan,

    From the firmware version you stated, I am led to believe that you have an AEP Conduit. The 1.0.33 is the version of the latest AEP to be released. To enable ICMP responses on the AEP model and make that configuration persists you need to log in with the UI, go to the Access Configuration page. Then, under ICMP, check the enable box and check the “Via LAN” and/or “Via WAN” boxes depending if you want both LAN and WAN ping responses or not.

    There is an “Advanced Settings” option on the Firewall->Settings page that will also give you much more IPTable “flexibility” with the rules you can create without having to go to the SSH command line.

    Hope that helps,

    Jeff Hatch

    in reply to: Connecting to Node RED #10035
    Jeff Hatch
    Keymaster

    Jim,

    There are a couple of things to look for initially, one is to open the developer tools in the browser and look at the console output for errors. This may give you an idea of what is going on with the Node-RED connection when it is lost.

    Another thing to check is to see if Node-RED is restarting. One way to do this would be to log into the Conduit via SSH and run a “ps auxww | grep node” before you try to connect and after you receive the error to check if the node-red PID has changed indicating that it has restarted.

    Jeff Hatch

    in reply to: I can receive SMS messages but I can not send SMS messages #10034
    Jeff Hatch
    Keymaster

    Furrukh,

    Everything that you have sent looks fine. I do not think that we have tested this radio with a Net-10 SIM, especially with a dual. Since you can receive, you should be able to send.

    One place to look to see if the messages actually got to the Conduit is to look in /var/conf/sms/inbox, and see if there are any messages in there. To get to that directory either log in via ssh to the Conduit or log in at the debug console.

    Jeff Hatch

    in reply to: IPTables Rules #10014
    Jeff Hatch
    Keymaster

    Jonathan,

    Which version of Conduit do you have (AEP or mLinux)? The AEP Conduit has a number of configuration items in the Web UI including HTTPS access for the UI, SSH access, response to ICMP Pings, etc. If it is the mLinux version, you will have to deal directly with IPTables itself.

    On the AEP version I am sorry to say that the documentation for the firewall functionality is sparse, though it is essentially a simplified front-end for IPTables. This help has been enhanced for an upcoming release.

    Jeff Hatch

    in reply to: Conduit no longer responding serial login on device port #9886
    Jeff Hatch
    Keymaster

    Depending on which terminal program you are using, you can import the script and run it through your terminal program. If you don’t have something like minicom that supports this, then you can revert to cut and pasting the setenv commands in the script.

    For example, in minicom you can do a CTRL-A Z, G and point minicom to the script you want to run at the prompt in the menu.

    Jeff

    in reply to: Conduit no longer responding serial login on device port #9877
    Jeff Hatch
    Keymaster

    Jonathan,

    Have you tried entering the runlevel at the prompt? Run level 5 is a common level for most things to run in normal configuration. If that does not work you may be required to re-flash the device from the boot loader. It appears that your inittab got corrupted or removed somehow.

    Jeff Hatch

    Jeff Hatch
    Keymaster

    Lawrence,

    Could you please try to keep me in the loop on this feature request, maybe post what identifying information you get for the request? I am currently working on a list of features for upcoming releases.

    Thank You,

    Jeff Hatch

    in reply to: Registering device on DeviceHQ #8702
    Jeff Hatch
    Keymaster

    Andrew,

    Could you send your UUID to me Jeff.Hatch@multitech.com, and I will work with the Device HQ team to see if that it is in the database so that you can register it. It is probably missing from the database on the beta server.

    Thank You,

    Jeff Hatch

Viewing 22 posts - 601 through 622 (of 622 total)