[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] paho-dev Digest, Vol 38, Issue 10
|
I want to unsubscribe this mail.
Thanks!
On Feb 5, 2015, at 7:54 PM, <paho-dev-request@xxxxxxxxxxx> <paho-dev-request@xxxxxxxxxxx> wrote:
> Send paho-dev mailing list submissions to
> paho-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev
> or, via email, send a message with subject or body 'help' to
> paho-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
> paho-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of paho-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Cross-compilation of Eclipse Paho (Ian Craggs)
> 2. Re: Cross-compilation of Eclipse Paho (Rainer Poisel)
> 3. Re: Paho C-Client TLSv1.1 - unknown Protocol (Chris Summer)
> 4. Re: Paho C-Client TLSv1.1 - unknown Protocol (Ian Craggs)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 04 Feb 2015 20:41:19 +0000
> From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> To: paho-dev@xxxxxxxxxxx
> Subject: Re: [paho-dev] Cross-compilation of Eclipse Paho
> Message-ID: <54D283EF.8000109@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hi Rainer,
>
> the situation I want to avoid is having a list of output directory names
> in the Ant job, having to maintain that list and select the right one in
> the job. That's just a recipe for more work and bugs.
>
> If the Ant job detects the output directory dynamically and uses it, I'd
> be happy with that.
>
> Another alternative would be to change the Hudson job so that it didn't
> use Ant. But that would be a few days' work, and not something I really
> want to look into right now.
>
> Ian
>
> On 02/04/2015 07:49 PM, Rainer Poisel wrote:
>> Hi Ian and Frank,
>>
>> thank's for having a look at my commit!
>>
>> To me having different names for the output directory for the
>> different target platforms is quite important because I am compiling
>> programs for a few different platforms every day.
>>
>> However, if you want we could remove the "unique name per target
>> platform" change for the output directory in a new patchset and
>> configure CDT to rename the build directory to a unique name in a
>> post-build step, aside of the things that happen in the Makefile. That
>> way, using Eclipse it is possible to have different output
>> directories, but by using the Makefile only, it is always the same. I
>> guess adapting your tests, CI, etc. to support different platforms
>> could be quite an effort.
>>
>> We could think of having e. g. unit-tests for the different platforms
>> in one of the next releases.
>>
>> Kind regards,
>> Rainer
>>
>>
>> On Wed, Feb 4, 2015 at 6:12 PM, Ian Craggs
>> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> Hi Rainer,
>>>
>>> you changed the default build directory, which causes the tests not to run
>>> in the Ant build, which is why the Hudson verification of the change fails.
>>>
>>> The change is from:
>>>
>>> /build/output
>>>
>>> to
>>>
>>> build/$(BUILD_TYPE)-$(OSTYPE)-$(MACHINETYPE)
>>>
>>> This would mean that the Ant configuration file would have to have a
>>> different build directory setting for each OS etc. The Hudson build
>>> definition could send this in as a parameter, but this to me feels
>>> unnecessarily complicated. As this is a temporary directory, is the name
>>> that important?
>>>
>>> Ian
>>>
>>> On 02/03/2015 08:52 PM, Rainer Poisel wrote:
>>>> Dear list,
>>>>
>>>> some days ago I published a commit on the eclipse gerrit server that
>>>> features multi-core builds (using "make -j"), cross compilation and
>>>> some sample build-configurations for Eclipse CDT:
>>>> * https://git.eclipse.org/r/#/c/39355/
>>>>
>>>> As part of this commit the Makefile has been refactored in order to
>>>> remove some code-duplication and to reflect involved dependencies
>>>> correctly. As the output directory structure of the Makefile changed,
>>>> the builds on the Hudson based CI fail.
>>>>
>>>> Is there a way to make my changes make their way into one of the next
>>>> releases? Or is there someone out there who could review my commit?
>>>>
>>>> Kind regards and thanks,
>>>> Rainer
>>>> _______________________________________________
>>>> 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
>>>
>>> --
>>> Ian Craggs
>>> icraggs@xxxxxxxxxx IBM United Kingdom
>>> Paho Project Lead; Committer on Mosquitto
>>>
>>> _______________________________________________
>>> 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
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Paho Project Lead; Committer on Mosquitto
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 4 Feb 2015 23:38:58 +0100
> From: Rainer Poisel <rainer.poisel@xxxxxxxxx>
> To: General development discussions for paho project
> <paho-dev@xxxxxxxxxxx>
> Subject: Re: [paho-dev] Cross-compilation of Eclipse Paho
> Message-ID:
> <CADpFnzxDkAaWVy1SjTEkU0Ga_ujuZyNs+XLBeP013mCaNZCgpA@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Ian,
>
> I think I did not explain very well, what I meant. I have amended your
> new commit on the "develop" branch:
> * https://git.eclipse.org/r/#/c/41089/1..2/Makefile
>
> The output directory will now always be "/build/output" (please see
> line 31 of the Makefile), no matter what target platform or build
> configuration has been chosen. Therefore it works with your Hudson
> configuration. Configuration settings (BUILD_TYPE, OSTYPE,
> MACHINETYPE) however, are still regarded in the compilation/linking
> process.
>
> In the future (e. g. one of the next releases) we can think of
> different configurations and test scenarios. ATM it is sufficient for
> me to have a "post-build" step where directories are renamed by the
> caller of the Makefile. I don't know how to do that with an unmanaged
> CDT project, but I am confident to find a solution soon.
>
> On Wed, Feb 4, 2015 at 9:41 PM, Ian Craggs
> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Hi Rainer,
>>
>> the situation I want to avoid is having a list of output directory names in
>> the Ant job, having to maintain that list and select the right one in the
>> job. That's just a recipe for more work and bugs.
>>
>> If the Ant job detects the output directory dynamically and uses it, I'd be
>> happy with that.
>>
>> Another alternative would be to change the Hudson job so that it didn't use
>> Ant. But that would be a few days' work, and not something I really want to
>> look into right now.
>>
>> Ian
>>
>>
>> On 02/04/2015 07:49 PM, Rainer Poisel wrote:
>>>
>>> Hi Ian and Frank,
>>>
>>> thank's for having a look at my commit!
>>>
>>> To me having different names for the output directory for the
>>> different target platforms is quite important because I am compiling
>>> programs for a few different platforms every day.
>>>
>>> However, if you want we could remove the "unique name per target
>>> platform" change for the output directory in a new patchset and
>>> configure CDT to rename the build directory to a unique name in a
>>> post-build step, aside of the things that happen in the Makefile. That
>>> way, using Eclipse it is possible to have different output
>>> directories, but by using the Makefile only, it is always the same. I
>>> guess adapting your tests, CI, etc. to support different platforms
>>> could be quite an effort.
>>>
>>> We could think of having e. g. unit-tests for the different platforms
>>> in one of the next releases.
>>>
>>> Kind regards,
>>> Rainer
>>>
>>>
>>> On Wed, Feb 4, 2015 at 6:12 PM, Ian Craggs
>>> <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>
>>>> Hi Rainer,
>>>>
>>>> you changed the default build directory, which causes the tests not to
>>>> run
>>>> in the Ant build, which is why the Hudson verification of the change
>>>> fails.
>>>>
>>>> The change is from:
>>>>
>>>> /build/output
>>>>
>>>> to
>>>>
>>>> build/$(BUILD_TYPE)-$(OSTYPE)-$(MACHINETYPE)
>>>>
>>>> This would mean that the Ant configuration file would have to have a
>>>> different build directory setting for each OS etc. The Hudson build
>>>> definition could send this in as a parameter, but this to me feels
>>>> unnecessarily complicated. As this is a temporary directory, is the
>>>> name
>>>> that important?
>>>>
>>>> Ian
>>>>
>>>> On 02/03/2015 08:52 PM, Rainer Poisel wrote:
>>>>>
>>>>> Dear list,
>>>>>
>>>>> some days ago I published a commit on the eclipse gerrit server that
>>>>> features multi-core builds (using "make -j"), cross compilation and
>>>>> some sample build-configurations for Eclipse CDT:
>>>>> * https://git.eclipse.org/r/#/c/39355/
>>>>>
>>>>> As part of this commit the Makefile has been refactored in order to
>>>>> remove some code-duplication and to reflect involved dependencies
>>>>> correctly. As the output directory structure of the Makefile changed,
>>>>> the builds on the Hudson based CI fail.
>>>>>
>>>>> Is there a way to make my changes make their way into one of the next
>>>>> releases? Or is there someone out there who could review my commit?
>>>>>
>>>>> Kind regards and thanks,
>>>>> Rainer
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> --
>>>> Ian Craggs
>>>> icraggs@xxxxxxxxxx IBM United Kingdom
>>>> Paho Project Lead; Committer on Mosquitto
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> --
>> Ian Craggs
>> icraggs@xxxxxxxxxx IBM United Kingdom
>> Paho Project Lead; Committer on Mosquitto
>>
>> _______________________________________________
>> 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
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 5 Feb 2015 08:11:27 +0100
> From: Chris Summer <chrisdevel@xxxxxxxxxxx>
> To: General development discussions for paho project
> <paho-dev@xxxxxxxxxxx>
> Subject: Re: [paho-dev] Paho C-Client TLSv1.1 - unknown Protocol
> Message-ID: <BAY179-W123ECDF4D6515C57ECDF40C13B0@xxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
>
> Hi Ian,
>
> I had seen that, but not realized that default ALL will somehow interfere with the functioning....
>
> There was a second thing that I had to change.
>
> The Server URI in the MQTTClient_create function had to have ssl instead of tcp as protocol. Although the API description states:
>
>
> serverURI A null-terminated string specifying the server to which the client will connect. It takes the form protocol://host:port. Currently, protocol must be tcp.
> Maybe it is a good Idea to extend the API documentation in this point!
>
> Cheers
>
> Chris
>
>
>
>
> Date: Wed, 4 Feb 2015 15:06:58 +0000
> From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx
> To: paho-dev@xxxxxxxxxxx
> Subject: Re: [paho-dev] Paho C-Client TLSv1.1 - unknown Protocol
>
>
>
>
>
>
> P.S. you can use the protocol trace of the client to display the
> diagnostic messages from OpenSSL by setting the environment
> variables:
>
>
>
> MQTT_C_CLIENT_TRACE=<ON or filename>
>
> MQTT_C_CLIENT_TRACE_LEVEL=PROTOCOL
>
>
>
> This will show details of the OpenSSL handshake.
>
>
>
> Ian
>
>
>
>
>
> On 02/04/2015 03:03 PM, Ian Craggs
> wrote:
>
>
>
>
> Hi Chris,
>
>
>
> in the documentation for the SSL options structure,
>
>
>
> (https://www.eclipse.org/paho/files/mqttdoc/Cclient/struct_m_q_t_t_client___s_s_l_options.html)
>
>
>
> there is the enabledCipherSuites option, which points to the
> OpenSSL documentation:
>
>
>
> For a full explanation of the cipher list format, please
> see the OpenSSL on-line documentation: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT
> If this setting is ommitted, its default value will be "ALL"
>
>
>
>
> ALL
>
> all cipher suites except the eNULL
> ciphers which must be explicitly enabled; as of OpenSSL,
> the ALL cipher suites are
> reasonably ordered by default
>
>
>
>
>
> Also in the OpenSSL Cipher Suites section there is:
>
>
>
> TLSv1.2, TLSv1,
> SSLv3
>
>
> TLS v1.2, TLS v1.0 or SSL v3.0 cipher suites
> respectively. Note: there are no ciphersuites specific to
> TLS v1.1.
>
>
>
> So, you should be able to use
>
>
>
> sslopts.enabledCipherSuites = "TLSv1.2";
>
>
>
> for instance.
>
>
>
> Ian
>
>
>
> On 02/04/2015 10:49 AM, Chris Summer
> wrote:
>
>
>
>
> Hi all,
>
>
>
> I am trying to use a SSL connection with the PAHO C Client. It
> seems as if I just miss something!
>
>
>
> When Using the Python API, I can use tls_version=....
>
>
>
> In the Documentation for the C API I don't find anything
> comparable.
>
>
>
> I have set connection_options.serverURIs="ssl://mybroker:8883"
> and the client tries to connect to the mosquitto broker, which
> logs:
>
>
>
> SSL23_GET_CLIENT_HELLO:unknown protocol.
>
>
>
> Which was the same Error I got when not specifying the tls
> protocol version in Python. Is there any way in the C API to
> set the SSL/TLS Version?
>
>
>
> Did I miss anything else?
>
>
>
> Cheers,
>
>
>
> Chris
>
>
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Paho Project Lead; Committer on Mosquitto
>
>
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Paho Project Lead; Committer on Mosquitto
>
>
>
>
>
> _______________________________________________
> 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/paho-dev/attachments/20150205/171efb8b/attachment.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 05 Feb 2015 10:54:02 +0000
> From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> To: paho-dev@xxxxxxxxxxx
> Subject: Re: [paho-dev] Paho C-Client TLSv1.1 - unknown Protocol
> Message-ID: <54D34BCA.8040301@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Ah, thanks for pointing that out. Will update.
>
> Ian
>
>
> On 02/05/2015 07:11 AM, Chris Summer wrote:
>>
>> Hi Ian,
>>
>> I had seen that, but not realized that default ALL will somehow
>> interfere with the functioning....
>>
>> There was a second thing that I had to change.
>>
>> The Server URI in the MQTTClient_create function had to have ssl
>> instead of tcp as protocol. Although the API description states:
>>
>>
>> /serverURI/ A null-terminated string specifying the server to which
>> the client will connect. It takes the form /protocol://host:port/.
>> Currently, /protocol/ must be /tcp/.
>>
>>
>> Maybe it is a good Idea to extend the API documentation in this point!
>>
>> Cheers
>>
>> Chris
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> Date: Wed, 4 Feb 2015 15:06:58 +0000
>> From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx
>> To: paho-dev@xxxxxxxxxxx
>> Subject: Re: [paho-dev] Paho C-Client TLSv1.1 - unknown Protocol
>>
>> P.S. you can use the protocol trace of the client to display the
>> diagnostic messages from OpenSSL by setting the environment variables:
>>
>> MQTT_C_CLIENT_TRACE=<ON or filename>
>> MQTT_C_CLIENT_TRACE_LEVEL=PROTOCOL
>>
>> This will show details of the OpenSSL handshake.
>>
>> Ian
>>
>>
>> On 02/04/2015 03:03 PM, Ian Craggs wrote:
>>
>> Hi Chris,
>>
>> in the documentation for the SSL options structure,
>>
>> /(https://www.eclipse.org/paho/files/mqttdoc/Cclient/struct_m_q_t_t_client___s_s_l_options.html)/
>>
>> there is the enabledCipherSuites option, which points to the
>> OpenSSL documentation:
>> /
>> //For a full explanation of the cipher list format, please see the
>> OpenSSL on-line documentation:
>> //http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT//If
>> this setting is ommitted, its default value will be "ALL"/
>>
>> /**ALL**/
>> // /all cipher suites except the //*eNULL*//ciphers which must
>> be explicitly enabled; as of OpenSSL, the //*ALL*//cipher
>> suites are reasonably ordered by default/
>>
>>
>> Also in the OpenSSL Cipher Suites section there is:
>>
>> /**TLSv1.2*, *TLSv1*, *SSLv3**/
>>
>> // /TLS v1.2, TLS v1.0 or SSL v3.0 cipher suites respectively.
>> Note: there are no ciphersuites specific to TLS v1.1./
>>
>> So, you should be able to use
>>
>> /sslopts.enabledCipherSuites = "TLSv1.2";/
>>
>> for instance.
>>
>> Ian
>>
>> On 02/04/2015 10:49 AM, Chris Summer wrote:
>>
>> Hi all,
>>
>> I am trying to use a SSL connection with the PAHO C Client. It
>> seems as if I just miss something!
>>
>> When Using the Python API, I can use tls_version=....
>>
>> In the Documentation for the C API I don't find anything
>> comparable.
>>
>> I have set connection_options.serverURIs="ssl://mybroker:8883"
>> and the client tries to connect to the mosquitto broker, which
>> logs:
>>
>> SSL23_GET_CLIENT_HELLO:unknown protocol.
>>
>> Which was the same Error I got when not specifying the tls
>> protocol version in Python. Is there any way in the C API to
>> set the SSL/TLS Version?
>>
>> Did I miss anything else?
>>
>> Cheers,
>>
>> Chris
>>
>>
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx <mailto: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
>>
>>
>> --
>> Ian Craggs
>> icraggs@xxxxxxxxxx <mailto:icraggs@xxxxxxxxxx> IBM United Kingdom
>> Paho Project Lead; Committer on Mosquitto
>>
>>
>>
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx <mailto: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
>>
>>
>> --
>> Ian Craggs
>> icraggs@xxxxxxxxxx <mailto:icraggs@xxxxxxxxxx> IBM United Kingdom
>> Paho Project Lead; Committer on Mosquitto
>>
>>
>> _______________________________________________ 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
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Paho Project Lead; Committer on Mosquitto
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/paho-dev/attachments/20150205/8261d974/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> 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
>
> End of paho-dev Digest, Vol 38, Issue 10
> ****************************************
