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. AW: Bug in gdhcp/server.c (Gerald Loacker)
2. Re: [PATCH 2/2] session: Change del_nat_rules logic
(Daniel Wagner)
3. Re: connmand[186]: Online check failed but running dhclient
manually fixes this issue (Daniel Wagner)
4. Re: connmand[186]: Online check failed but running dhclient
manually fixes this issue (Denis Kenzior)
----------------------------------------------------------------------
Message: 1
Date: Wed, 6 Sep 2017 06:11:29 +0000
From: Gerald Loacker <[email protected]>
To: "Carl D. Blake" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: AW: Bug in gdhcp/server.c
Message-ID:
<EE574EEBFD35A749A1DCE035A0A7849E14D09644@WOLFSERVER19.wolfvision-at.intra>
Content-Type: text/plain; charset="utf-8"
Carl,
great to hear. Thanks for the feedback.
Gerald
-----Urspr?ngliche Nachricht-----
Von: Carl D. Blake [mailto:[email protected]]
Gesendet: Dienstag, 5. September 2017 18:51
An: Gerald Loacker
Cc: [email protected]
Betreff: Re: Bug in gdhcp/server.c
Gerald,
On Thu, 2017-08-31 at 08:39 -0700, Carl D. Blake wrote:
> Gerald,
>
> On Thu, 2017-08-31 at 07:56 +0000, Gerald Loacker wrote:
> > Hi,
> >
> >
> >
> > when using miracast and being group owner of the p2p connection,
> > the connection stops after about one hour (client was Microsoft
> > surface pro 3). The attached patch fixes this issue. Could someone
> > please review?
> >
> I will be checking this in the next few days. I've been experiencing
> this problem also. Only it stops after about 30 mins. Very
> consistently. Same situation (miracast and p2p connection).
>
I applied the patch to V1.35. It works. I tested this for an hour and a half
with a miracast connection through p2p without it disconnecting.
Thank you.
> >
> >
> > Regards,
> >
> > Gerald
> >
> >
> >
> >
> > _______________________________________________
> > connman mailing list
> > [email protected]
> > https://lists.01.org/mailman/listinfo/connman
>
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
------------------------------
Message: 2
Date: Wed, 06 Sep 2017 17:09:45 +0200
From: Daniel Wagner <[email protected]>
To: "Liang\, Jian \[TYCO GBS - Cork\]" <[email protected]>
Cc: Jian Liang <[email protected]>, "connman\@lists.01.org"
<[email protected]>
Subject: Re: [PATCH 2/2] session: Change del_nat_rules logic
Message-ID: <[email protected]>
Content-Type: text/plain
Hi Jian,
"Liang, Jian [TYCO GBS - Cork]" <[email protected]> writes:
> Hi Daniel,
>
> Looking back to this patch. It seems that it is not needed at all
> now. The original intention of these two patches together was to solve
> the issue that nat-postrouting rule was not updated when IP address
> changed in a context of multiple sessions on the same
> AllowedInterface. The issue is supposed to be solved by the last
> patch. The addr parameter should be sufficient to make sure
> fw_snat_look function find the correct fw_snat, deleting sessions one
> by one from the old fw_snat and add them to the new fw_snat created
> with the new IP address. Hope this make more sense to you.
Ah good, I drop this patch in this case.
> Thank you very much for your carefulness. :)
No problem. :)
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 06 Sep 2017 17:17:43 +0200
From: Daniel Wagner <[email protected]>
To: Denis Kenzior <[email protected]>
Cc: [email protected], Alexander Couzens <[email protected]>,
"connman\@lists.01.org" <[email protected]>, [email protected]
Subject: Re: connmand[186]: Online check failed but running dhclient
manually fixes this issue
Message-ID: <[email protected]>
Content-Type: text/plain
Hi Denis,
Denis Kenzior <[email protected]> writes:
> On 09/05/2017 09:46 AM, Alexander Couzens wrote:
>> On Thu, 10 Aug 2017 12:47:28 +0200
>> Daniel Wagner <[email protected]> wrote:
>>
>>>> Bus 001 Device 003: ID 1bc7:1201 Telit Wireless Solutions
>>>
>>> Here is a compile tested 'fix'. I don't know if this works and\
>>> obviously it doesn't follow the coding guide lines for this
>>> project. If you could test this and report back the outcome
>>> that would be really helpful. Then I can create a proper
>>> patch for Denis.
>>
>> I can confirm this bug with an quectel ec20 using the firmware
>> EC20EQAR02A13E2G 1 [Jul 5 2017 10:49:17].
>>
>> To reproduce using ofono w/o connman. linux 4.12.8
>> - call ofono "../context1 Active true"
>> - set the ip by hand. No ping response.
>> - using dhcpcd. Ping responses.
>>
>> The `ip addr show` looks the same, except the interface has now an ipv6
>> link local address. Is this is problem of modern LTE cards?
>> Could be raw-ip or 802.3 encapsulations the problem?
>>
>
> Here's something Reinhard said in a different thread that might be
> applicable here:
>
> "Unfortunately the PLS8 seems to need DHCP to be used as a trigger to
> pass IPv4 traffic over the network interface even if the parameters
> could be obtained from AT commands.
>
> This restriction also holds for some other Qualcomm firmwares when the
> QMI network interface is used in Ethernet mode instead of Raw IP mode."
>
> If this is true, then falling back to DHCP would seem to be required
> for many Qualcomm based devices. This seems to be a recently
> introduced 'bug' as older QMI devices did not need this workaround.
Do you think we should try to figure out which Qualcomm device is
misbehaving or should the feature just be reverted?
The other option is to add some fallback mechanism in ConnMan and print
a fat warning into the log. But I don't this idea.
Thanks,
Daniel
------------------------------
Message: 4
Date: Wed, 6 Sep 2017 10:40:18 -0500
From: Denis Kenzior <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected], Alexander Couzens <[email protected]>,
"[email protected]" <[email protected]>, [email protected]
Subject: Re: connmand[186]: Online check failed but running dhclient
manually fixes this issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
>>
>> If this is true, then falling back to DHCP would seem to be required
>> for many Qualcomm based devices. This seems to be a recently
>> introduced 'bug' as older QMI devices did not need this workaround.
>
> Do you think we should try to figure out which Qualcomm device is
> misbehaving or should the feature just be reverted?
It would seem that this only affects devices introduced in the last
several years. The QMI code is from 2012, and the devices Marcel tested
this with worked fine.
Perhaps we should have plugins/udevng.c maintain a database of all the
'dhcp-required' devices and set this property accordingly. Running DHCP
takes time, so if it can be avoided, you get online a bit faster...
>
> The other option is to add some fallback mechanism in ConnMan and print
> a fat warning into the log. But I don't this idea.
>
Sounds like a least preferred option to me as well.
Regards,
-Denis
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 23, Issue 5
**************************************
