Re: [paho-dev] Please Try Out the MQTT-SN Gateway

[Paul Kierstead <paulkierstead@xxxxxxxxx>]

So, I tweaked TLS_client_method to be TLSv1_2_client_method and it compiles fine on the PI (but I presume this limits it to TLS1.2, which is fine by me...) and it #29 is working quite well on the PI. My previous complaints are all nicely addressed :)

Here is one thing that is sort of I think is only hinted at by the standard, which I implemented in previous gateway, but seems "open". Let say I power-cycle/etc the gateway. Now, the client keeps on going ... and sends a publish. The gateway ignores the client: "Not an active client". It would be really useful if the gateway sent back a DISCONNECT so that the client could immediately re-establish the connection.  Otherwise, a client sending QoS 0 messages doesn't know it is no longer connected and all the messages go to /dev/null. I think this is an oversight in the standard (or I've missed it.... I might have even known when I implemented  a gateway, but that was quite a while ago). Without it, QoS 0 is almost useless.

PK

On Sat, 1 Oct 2016 at 22:56 Paul Kierstead <paulkierstead@xxxxxxxxx> wrote:

Ah, well, might as answer my own question. Appears to be in OpenSSL v1.1, but ubuntu is at 1.0.2. Looks like it will have to be built from source ... I'll be betting that will take overnight on the pi :)

On Sat, 1 Oct 2016 at 22:47 Paul Kierstead <paulkierstead@xxxxxxxxx> wrote:

In #29 I'm getting

MQTTSNGateway/src/linux/Network.cpp: In member function ‘bool Network::connect(const char*, const char*, const char*, const char*, const char*, const char*)’:

MQTTSNGateway/src/linux/Network.cpp:299:40: error: ‘TLS_client_method’ was not declared in this scope

   _ctx = SSL_CTX_new(TLS_client_method());

This first appear in the "Update: indivisual client assigns TLS connection by clients.conf file." commit (2537dd76dd6a91d08162e925834f5d4af1626b91). Looking at https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html, it does appear there, but my ubuntu vm nor my pi could find it. I am using libssl-dev. What is the required version of OpenSSL (ok, I'm lazy here, I probably could poke around, but just in case someone else runs into it, I though I would ask)

PK

On Sat, 1 Oct 2016 at 01:35 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:

Hi All,

I found the serious bag of Que template. Que template can not queue elements, except only one.

This bug is already fixed and pull request #29 includes this fix. I hope this request will be merged soon.

Tomy Technology

Tomoaki  YAMAGUCHI

2016-09-25 23:15 GMT+09:00 Paul Kierstead <paulkierstead@xxxxxxxxx>:

On Sun, 25 Sep 2016 at 09:50 Tomoaki Yamaguchi <tomoaki@xxxxxxxxxxxxx> wrote:

Hi Paul,

Thank you for your suggestions.

1.

> I'm not sure about its purpose,

const char* getDescription(void) { return "XBEE"; } has been changed.

Purpose is to show sensor network parameters defined by gateway.conf as follows:

Ah, I see its in your fork, but not in the gateway branch yet (my github terminology may not be right here). I think I'll try out your fork then, it seems to have some nice improvements.

you don't need to change Makefile to build GW for XBee.

SENSORNET is over writen by a command line parameter.

Input command as follows:

      $ make SENSORNET=xbee

Wow, I've used make for how many years and I didn't know command line assignments overrode explicit makefile assignments. You learn something new everyday!

 

3.

I disagree changing to the software selectable GW.

No one knows how many sensor network devices should be covered.

Sure, everyone who uses the supplied code knows: There are two. Of course people can write their own, but 99% of people will use it "out of the box". I'm not saying the ability to add ones at compile time should be eliminated, but what will happen is likely this: If this gateway has some success, people will want to have pre-built binaries for the supported networks (currently XBee and UDP). So, someone will make an Ubuntu package (or whatever) and just build one executable for each type of network. If more network types are added to the base, there will be more executables. This has the additional clunkiness that if the a new network type is added to the codebase, the package building stuff has to be updated instead of just rebuilt. This will also lead to confusion, as they all can be defined in the gateway.conf. Eventually, people will want one executable and be able to select which network type (or even types) in the conf file. Of course, one could easily have a make variable which defines which networks are in the executable for those who want to build their own. 

However, in any case, it only matters if the gateway gets some usage, which would be nice! 

PK

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev