Month: August 2018

Some rework had to be done
Brett sent me answers on what to do about SSL 1.x.x, and the problem I had with one of the sample programs: SSL 1.0.x has been staticly linked into the shareable image, so linking against that file (libmqttv3c$shr.exe) instead of the object library (libmqttv3c.olb) would solve the problem.
He also added a somewhat reworked version of paho_c_pub.c, I had to do some re-editing to solve issues that were the result of retrieving this source from the message and store it in my (WIN10) workstation, and moving is (ASCII) to the VMS box. But once these were addressed, the program starts and runs.

Next issue was to figure out how to pass a message from the VMS box to the application on my mobile….
First do it the easy way:


So there the commands and results are:
$ pub :== $DKA0:[MQTT.PAHO.EXAMPLES]PAHO_C_PUB.EXE
$ pub test --clientid (Name on Mobile) --username (username) --password (password)
Using topic test
Connecting

Connected
redo


Any test that is now entered, will show up in MQTT Dashboard in this client, under topic “test”

Backlink has to be done – will be (I guess) paho_c_sub.c; Same setup for subject, it will show all that is sent – together with subject – until cancelled – it will listen to any topic (due to wildcard “+”):

$ sub :== $DKA0:[MQTT.PAHO.EXAMPLES]PAHO_C_SUB.EXE
$ sub + --clientid (Name on Mobile) --username (username) --password (password)
Subscribing to topic + with client (clientid) at QoS 2
test redo
Oktest redo
Oktest redo
Oktest Done

These messages show up in the subcsscription area in MQTTDashboard as well – obvious, since I’m listening to any subject 🙂
I also added –delimiter \n to add delimiter beyond, but that does not work the way I anticipated. But is newline is included in the message it will show up in output:

$ sub + --clientid (Name on Mobile) --username (username) --password (password) --delimiter \n
topic is +
Subscribing to topic + with client htc at QoS 2
test Done \test Done
\test With crlf


But that is possibly a matter of understanding on how to read the documentation, it might well be the way it should work.

If sub is started without clientid,

sub + --username (username) --password (password)
topic is +
Subscribing to topic + with client stdout-subscriber-async at QoS 2

messages from my mobile are not accepted. Which is fine for what I’m planning to use it for.

Now the first hurdles have been taken: Connection works both ways and I have a fair impression on how the use it both ways. Next is creating API-calls (that Brett already started to do) and use these.

Paho reinstalled
I have overlooked a few things: I installed the previous version (that process removes what’s on the system…) and checked the contents of the object libraries in that version; but what is in the latest version was already saved – and the new lobrraies contain the same routines.
Re-installed the latest version of Paho (1.2) and rebuilt the samples using the supplied procedure – which may be different from the 1.o version.
Now all but two images can be compiles; the programs that run in an SSL environment compile but link fails.

$ link/threads paho_cs_pub.obj,paho$root:[lib]libmqttv3cs.olb/lib,sys$input/opt
sys$library:ssl1$libssl_shr32.exe/share
sys$library:ssl1$libcrypto_shr32.exe/share

stating that sys$library:ssl1$libssl_shr32.exe/share cannot be found.
Of course not: I have no support contract with HPE an d so I cannot update my system anymore…

So I used the old files instead, which gives me undefines symbols:

$ link/threads paho_cs_sub.obj,paho$root:[lib]libmqttv3cs.olb/lib,sys$input/opt
sys$library:ssl$libssl_shr32.exe/share
sys$library:ssl$libcrypto_shr32.exe/share
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         CRYPTO_THREADID_SET_CALLBACK
%LINK-I-UDFSYM,         CRYPTO_THREADID_SET_NUMERIC
%LINK-W-USEUNDEF, undefined symbol CRYPTO_THREADID_SET_NUMERIC referenced
        in psect $LINK$ offset %X000007E0
        in module SSLSocket file PAHO$ROOT:[lib]libmqttv3cs.olb;1 %LINK-W-USEUNDEF, undefined symbol CRYPTO_THREADID_SET_CALLBACK referenced
        in psect $LINK$ offset %X00000890
        in module SSLSocket file PAHO$ROOT:[lib]libmqttv3cs.olb;1
