> On 02 Sep 2015, at 12:09, Daniel Wagner <[email protected]> wrote: > > On 09/02/2015 11:44 AM, Gianfranco Casanova wrote: >>> On 02 Sep 2015, at 09:10, Daniel Wagner <[email protected]> wrote: >>> On 08/25/2015 04:39 PM, Gianfranco Casanova wrote: >>>> I try to understand better the mechanism of Routing and Source Address >>>> Selection. >>>> >>>> Taking the example I posted, the steps are (what we are doing in Connman): >>>> >>>> Create a "wifi" user >>>> 1. adduser wifi >>>> >>>> Mark packets coming from the wifi user >>>> 2. iptables -t mangle -A OUTPUT -m owner --uid-owner wifi -j MARK >>>> --set-mark 42 >>>> >>>> Apply the Wi-Fi IP address on them >>>> 3. iptables -t nat -A POSTROUTING -o ath0 -m mark --mark 42 -j SNAT >>>> --to-source 10.1.2.3 >>>> >>>> Route marked packets via Wi-Fi >>>> 4. ip rule add fwmark 42 table 42 >>>> 5. ip route add default via 10.0.0.1 dev ath0 table 42 >>>> >>>> Except for point 2. I see this (point 2) as the only way to have the >>>> marked packets with the WiFi address as Source! >>> >>> That is correct and that is what ConnMan is doing (if no bug prevents it) >> >> 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. > >>>> Otherwise I do >>>> understand what packages the NAT table rules are modifying (in our case >>>> we'd have two rules for NAT depending on UID). >>>> >>>> Reading the http://linux-ip.net/html/routing-selection.html as well as >>>> the http://linux-ip.net/html/routing-saddr-selection.html it looks to me >>>> that we can work on "ip route add default via <IP> src" that can really >>>> specify better the Source address (in this case I'd say that even the >>>> NAT is useless). >>> >>> I don't understand what you are saying here. >> >> In the post aforementioned to enforce the SRC, this is added via the >> command "ip route add default via <IP> src”. With this command seems to >> me we can avoid to change it by NAT table after. >> But please, correct me if I’m wrong.> > > The reason why we need to send the packets through SNAT is that the > rerouting lookup will only happen if the packets have been touched by > the SNAT rule. It is a workaround. This is the reason why I was trying to see if the SNAT can also be avoided forcing since the beginning the src correct. > BTW, cgroups allow to attach eBPF since quite recently. With that we > could write an eBPF which sets the marker for all applications in a > given cgroup. The policy routing table would just work fine, no need to > do the trick via SNAT to get through the rerouting. For this I’m not sure it look to me the MARKING can just mark packets if the wrong SRC is used they are not rerouted afterword. > Another nice upside with the eBPF is, we could proper stats on rx/tx per > application. Now we just need someone doing it :) :) > >> P.S.: added conman mail list. > > Yay! :) > > cheers, > daniel _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
