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: ipv4 gateway is missing after configurations (Daniel Wagner)
2. Re: Sending DHCP release on incorrect iface when iface goes
down (Joakim Lotseng?rd)
3. Re: Unsalble cellular connection (Daniel Wagner)
4. Re: Sending DHCP release on incorrect iface when iface goes
down (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Aug 2019 14:46:56 +0200
From: Daniel Wagner <[email protected]>
To: Daniel WANG <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: ipv4 gateway is missing after configurations
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daniel,
On 8/1/19 10:23 AM, Daniel WANG wrote:
> Hi Daniel,
>
> Thanks for your reply. The attached is the log with latest release
> v1.37. The issue happens when IP mode is changed from dhcp to manual.
Thanks a lot. I can't really see any problem in the log.
> When the issue happens, I can disable the interface sw0p1 using
> ?connmanctl config ethernet_xxxxx_interface ?ipv4 off?. Once sw0p1 is
> off, the gateway on eth0 is correct again.
Very strange. I tried to reproduce it but no avail. Maybe I am doing
something different to your setup.
> sw0p1 is a bridge port on a switch chip, which is connected to eth0.
Hmm, is ConnMan getting confused this? No idea. Sorry.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 15 Aug 2019 12:57:27 +0000
From: Joakim Lotseng?rd <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Sending DHCP release on incorrect iface when iface goes
down
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
On 2019-08-15 14:24, Daniel Wagner wrote:
> Hi Joakim,
>
> On 8/14/19 9:17 AM, Joakim Lotseng?rd wrote:
<snip>
>> I will try to investigate this further but wanted to ask if someone else
>> seen this issue. My guess is that a fix is to not send the DHCP release
>> if the interface we want to release the IP for is down. It kind of makes
>> sense. There must be very few cases where the DHCP release packet can be
>> routed to the correct DHCP-server via another interface.
>
> Without looking at the code I suspect, that the DHCP release is trigger
> from the interface take down unconditionally.
>
> That is when the interface goes down (user interaction) we send the DHCP
> release. This works in the right order.
>
> But when the interface goes down first we still try to send out the DCHP
> release not checking if the interface is still up.
>
>> connman version used is latest 1.37. However, we tested older of our
>> firmwares and (at least) 1.36 has the problem as well.
>
> Likely.
>
I've not had time to investigate this further (due to sprints planing
and stuff where I work). I didn't really understand if you also thought
that maybe connman shouldn't send that DHCP release, if the interface is
down.
There is also the possibility to bind the socket to a specific
interface. setsockopt(..., SO_BINDTODEVICE, ...); I don't know if that
might solve the problem. Will kernel drop it?
I will eventually have a better look at this and suggest patches, but my
first mail was just to inform about the problem, and also check if maybe
I/we did something stupid and this is how connman should work.
Best regards,
Joakim Lotseng?rd
------------------------------
Message: 3
Date: Thu, 15 Aug 2019 16:58:50 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>, Jonas Bonn <[email protected]>
Cc: connman <[email protected]>, Giacinto Cifelli
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: Unsalble cellular connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 8/15/19 2:45 PM, JH wrote:
>> Well, the log _seemed_ to indicate that connman does an NTP request to a
>> server that isn't available and thereby decides to take the link down...
>> off the top of my head I can't say whether that's something connman
>> actually does so hopefully somebody else will jump in here. Did ofono
>> indicate the context as still established after that?
>
> That seems critical, every time when the link down, connman called:
>
> connmand[213]: Time request for server 10.114.52.97 failed
> (101/Network is unreachable)
The NTP code is just telling it can't reach the server. This has no
direct connenction to the next entry.
> Then deleted the link IP address to cause the link down:
> connmand[213]: wwan0 {del} address 10.114.52.98/30 label wwan0
This message is from the kernel via RTNL interface. The kernel tells
ConnMan the interface state has changed.
> connmand[213]: Skipping disconnect of /ubloxqmi_0/context1, network is
> connecting.
> connmand[213]: ipconfig state 2 ipconfig method 1
and the above is then the cause of the RTNL message.
>> Seeing the issue with complete logs would be useful. I thought your
>> previous logs indicated connman trying to deactivate the context when it
>> took the link down, but the ofono logs didn't show any of that... what's
>> going on there?
>
> The full connman log file attached, there was no information for ofono
> log files. I don't think that ofono was aware of that connman deleted
> the IP address from the LTE link, I cannot understand why the connman
> did it. Anyway, I'll try to debug and to generate ofono log again.
Your log does not contain the debug information (connmand -d).
------------------------------
Message: 4
Date: Thu, 15 Aug 2019 17:03:33 +0200
From: Daniel Wagner <[email protected]>
To: Joakim Lotseng?rd <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Sending DHCP release on incorrect iface when iface goes
down
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Joakim,
On 8/15/19 2:57 PM, Joakim Lotseng?rd wrote:
> I've not had time to investigate this further (due to sprints planing
> and stuff where I work). I didn't really understand if you also thought
> that maybe connman shouldn't send that DHCP release, if the interface is
> down.
Yes, I though ConnMan should not attempt to send the DHCP release if the
interface is down. Though this could be hard/impossible to get right,
because we never have a consistent view of the system state.
> There is also the possibility to bind the socket to a specific
> interface. setsockopt(..., SO_BINDTODEVICE, ...); I don't know if that
> might solve the problem. Will kernel drop it?
I would suggest try out the socket option approach. As I said, it is
almost impossible to consistently track the state of an interface.
> I will eventually have a better look at this and suggest patches, but my
> first mail was just to inform about the problem, and also check if maybe
> I/we did something stupid and this is how connman should work.
It is likely ConnMan does something stupid. Wouldn't be the first time :)
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 46, Issue 13
***************************************
