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: VLAN configuration support (Daniel Wagner)
2. Re: [PATCH] wifi: verify that wifi->network is not null
before using (Daniel Wagner)
3. Re: How to use connman with a DSA? (Daniel Wagner)
4. Re: [PATCH] service: Group online functions (Daniel Wagner)
5. Re: [PATCH 0/2] commandctl: handle error case more gracefully
(Daniel Wagner)
6. Re: [PATCH v2 1/1] service: Start online check on IP address
update (Daniel Wagner)
7. Re: Re: VLAN configuration support (Langlois, Maxime)
8. Re: VLAN configuration support (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Apr 2019 09:05:37 +0200
From: Daniel Wagner <[email protected]>
To: "Langlois, Maxime" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: VLAN configuration support
Message-ID: <20190404070536.npdbcgstqlhoslve@beryllium>
Content-Type: text/plain; charset=us-ascii
Hi Maxime,
On Tue, Apr 02, 2019 at 01:01:46PM +0000, Langlois, Maxime wrote:
> I need to assign a static link-layer address on eth0.1 and use dhcp on
> eth0.2. I know we assign a configuration to a specific interface using
> the MAC address, but as the vlan's interfaces have the same MAC address
> as the actual physical interface, is it possible to match a
> configuration to a specific vlan interface?
You are right. Currently the only way ConnMan matches the config
entries against the interfaces is by using the MAC Address. Adding
another way to reliable match them isn't that hard to add. I just
don't know if there is a good/reliable way to identify the VLAN
interfaces.
Maybe with SIOCGIFPFLAGS could help here. Just an idea.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 4 Apr 2019 09:11:21 +0200
From: Daniel Wagner <[email protected]>
To: Henrik Persson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH] wifi: verify that wifi->network is not null
before using
Message-ID: <20190404071121.p5t4xvghvrjycq6c@beryllium>
Content-Type: text/plain; charset=us-ascii
Hi Henrik,
On Tue, Apr 02, 2019 at 02:50:33PM +0000, Henrik Persson wrote:
> In disconnect_callback() wifi->network is used, but it seems that
> callback can arrive without wifi->network being set. The call to
> connman_network_set_connected(wifi->network, false) will then be
> called and deref that null pointer, making connman crash.
>
> So, don't call connman_network_set_connected() if wifi->network is
> null.
The patch didn't apply directly. It looks like your creating the
patches against an older version of ConnMan.
Anyway, the patch is applied and pushed.
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 4 Apr 2019 09:15:34 +0200
From: Daniel Wagner <[email protected]>
To: Brian Hutchinson <[email protected]>
Cc: [email protected]
Subject: Re: How to use connman with a DSA?
Message-ID: <20190404071533.4iha5hbgoz6wvj7n@beryllium>
Content-Type: text/plain; charset=us-ascii
Hi Brian,
On Tue, Apr 02, 2019 at 03:08:10PM -0400, Brian Hutchinson wrote:
> Searched the archives and while I see Connman is supposed to support DSA,
> not quite sure how to configure it or why it won't see our Marvell switch
> interfaces.
What is DSA? I read 'Das schwarze Auge' which is unlikely the right thing :D
> I have an interface called ethmv4 but connman doesn't appear to see it.
> Our TI processor has two EMAC interfaces. eth0 is or local private port,
> eth1 is connected to a 4 port Marvell switch.
>
> When I do 'connmanctl services' I see:
>
> *AR Wired ethernet_74e1828f3f79_cable
> *Ac Wired ethernet_74e1828f3f78_cable
>
> ... and that's it.
>
> Any clues how I can make profile for ethmv4 so I can specify if this wired
> interface is static or dhcp?
If I understood your question correctly, you can provision the
interface by creating a couple of config files. Usually they are
stored in /var/lib/connman/*. Check the doc/config-format.txt file for
more info.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 4 Apr 2019 09:17:04 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH] service: Group online functions
Message-ID: <20190404071704.rxklduxql24c6s7e@beryllium>
Content-Type: text/plain; charset=us-ascii
Patch applied.
------------------------------
Message: 5
Date: Thu, 4 Apr 2019 09:18:08 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH 0/2] commandctl: handle error case more gracefully
Message-ID: <20190404071807.qjjrmlqkliwwbags@beryllium>
Content-Type: text/plain; charset=us-ascii
Both paches applied.
------------------------------
Message: 6
Date: Thu, 4 Apr 2019 09:21:33 +0200
From: Daniel Wagner <[email protected]>
To: Robert Tiemann <[email protected]>, [email protected]
Subject: Re: [PATCH v2 1/1] service: Start online check on IP address
update
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Robert,
On 4/1/19 10:53 AM, Robert Tiemann wrote:
> On 4/1/19 8:26 AM, Daniel Wagner wrote:
>> On 3/28/19 1:18 PM, Robert Tiemann wrote:
>>> This patch enables ConnMan to enter online state after getting IP
>>> configuration via DHCP when coming from an IPV4LL configuration.
>>
>> Patch applied. I saw we could drop the start_online_check() forward
>> deceleration by reordering. I'll send a patch for this.
>
> Thank you. I did the forward declaration to keep the patch small,
> thanks for cleaning this up. :) Current master + your patch works
> well here.
Thanks for the testing and the feedback!
Daniel
------------------------------
Message: 7
Date: Thu, 4 Apr 2019 13:05:34 +0000
From: "Langlois, Maxime" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Re: VLAN configuration support
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
couldn't we use the interface name for matching? That seems a reliable
way to me.
I am developing an embedded software and when deploying the software in
production, the only thing that I know for sure will match is the
interfaces name, as the MAC addresses will obviously be different from
board to board.
Currently, if I wanted to release my software with connman, I would
have to add a script running before connman starts in order to tweak
the config file to put the board specific MAC addresses in there, so I
end up with the expected config. And I would get the correct MAC using
the interfaces name!
I guess I am missing something because I don't understand why it is not
already supported!
Thanks for your answer,
Maxime
------------------------------
Message: 8
Date: Thu, 4 Apr 2019 20:47:47 +0200
From: Daniel Wagner <[email protected]>
To: "Langlois, Maxime" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: VLAN configuration support
Message-ID: <20190404184747.e3lrj6vu7pj2mtqc@beryllium>
Content-Type: text/plain; charset=us-ascii
Hi Maxime,
On Thu, Apr 04, 2019 at 01:05:34PM +0000, Langlois, Maxime wrote:
> couldn't we use the interface name for matching? That seems a reliable
> way to me.
In the past some argued that only the MAC address is kind of reliable
to match. Obviously, this is not really true. Changing a MAC address
is as simple has changing an interface (udev rules).
> I am developing an embedded software and when deploying the software in
> production, the only thing that I know for sure will match is the
> interfaces name, as the MAC addresses will obviously be different from
> board to board.
This seems to be a common use case for embedded systems. So yes, I
agree we should just add an additional match for the interface names.
Care to send a patch?
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 42, Issue 4
**************************************
