On Thu, 2013-11-07 at 10:05 -0500, Glenn Schmottlach wrote: > >> So it would appear the *last* session that is created will > effectively > >> mark (and clobber) the first marking for the packet (0x101 mark > >> clobbers the earlier 0x100 mark since it's last in the chain). I > hope > >> this is *not* what was intended. I expected that iptable rules for > >> Session policies for the same UID/GID/SELinux context would "share" > >> the same session (and thus statistics). So if two applications > running > >> as the same UID/GID/SELinux context requested a Connman Session, > the > >> first requestor would create it while the second application would > get > >> a "reference" to that session. This session would remain valid > until > >> the last application (with the same UID/GID/SELinux context) > destroyed > >> the session. In a sense the Sessions become reference counted per > >> session policy. As it stands today it would appear Connman creates > far > >> more iptable rules than necessary to support multiple applications > >> running as the same user (or in the same group or SELinux context). > Am > >> I correct in assuming this is a design error in the current > >> implementation of Sessions? > > > > > > You are right. We need to fix this. Patches? :D
Both processes need to be notified separately as they have independently asked that via D-Bus. The approach here is to keep two separate sessions over D-Bus, one for each process, while setting up the netfilter rules only once per matching policy. Cheers, Patrik _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman