Hi Gianfranco, The default autoconnect algorithm will do its 'magic' in this case. I can't remember all details out of the head but we have some documentation on the default behavior.
So now we are coming back to the policy plugin I was mentioning at the beginning of our discussion. If the default behavior of autoconnect is not suiting your use case you can overwrite it by providing a policy plugin for this. If it turns out you need a plugin we could try to fixup the proof of concept plugin I wrote for GENIVI. Maybe it turns out the be acceptance even for upstream. cheers, daniel On 09/09/2015 02:38 PM, Gianfranco Casanova wrote: > Hi Daniel > > I'll test it as soon as I can and let you know. I've got an other > question for you all: Considering the new ConnMan with the routing > problem solved, I do not see how we can deal with the following Use Case: > User A can use both ETH and WiFi. Which is the preferred route chosen by > ConnMan in this case? Is the first one declared in the PolicyFile? > If User A is going via internet through WiFi and the WiFi is dropped > out, is the ConnMan automatically re routing the internet traffic via > ETH for User A? > > Thanks in advance for the support > Gianfranco > > On Thu, Sep 3, 2015 at 3:19 PM, Daniel Wagner <[email protected] > <mailto:[email protected]>> wrote: > > >>> There is a difference respect what we were discussing i.e.: -m mark > --mark 42 is also in the point 3. > >> > >> Ah I see. So we are not using the mark matcher. Yes, that makes sense. > >> When I was testing it without the mark matcher it did work for me. I > >> looked at the tcmpdump. > > > > I can confirm that whiteout the mark matcher Connman 1.29 + patch is > > also working on my side but it looks to my only by chance, there is > > no match between marked packets with the device and as a consequence > > with the SRC to be changed. > > Can you test the patch below? With that we should at least solved > the routing. If I understood you correctly, we still need to figure > out why rp_filter sometimes needs to be disabled. > > > > From 2df313ec4dac570dc378fc70a7a5f6307cd48e2e Mon Sep 17 00:00:00 2001 > From: Daniel Wagner <[email protected] > <mailto:[email protected]>> > Date: Thu, 3 Sep 2015 15:17:27 +0200 > Subject: [PATCH] session: Install SNAT rule with mark matcher > > Filter the packets based on the marker and update > only their routing. > > Reported by: Gianfranco Casanova <[email protected] > <mailto:[email protected]>> > --- > src/session.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/session.c b/src/session.c > index 388aae7..8b695ab 100644 > --- a/src/session.c > +++ b/src/session.c > @@ -405,8 +405,8 @@ static void add_nat_rules(struct connman_session > *session) > addr = __connman_ipconfig_get_local(ipconfig); > > id = __connman_firewall_add_rule(session->fw, "nat", > "POSTROUTING", > - "-o %s -j SNAT --to-source %s", > - ifname, addr); > + "-o %s -m mark --mark %d -j SNAT --to-source > %s", > + ifname, session->mark, addr); > g_free(ifname); > if (id < 0) { > DBG("failed to add SNAT rule"); > -- > 2.4.3 > > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
