Hi Gianfranco, I know the mail server settings are pretty stupid because Reply-All doesn't work for this mailing list.
Please try to remember to add the mailing list. On 07/27/2015 01:30 PM, Gianfranco Casanova wrote: > Hi Daniel > > Thanks for the analysis. I’m not sure to have understood your > explanation correctly. > Please find my doubts inline. Those are mainly related to the NAT vs > Routing Policy. > >> On 24 Jul 2015, at 16:03, Daniel Wagner <w...@monom.org >> <mailto:w...@monom.org>> wrote: >> >> I figured out the main problem: >> >> (local process) -> (routing decision) -> [raw:output] -> >> contrack -> [mangle:output] -> (reroute check) -> >> [nat:output] -> [filter:output] -> ... >> >> When the local process generates a packet, the network stack >> takes the routing decision really early on. In our case earlier >> then we are able to mark with iptables the packets. That happens >> in the mangle table and therefore the policy routing table is >> not considered at this point. > > Where in the chain the policy routing table is acting? In the (reroute > check) block? The routing decision is taken as one of the first steps in the network stack. That applies to normal routing or policy routing. > Are you referring to the action of marking the package, triggered by the > ConnMan, with the following command depending on UID | GID i.e.: > iptables -t mangle -A OUTPUT -m owner [--uid-owner|--gid-owner] > $OWNER -j MARK --set-mark $MARK ? Yes, the order is: 'routing decision' followed by 'marking packets'. Clearly this is in the wrong order. >> My naive assumption was that the reroute check would be done >> unconditionally. Unfortunately, this is not true. > > What do you mean with this assertion? That the path: > [mangle:output] -> [nat:output] -> [filter:output] -> (reroute check) -> > Is not followed all the time by all packages? My assumption was that the rerouting decision is unconditionally executed. Only packets which have been touched by a rule in the mangled table will rerouted. >> The reroute check is only done if the packet was modified in >> the mangle output chain. So for example if you look at a simple >> ping the code path relevant to route is: >> >> net/ipv4/ping.c: >> ping_v4_sendmsg() >> ip_route_output_flow() > > Does this means that the PING with any NAT, MANGLE & all. table modified > is following the: > (local process) -> (routing decision) ->(xfrm lookup) path? I picked a random entry point. I think this is true for all protocols, so yes. >> net/ipv4/netfilter/iptable_mangle.c >> ipt_mangle_out() >> ip_route_me_harder() >> ip_route_output_key() >> ip_route_output_flow() > > Does this means that once only a MANGLE (OUTPUT) table is modified the > packages are not necessarily flowing to all the: > [nat:output] -> [filter:output] -> (reroute check) chain? Packets which have been modified by an mangle rule are rerouted. Only those. >> That means the NAT rule is necessary, e.g. >> >> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.1.100 > > The NAT rule at my eyes is just enforcing the source specific IP address > i.e. this address is “appended” to the packages. I see this phase > important once a reply is wait. In other word for me even whiteout the > NAT rule applied, the packages are going on Internet but no way to > guarantee to receive any reply back if the IP address is not appended > correctly. Is also your opinion? The rule needs to match the current IP configuration. So this is not a static rule. > Seems to me you are saying that: changing the NAT table (POSTROUTING), > we are implicitly enabling the last part of the PATH containing also the > reroute check. Is my understanding correct? Yes. >> The policy routing table is not completely useless. > > Are you considering “policy routing” the following commands: > > 1. ip rule add fwmark 1234 table 1234 > 2. ip route add default via 1.2.3.4 dev wlan0 table 1234 Yes. > If yes, for me those are mandatory to instruct which interface has to be > used by the specific application. If not, which messages are you > considering useless (policy routing)? 'fwmark' wont match any packets if SO_MARK is not set. Remember the marking happens _after_ the fwmark lookup. >> For example the >> process could mark its packet on its own. Another possible way is to >> have a cgroup controller setting the SO_MARK or we teach the policy >> routing table to match on sk_classid (cls cgroup controller). > > Even having applications capable to MARK their packages, the rules for > Policy Routing are mandatory to define which route have to be applied > (if for Policy Route we are considering the point 1. and 2. in the > previous numerated list). If the application set the SO_MARK (some might say this is not going to be secure because you need CAP_NET_ADMIN) or you have a cgroup controller doing this for you. In both cases the marker/magic value (fwmark) needs to be exposed via the Session D-Bus API. We had that in the past but dropped it since the missing pieces in the kernel are still missing upstream. Doesn't have to stay this way though. Patches are always highly appreciated. >> Back to original problem. I am preparing a patch for adding >> the missing NAT rules which should fix this problem. > > As soon as those are ready, I’d test the new ConnMan! Glad to hear. Almost done. Need to do some finishing but looks good so far. > Is there any WIKI in ConnMan? I think can be good prepare an HowTo. I don't think there is an official wiki. Though I assume Patrik takes howto documentation for the official website. >> Obviously, we don't need both the policy routing table and the >> NAT rules. But I am reluctant to rip out the policy routing code at this >> point. Maybe someone is using it already. > > For this I need to understand what you are considering for “policy routing”. I hope I could answer this question above. cheers, daniel _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
