Cannot connect to DeviceHQ when running firmware 5.x

[info@mockingbirdconsulting.co.uk]

Hey all,

I’m hitting an error when trying to configure an AEP Conduit to talk to DeviceHQ. All it does is print “failed to send USR1 to annexcd”.

I’m running firmware version 5.0.0-AEP, however when I log into the box via SSH and run /sbin/monitor-annexcd it refuses to start and just throws the “help” function at me.

Having gone through this and debugged it, I *think* that the issue is a missing –vendor-id flag in the command, however I can’t see from the Web UI what this value might need to be.

Can anyone help with this?

[Jeff Hatch]

Below is the ps output for the annexcd command line arguments on a Conduit that is successfully checking into devicehq.

root@mtcdt:/var/config/home/admin# ps auxww | grep annexcd
root 4745 0.0 0.6 2704 1540 ? S 13:17 0:00 /bin/bash /sbin/monitor-annexcd
root 4796 0.5 2.6 33068 6784 ? Sl 13:17 0:01 annexcd –account-key XXXXXXXX-xxxx-XXXX-xxxx-XXXXXXXXXXXX –host ds.devicehq.com –port 5798 –product-id MTCDT-LAT3-240L –device-id 12345678 –rpd-interval 43200000 –gps-interval 43200000 –net-interval 43200000 –cell-interval 43200000 –active-apps-interval 43200000 –lora-interval 43200000 –when-ppp-up on –firmware-upgrade true –config-upgrade true –config-upload false –radio-firmware-upgrade true –ssl-method tls –ssl-ca-certificate /etc/ssl/certs/rootCA.pem –ssl-ca-strict –log-upto 7 –dial-on-demand false
root 6163 0.0 0.4 3092 1096 pts/0 S+ 13:21 0:00 grep annexcd

The vendor-id argument is not required in this case. What are the messages from annexcd in /var/log/messages saying?

Jeff

[info@mockingbirdconsulting.co.uk]

Thanks.

In the logs, I’m getting

2019-09-09T14:33:38.704293+00:00 mtcdt annexcd: [ERR] main.cc:parse_command_line:382: expected 0 non-options

The full command that I am running is
annexcd –account-key <KEY> –host ds.devicehq.com –port 5798 –product-id MTCDT $ –device-id <DEVID> –rpd-interval 43200000 –gps-interval 43200000 –net-interval 43200000 –cell-interval 43200000 –active-apps-interval 43200000 –lora-interval 43200000 –when-ppp-up on –firmware-upgrade true –config-upgrade true –config-upload false –radio-firmware-upgrade true –ssl-method tls –ssl-ca-certificate /etc/ssl/certs/rootCA.pem –ssl-ca-strict –log-upto 7 –dial-on-demand false

• This reply was modified 4 years, 7 months ago by info@mockingbirdconsulting.co.uk.

[Jeff Hatch]

Does the value for the product-id really contain a ‘$’? That is very odd and possibly the problem for parsing the command line arguments by the daemon. I am not sure where that character would be coming from.

At the command line could you perform the following command:

AEP 1.7.x:
mts-id-eeprom –in-file /sys/devices/i2c.3/i2c-0/device/0-0056/eeprom

AEP 5.x:
mts-id-eeprom –in-file /sys/class/i2c-dev/i2c-0/device/0-0056/eeprom

This will show the contents of the eeprom where the product-id and other pertinent information is stored.

Jeff

[info@mockingbirdconsulting.co.uk]

I did think it was weird, but yup, it’s definitely there:

vendor-id: "Multi-Tech Systems"
product-id: "MTCDT	$"
device-id: "DEVID"
hw-version: "MTCDT	,0"
mac-addr: "00:08:00:00:00:00"
imei: "IMEI"
capa-gps: true
capa-din: false
capa-dout: false
capa-adc: false
capa-wifi: false
capa-bluetooth: false
capa-lora: false
capa: "\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
mac-bluetooth: "00:00:00:00:00:00"
mac-wifi: "00:00:00:00:00:00"
uuid: "A0800040000000000000000000000021"
lora-eui: "00:00:00:00:00:00:00:00"
lora-product-id: ""
lora-hw-version: ""

That MAC address looks off to me as well…

[info@mockingbirdconsulting.co.uk]

Is it worth my updating to 5.0.1?

[Jeff Hatch]

Is this some kind of sample device? Other than the vendor ID none of the values in the eeprom on that device look valid.

Updating to 5.0.1 without valid values in the EEPROM will not solve this problem.

Setting values in the EEPROM can be done, however, you will need to talk with customer support at support.multitech.com. To write the EEPROM you need to put a jumper on the board and then write the values using a command like the following example:

mts-id-eeprom –in-file /sys/class/i2c-dev/i2c-0/device/0-0056/eeprom –update –out-format bin –uuid

Jeff

[info@mockingbirdconsulting.co.uk]

Nope, this has come from one of the UK suppliers and is like this straight out of the box.

Not sure I fancy writing the EEPROM myself, one of the reasons for purchasing MultiTech instead of RAK etc. was that we wouldn’t have to worry about that kind of thing.

I’ll take it up with the supplier, thanks.

[Jeff Hatch]

Hmm. You can talk with the supplier, however, it would be a good idea to open a support case with support.multitech.com. Either the supplier did this, or there is an OEM problem of some kind. Whoever/whatever put that ‘$’ in the product-id is what I believe is causing this problem. The support engineers at Multitech can help you fix this, but someone needs to not be messing up the EEPROM values. I don’t think this EEPROM information was what was set in production out of the factory at Multitech.

It may be possible there is/was some kind of problem with the EEPROM. The Multitech support team can help you fix this and should be able to straighten out what is going on with the reseller.

Jeff

[Author]

Posts