Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] paho-dev Digest, Vol 38, Issue 10

> To subscribe or unsubscribe via the World Wide Web, visit
>       https://dev.eclipse.org/mailman/listinfo/paho-dev

On Thu Feb 05 2015 at 10:59:33 안진아(JinA Ahn)/Platform Software개발1팀/SKP <jin.a.ahn@xxxxxx> wrote:
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@xxxxxxxxxxxxxxxxxxxx.uk>
> To: paho-dev@xxxxxxxxxxx
> Subject: Re: [paho-dev] Cross-compilation of Eclipse Paho
> Message-ID: <54D283EF.8000109@modelbasedtesting.co.uk>
> 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@xxxxxxxxxxxxxxxxxxxx.uk> 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@mail.gmail.com>
> 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@xxxxxxxxxxxxxxxxxxxx.uk> 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@xxxxxxxxxxxxxxxxxxxx.uk> 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@phx.gbl>
> 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@xxxxxxxxxxxxxxxxxxxx.uk
> 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@xxxxxxxxxxxxxxxxxxxx.uk>
> To: paho-dev@xxxxxxxxxxx
> Subject: Re: [paho-dev] Paho C-Client TLSv1.1 - unknown Protocol
> Message-ID: <54D34BCA.8040301@modelbasedtesting.co.uk>
> 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@xxxxxxxxxxxxxxxxxxxx.uk
>> 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
> ****************************************

_______________________________________________
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

Back to the top