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. [PATCH] rtnl: retry to add ether interface after renaming
      (Dmitry Rozhkov)
   2. [PATCH 0/2] session: fix missing snat and firewall updates
      (Lukasz Nowak)
   3. [PATCH 1/2] session: fix snat firewall not cleaning up
      correctly (Lukasz Nowak)
   4. [PATCH 2/2] session: update firewall and snat on ipconfig
      change (Lukasz Nowak)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Apr 2017 16:48:00 +0300
From: Dmitry Rozhkov <[email protected]>
To: [email protected]
Subject: [PATCH] rtnl: retry to add ether interface after renaming
Message-ID: <[email protected]>

If eth* interfaces are blacklisted to avoid a race condition
where connman may access an interface before systemd/udev can
change it to use a predictable interface name then it's impossible
to re-activate it under a new predictable name because an existing
interface is considered to be already added to the technology.

Once blacklisted an interface is not re-evaluated under a new name.

This patch allows to re-evaluate an interface known to connman for
adding it to the ethernet technology in case it's name has changed.
E.g. after unplugging a cable and plugging it back.

Signed-off-by: Dmitry Rozhkov <[email protected]>
---
 src/rtnl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/rtnl.c b/src/rtnl.c
index 195368d..c76e432 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -471,7 +471,9 @@ static void process_newlink(unsigned short type, int index, 
unsigned flags,
 
                if (type == ARPHRD_ETHER)
                        read_uevent(interface);
-       } else
+       } else if (type == ARPHRD_ETHER)
+               read_uevent(interface);
+       else
                interface = NULL;
 
        for (list = rtnl_list; list; list = list->next) {
-- 
2.9.3



------------------------------

Message: 2
Date: Thu, 20 Apr 2017 16:42:11 +0100
From: Lukasz Nowak <[email protected]>
To: [email protected]
Subject: [PATCH 0/2] session: fix missing snat and firewall updates
Message-ID: <[email protected]>

From: Lukasz Nowak <[email protected]>

Two scenarios have been found where session would not update all tables
it manages:
- snat not removed after a disconnect
- snat and firewall mark not updated after ip config change

Lukasz Nowak (2):
  session: fix snat firewall not cleaning up correctly
  session: update firewall and snat on ipconfig change

 src/session.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

-- 
2.7.4



------------------------------

Message: 3
Date: Thu, 20 Apr 2017 16:42:12 +0100
From: Lukasz Nowak <[email protected]>
To: [email protected]
Subject: [PATCH 1/2] session: fix snat firewall not cleaning up
        correctly
Message-ID: <[email protected]>

From: Lukasz Nowak <[email protected]>

Session snat firewall rules are not being deleted correctly on
a session disconnect. As a result, after many disconnects,
iptables fills up with old snat rules. This can happen, e.g.
when a cellular modem disconnects frequently, and is assigned
a different ip address every time.

This happens because del_nat_rules() depends on
having an ipconfig index stored in the session structure. But
that index is getting cleared by update_routing_table().

Fix this by correcting clean-up call order. Instead of this:
update_routing_table(session);
del_nat_rules(session);
add_nat_rules(session);

do this:
del_nat_rules(session);
update_routing_table(session);
add_nat_rules(session);
---
 src/session.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/session.c b/src/session.c
index dadd68f..bb47a13 100644
--- a/src/session.c
+++ b/src/session.c
@@ -466,12 +466,6 @@ static void cleanup_nat_rules(struct connman_session 
*session)
        del_nat_rules(session);
 }
 
-static void update_nat_rules(struct connman_session *session)
-{
-       del_nat_rules(session);
-       add_nat_rules(session);
-}
-
 static void destroy_policy_config(struct connman_session *session)
 {
        if (!policy) {
@@ -1678,8 +1672,9 @@ static void update_session_state(struct connman_session 
*session)
        DBG("session %p state %s", session, state2string(state));
 
        update_firewall(session);
+       del_nat_rules(session);
        update_routing_table(session);
-       update_nat_rules(session);
+       add_nat_rules(session);
        session_notify(session);
 }
 
-- 
2.7.4



------------------------------

Message: 4
Date: Thu, 20 Apr 2017 16:42:13 +0100
From: Lukasz Nowak <[email protected]>
To: [email protected]
Subject: [PATCH 2/2] session: update firewall and snat on ipconfig
        change
Message-ID: <[email protected]>

From: Lukasz Nowak <[email protected]>

When an ipconfig changes (e.g. from link-local to dhcp), session
needs to update all the tables:
- routing
- firewall marking
- snat
and not just the routing table.
---
 src/session.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/session.c b/src/session.c
index bb47a13..721e4b9 100644
--- a/src/session.c
+++ b/src/session.c
@@ -1900,7 +1900,7 @@ static void ipconfig_changed(struct connman_service 
*service,
                        continue;
 
                if (session->service && session->service == service) {
-                       update_routing_table(session);
+                       update_session_state(session);
 
                        if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
                                ipconfig_ipv4_changed(session);
-- 
2.7.4



------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 18, Issue 16
***************************************

Reply via email to