Problem installing iotkit-agent

[Tuan_B_Intel]

I'm trying to install iotkit-agent on my Galileo but ran into a problem with some SSL certificate issues.

Here's the error message when I try to run iotkit-agent/setup-agent.sh. Any idea how to get around this.

============================================
 IoT Kit Agent - Setup
============================================
copying startup script
forever:
   installing ...
./setup-agent.sh: line 33: sudo: command not found
npm http GET https://registry.npmjs.org/mqtt
npm http GET https://registry.npmjs.org/getmac
npm http GET https://registry.npmjs.org/winston
npm http GET https://registry.npmjs.org/express
npm ERR! Error: SSL Error: CERT_NOT_YET_VALID
npm ERR!     at ClientRequest.<anonymous> (/usr/lib/node_modules/npm/node_modules/request/main.js:525:26)
npm ERR!     at ClientRequest.g (events.js:192:14)
npm ERR!     at ClientRequest.EventEmitter.emit (events.js:96:17)
npm ERR!     at HTTPParser.parserOnIncomingClient (http.js:1544:7)
npm ERR!     at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:111:23)
npm ERR!     at CleartextStream.socketOnData (http.js:1447:20)
npm ERR!     at CleartextStream.CryptoStream._push (tls.js:544:27)
npm ERR!     at SecurePair.cycle (tls.js:898:20)
npm ERR!     at EncryptedStream.CryptoStream.write (tls.js:285:13)
npm ERR!     at Socket.ondata (stream.js:38:26)
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>

npm ERR! System Linux 3.8.7-yocto-standard
npm ERR! command "/usr/bin/node" "/usr/bin/npm" "install"
npm ERR! cwd /home/root/iotkit-agent
npm ERR! node -v v0.8.18
npm ERR! npm -v 1.2.2
npm ERR! code ESSL
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /home/root/iotkit-agent/npm-debug.log
npm ERR! not ok code 0
done

[Brendan_L_Intel]

iotkit-agent is already installed & launched (if you the iotdk images). But if you want to use the latest from git (from the log you have it doesn't look it it) you should be able to run it but make sure to kill the existing one first.

This looks like a npm issue though, maybe the first thing to do would be getting to an unrestricted internet access point, there may just be a proxy or something interfering :/

[Tuan_B_Intel]

I'm not behind any firewall when I tried this. This is the original image I have been running my Galileo since I got it.

[Brendan_L_Intel]

Then you're in the wrong forum ;-) the iotdk images are here : http://iotdk.intel.com/images/1.0/iot-devkit-201402201605-mmcblkp0.direct.bz2

If you're on an original image (probably earlier than 0.7.5) then you'll need to start by updating node. But I haven't tried it myself so can't really help there.

[Tuan_B_Intel]

So, I went and download the iotdev image to try out iotdev-agent.

When I try to get my N6235 WiFi card up, I get the following error message:

ifconfig: SIOCSIFFLAGS: Operation not possible due to RF-kill

When I tried 'rfkill unblock all', the wireless software go into an infinite loop of authenticate, then de-authenticate on my WiFi access point.

Does the iotdevkit image support WiFi? I'd hate to go into my closet to connect to the ethernet port on my router.

[Brendan_L_Intel]

Yes it does but we have an issue with connman. You need to kill it, then remove the init script (to make sure :)) and then it should work as normal. Make sure to use the nl80211 and not the wext driver with wpa_supplicant.

Hopefully we'll do a package update to fix this and also provide an updated image soon.

[Tom_B_Intel]

I have the exact same problem.  Seems that the date on the Galileo is what is at issue.  It defaults on boot to something like "Jan 01 2001".

This caused the node package manager to fail on certificate validation.

Easy fix is to adjust the date with:

# date 201403261645.5

where YYYYMMDDHHMM.SS is the format for that killer number.  Pretty obscure, if you're not a embedded guy.

Additionally - if you want the result of the command "date" to return the value in your timezone, then you'll need to add this to a file in your ~ directory.

1.) create a file in your ~ directory called .profile

2.) add two lines to this file:

TZ = 'PST8PDT'
export TZ

where you adjust the PST8PDT to your timezone.  PST = Pacific Standard Time, PDT = Pacific Daylight savings Time and the number between these two is the offset from UTC.

Hope that helps others - took me a long time to figure that one out...

[Brendan_L_Intel]

Tom B. wrote:
I have the exact same problem.  Seems that the date on the Galileo is what is at issue.  It defaults on boot to something like "Jan 01 2001".

We have a deeper explanation of the issue & fix here: http://software.intel.com/en-us/forums/topic/507062#comment-1782611

[EngKean_L_Intel]

Brendan Le Foll (Intel) wrote:

Yes it does but we have an issue with connman. You need to kill it, then remove the init script (to make sure :)) and then it should work as normal. Make sure to use the nl80211 and not the wext driver with wpa_supplicant.

Hopefully we'll do a package update to fix this and also provide an updated image soon.

Would you elaborate more about how to workaround this?

Kill by "rfkill block 0"? And which script file to be removed?

I am using Intel Centrino Wireless-N 135. Is this wifi module supported?

Thanks.

[Brendan_L_Intel]

Eng Kean Lee (Intel) wrote:

Would you elaborate more about how to workaround this?

Kill by "rfkill block 0"? And which script file to be removed?

I am using Intel Centrino Wireless-N 135. Is this wifi module supported?

I don't have and old image around so I can't tell you exactly which init script, but it's the one starting connman, I think it's /etc/init.d/connman. You need to stop rfkill blocking the wifi module, and then disable connman, then killall connmand. Alternatively install conman-client from the repo and use conmanctl to connect to your wifi network.

rfkill unblock 0
rm /etc/init.d/connman

We support the Intel 135 wifi module (just do iwconfig) and you should see it.

[EngKean_L_Intel]

Instead of removing the init script, I use another method by kill -9 "connman's process id", and then rfkill unblock 0.

thanks.

[Brendan_L_Intel]

Eng Kean Lee (Intel) wrote:
Instead of removing the init script, I use another method by kill -9 "connman's process id", and then rfkill unblock 0.

I'd always advise against a 'kill -9', 'killall' is present and will do a cleaner job. When doing this be careful connman doesn't come back on reboot or if using systemd just because systemd helpfully restarts it :) In this case '/etc/init.d/connman stop' would be the best option for a temporary shutdown.