This is not a big issue – as long as the programs that do not require encrypted communication can be build. And that is Ok.

So I started the publication program:

$ sho symb pub
PUB = "$DISK$DAPHNE084:[MQTT.PAHO.EXAMPLES]PAHO_C_PUB.EXE"
$ pub test --clientid ExampleClientPub
Using topic test
Connecting
Failed to start connect, return code -13
$

It might be that I need to add credentials:

$ pub test --clientid ExampleClientPub --username (username) --password (password)

but that gives the same result

Checked the log (after I enabled logging of connections) it shows a warning – which may point the cause:

$ type dka0:[mqtt.mosquitto.logs]MOSQUITTO.LOG
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
$
$ mosquitto :== $mosquitto$root:[bin]mosquitto.exe
$ mosquitto "-c" mosquitto$root:[conf]mosquitto.conf
1533837960: mosquitto version 1.4.14 (build date 29-MAR-2018 02:52:02.10) starting
1533837960: Config loaded from mosquitto$root:[conf]mosquitto.conf.
1533837960: Opening ipv4 listen socket on port 1883.
1533837960: Opening ipv4 listen socket on port 1883.
1533837960: Warning: protocol wrong type for socket

I did some more investigation – the subscriber program does connect – but wont’t show a result when a message is posted from the mobile phone (using MQTT Dashboard):

$ sho sym sub
SUB = "$DISK$DAPHNE084:[MQTT.PAHO.EXAMPLES]PAHO_C_SUB.EXE"
$ sub ExampleClientsub --username (username) --password (password)

and it will wait until cancelled)

log shows it all: Connection failures and successes:

1533841611: New connection from 82.161.236.244 on port 1883.
1533841611: New client connected from 82.161.236.244 as ExampleClientPub1533841611246 (c1, k60, u'Willem ').
1533841630: New connection from 82.161.236.244 on port 1883.
1533841630: New client connected from 82.161.236.244 as ExampleClientSub1533841630615 (c1, k60, u'Willem ').
1533841655: New connection from 127.0.0.1 on port 1883.
1533841655: New client connected from 127.0.0.1 as stdout-subscriber-async (c1, k10, u'willem').
1533841708: Client stdout-subscriber-async disconnected.
1533841713: New connection from 127.0.0.1 on port 1883.
1533841713: New client connected from 127.0.0.1 as stdout-subscriber-async (c1, k10, u'willem').
1533841749: Client stdout-subscriber-async disconnected.
1533841888: Client ExampleClientPub1533841611246 has exceeded timeout, disconnecting.
1533841888: Socket error on client ExampleClientPub1533841611246, disconnecting.
1533841892: Client ExampleClientSub1533841630615 has exceeded timeout, disconnecting.
1533841892: Socket error on client ExampleClientSub1533841630615, disconnecting.
1533841948: New connection from 127.0.0.1 on port 1883.
1533841948: New client connected from 127.0.0.1 as stdout-subscriber-async (c1, k10, u'willem').
1533841956: Client stdout-subscriber-async disconnected.
1533841962: New connection from 127.0.0.1 on port 1883.
1533841962: New client connected from 127.0.0.1 as stdout-subscriber-async (c1, k10, u'willem').
1533841966: Client stdout-subscriber-async disconnected.

(connectios on address 82.161.236.244 are from my mobile, 127.0.0.1 is from my VMS development system)

and in TCPIP I see both connections when starting the reader (sub):

TCPIP> sho dev

…
  bg581       STREAM    1883       0                   *
  bg678       STREAM   49159    1883                   127.0.0.1
  bg679       STREAM    1883   49159                   127.0.0.1
…


I tried to compile and link the publisher program – but the problem is within the MQTT library which has no debug information, nor do I have the Mosquitto code with the package, so some assistance of Brett Cameron is required.