Hi Daniel Up to now seems to me that we can define the PreferredTechnologies at “system” level and doing that we can have one ROUTE marked as OnLine and the second one marked as Ready (as we know both usable to go in Internet). If both are marked as Autoconnect I’m expecting that the switching as you mentioned is than done magically.
Is there for the AllowedBearers any PRIO can be defined i.e.: If in the policy file we give for the User the AllowedBearers both Wifi and Eth, with the semantic of WiFi prio respect to the Eth, Which ROUTE is chosen by ConnMan for UID if: 1.\ ETH OnLine WiFi Ready? 2.\ WiFi OnLine ETH Ready? I’m expecting the Route marked as OnLine is all the time chosen, can you confirm? Cheers Gianfranco > On 09 Sep 2015, at 14:52, Daniel Wagner <w...@monom.org> wrote: > > 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 <w...@monom.org >> <mailto:w...@monom.org>> 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 <daniel.wag...@bmw-carit.de >> <mailto:daniel.wag...@bmw-carit.de>> >> 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 <gianfranco.casan...@gmail.com >> <mailto:gianfranco.casan...@gmail.com>> >> --- >> 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 connman@connman.net https://lists.connman.net/mailman/listinfo/connman
