Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite (Daniel Wagner)
2. Re: [PATCH] Adds support for additional wpa_supplicant
options (Daniel Wagner)
3. Re: [PATCH] Adds support for additional wpa_supplicant
options (Daniel Wagner)
4. Re: Issue in setting nameserver and default route (Daniel Wagner)
5. Re: [PATCH] stats: Don't handle TEMP_FAILURE_RETRY on close()
(Daniel Wagner)
6. RE: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite (Blanquicet-Melendez Jose (MM))
7. Tethering bridge interface (Blanquicet-Melendez Jose (MM))
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Dec 2016 08:46:54 +0100
From: Daniel Wagner <[email protected]>
To: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Jose,
>> I tried to figure out how to solve this. It seems the canonical
>> way according the man pages is to use a cast like:
>>
>> - if (expired == 0xffffffff)
>> + if (expired == (time_t)0xffffffff)
>>
>> Wouldn't mind if someone with more knowledge could answer this question.
>
> Indeed, that is why I replied to this patch; maybe Patrik or Feng
> Wang could tell us if that casting could impact the normal behavior of this
> patch because I also thought the same solution but I do not actually
> know the context of this patch.
Well, it seem we both are not really sound in the casting theory here.
Maybe have a look at the resulting assembly. If our assumption is
correct, I would expect the same assembly.
> iptables already implements a function to get struct xt_entry_target
> pointer from a struct ipt_entry pointer in iptables.h:
>
> static __inline__ struct xt_entry_target *
> ipt_get_target(struct ipt_entry *e)
> {
> return (void *)e + e->target_offset;
> }
>
> Then, two of the error could be solve doing this:
>
> - error = (struct error_target *) entry_head->elems;
> + error = (struct error_target *) ipt_get_target(entry_head);
>
> - standard = (struct ipt_standard_target *) entry_return->elems;
> + standard = (struct ipt_standard_target *) ipt_get_target(entry_return);
>
> Do you agree?
That make sense.
> On the other hand, to get the struct xt_entry_match pointer from
> ipt_entry we could follow the same approach by defining a function like
> this:
>
> static __inline__ struct xt_entry_match *ipt_get_match(struct ipt_entry *e)
> {
> return (void *)e->elems;
> }
>
> What do you think? I would really appreciate if someone with much
> more knowledge on this could test those ideas or suggest a possible solution.
> In fact, I am not completely sure if this is actually an alignment
> problem or only a casting problem because of different struct type.
Yes, let's add this helper function as is defined in iptables.h. Best
thing we can do is mimic what iptables does. The 'API' is pretty hard to
get right, so it's better to be as close iptables as possible. That code
should be okay in respect to alignment.
I wont have time to spin a patches today. So I don't mind of you send
fixes instead :)
Thanks for digging into this.
cheers,
daniel
------------------------------
Message: 2
Date: Mon, 5 Dec 2016 09:04:07 +0100
From: Daniel Wagner <[email protected]>
To: Bernhard Lichtinger <[email protected]>,
[email protected]
Subject: Re: [PATCH] Adds support for additional wpa_supplicant
options
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bernhard,
I gave the patch a short test and it seems to break my PSK setup.
First of all p2p technology disappears with this path and second no
network is shown at all. I am not sure what's going wrong because the
patch doesn't look that dangerous. I don't have time to look at it today.
Does it work for you on normal non EAP networks?
a few bikeshedding comments below:
On 12/02/2016 10:22 AM, Bernhard Lichtinger wrote:
> subject_match, altsubject_match, domain_suffix_match,
> domain_match
> they are used for 802.1X aka. enterprise-wpa to check
> the authentication server's certificate in order to
> prevent MITM attacks using a valid certificate issued
> by the same root-CA as configured by CACertFile.
If you are at it, you could make it a bit wider and break the lines
a bit nicer. Looks a bit out of normal (bikeshedding! :))
> @@ -4651,6 +4727,10 @@ static void service_free(gpointer user_data)
> g_free(service->anonymous_identity);
> g_free(service->agent_identity);
> g_free(service->ca_cert_file);
> + g_free(service->subject_match);
> + g_free(service->altsubject_match);
> + g_free(service->domain_suffix_match);
> + g_free(service->domain_match);
indention not correct.
cheers,
daniel
------------------------------
Message: 3
Date: Mon, 5 Dec 2016 09:06:45 +0100
From: Daniel Wagner <[email protected]>
To: Bernhard Lichtinger <[email protected]>,
[email protected]
Subject: Re: [PATCH] Adds support for additional wpa_supplicant
options
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/05/2016 09:04 AM, Daniel Wagner wrote:
> Hi Bernhard,
>
> I gave the patch a short test and it seems to break my PSK setup.
>
> First of all p2p technology disappears with this path and second no
> network is shown at all. I am not sure what's going wrong because the
> patch doesn't look that dangerous. I don't have time to look at it today.
>
> Does it work for you on normal non EAP networks?
D'oh, I should enable the wpa_supplicant pluing obviously... now it
works. I have fixed up the bikeshedding myself. You don't have to do
anything.
patch applied. pushing in a few minutes.
cheers,
daniel
------------------------------
Message: 4
Date: Mon, 5 Dec 2016 09:24:47 +0100
From: Daniel Wagner <[email protected]>
To: Priyaranjan Singh <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Issue in setting nameserver and default route
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
On 12/02/2016 10:21 AM, Priyaranjan Singh wrote:
> We have got Telephony device connected to usb0 interface with my
> Linux embedded system. This Telephony device doesn't have DHCP Server.
>
> Using connman API, we are setting static route and nameserver information.
I assume you are talking about the D-Bus APIs.
> With the logs we can very well verify that connman accepted this new
> values but reverting this value soon.
So you set the value and soon after that it is reverted again?
> Note: Telephony device has been given highest priority in the
> connman service order list. Also using log I cannot see service order
> changing
> is happening.
How do you set the highest priority? Via MoveBefore? If so, MoveBefore
and MoveAfter is not really useful because it is not something ConnMan
remembers. It is just the ordering for the moment you influence.
Everyone agrees, that is not how it should be.
> Basic steps: My application is setting below properties. Listening
> for the change from connman. In case connman is reverting this
> change, application is setting back to static values.
> For "nameserver" we are setting " Nameservers.Configuration" property
> For "route" we are setting " IPv4.Configuration" property (Method, Address,
> Netmask, Gateway)
>
> Result:
> 1) When application is setting "nameserver", for entire lifecycle
> connman is clearing the value and My application is setting it back.
> This is going in loop.
Hard to tell. Could you send logs for this?
> - If application is writing static nameserver to "resolv.conf" file directly.
> We are not observing any issues.
> - What will be side effect in case application is directly writing to
> resolv.conf
You are bypassing the dnsproxy inside ConnMan. If you don't want ConnMan
to handle the DNS queries you can disable it via -r command line option.
> 2) When application is reading " IPv4" property, if "method" is not
> "manual" then setting " IPv4.Configuration". Application is checking
> this on SERVICESCHANGED and PROPERTYCHANGED signal from connman
Not sure if I understand this correctly. Could you write this as small
Python demonstrator, something like in connman/tests/set-ipv4-method?
> - usb0 interface is getting added and removed by connman continuously ==>
> connman Log " usb0 {add} route" & " usb0 {del} route" is continuously coming
> - This is causing state change to "configuration" -> "idle" ->
> "ready"
>
> Do you know reason for this issue? Are we consuming connman APIs in wrong way?
As I said, it is hard to tell from you description. Log files and a
small Python prototype would really help.
Thanks,
Daniel
------------------------------
Message: 5
Date: Mon, 5 Dec 2016 09:27:50 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH] stats: Don't handle TEMP_FAILURE_RETRY on close()
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
patch applied after fixing the commit message slightly.
------------------------------
Message: 6
Date: Mon, 5 Dec 2016 15:35:50 +0000
From: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
>>> I tried to figure out how to solve this. It seems the canonical
>>> way according the man pages is to use a cast like:
>>>
>>> - if (expired == 0xffffffff)
>>> + if (expired == (time_t)0xffffffff)
>>>
>>> Wouldn't mind if someone with more knowledge could answer this question.
>>
>>
>> Indeed, that is why I replied to this patch; maybe Patrik or Feng
>> Wang could tell us if that casting could impact the normal behavior of
>> this
>> patch because I also thought the same solution but I do not actually
>> know the context of this patch.
>
>
> Well, it seem we both are not really sound in the casting theory here. Maybe
> have a look at the resulting assembly. If our assumption is correct, I would
> expect the same assembly.
>
>> iptables already implements a function to get struct xt_entry_target
>> pointer from a struct ipt_entry pointer in iptables.h:
>>
>> static __inline__ struct xt_entry_target *
>> ipt_get_target(struct ipt_entry *e)
>> {
>> return (void *)e + e->target_offset;
>> }
>>
>> Then, two of the error could be solve doing this:
>>
>> - error = (struct error_target *) entry_head->elems;
>> + error = (struct error_target *) ipt_get_target(entry_head);
>>
>> - standard = (struct ipt_standard_target *) entry_return->elems;
>> + standard = (struct ipt_standard_target *)
>> ipt_get_target(entry_return);
>>
>> Do you agree?
>
>
> That make sense.
However, analyzing better, ipt_get_target() will return a different offset than
what is currently done (Access directly entry_head->elems). According to
comments in iptables source code, in the variable elems of ipt_entry struct,
the matches (if any) are stored first and then the target. Therefore, either
current implementation is wrong because we are accessing the memory space where
is stored the matches and not the target, or I am missing something and I
misunderstood this.
>> On the other hand, to get the struct xt_entry_match pointer from
>> ipt_entry we could follow the same approach by defining a function like
>> this:
>>
>> static __inline__ struct xt_entry_match *ipt_get_match(struct ipt_entry
>> *e)
>> {
>> return (void *)e->elems;
>> }
>>
>> What do you think? I would really appreciate if someone with much
>> more knowledge on this could test those ideas or suggest a possible
>> solution.
>> In fact, I am not completely sure if this is actually an alignment
>> problem or only a casting problem because of different struct type.
>
>
> Yes, let's add this helper function as is defined in iptables.h. Best thing
> we can do is mimic what iptables does. The 'API' is pretty hard to get
> right, so it's better to be as close iptables as possible. That code should
> be okay in respect to alignment.
>
> I wont have time to spin a patches today. So I don't mind of you send fixes
> instead :)
Even fixing these error as we discussed, there are more cast-align errors when
compilation goes forward. I thought these new errors could be quickly fixed but
it seems they could not and unfortunately I do not have more time to continue
digging in this. I apologize, but I have to postponed this activity.
Cheers,
Jose Blanquicet
VISITA IL NOSTRO SITO WEB! - VISIT OUR WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited. If you have received this communication by mistake, please forward
the message back to the sender at the email address above, delete the message
from all mailboxes and any other electronic storage medium and destroy all
copies. Disclaimer Notice: Internet communications cannot be guaranteed to be
safe or error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
------------------------------
Message: 7
Date: Mon, 5 Dec 2016 15:57:33 +0000
From: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: Tethering bridge interface
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
We continue studying how tethering is implemented and we were wondering what is
the purpose of creating the bridge interface "tether". For instance, hostapd
does not do this thus it seems to not be strictly mandatory. In addition, what
would happen if a given system supports tethering but does not support 802.1d
Ethernet bridging?
Regards,
Jose Blanquicet
VISITA IL NOSTRO SITO WEB! - VISIT OUR WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited. If you have received this communication by mistake, please forward
the message back to the sender at the email address above, delete the message
from all mailboxes and any other electronic storage medium and destroy all
copies. Disclaimer Notice: Internet communications cannot be guaranteed to be
safe or error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 6
**************************************
