On 02/26/2016 09:51 AM, Patrik Flykt wrote:
On Fri, 2016-02-26 at 09:19 +0100, Daniel Wagner wrote:
> So what about something like this:
> rule #2
> __connman_firewall_enable_connection_tracking(struct firewall_context *ctx);
> __connman_firewall_disable_connection_tracking(struct firewall_context *ctx);
Where is this needed? Isn't it something automatically used when
enabling marking with rule #3 below?
Yes, rules #2 is tied to rule #3.
> rule #3
> __connman_firewall_enable_marking(struct firewall_context *ctx,
> enum connman_session_id_type,
> chard *id, uint32_t mark);
> __connman_firewall_disable_marking(struct firewall_context *ctx);
Should we say here which marking to remove or is the ctx per one marking
only? If it's one marking per ctx then subsequent (accidental) calls to
__connman_firewall_enable_marking() need to return -EALREADY or similar.
There is only one mark per session and we use the enable()/disable()
in nice pairs. Obviously adding some sanity checks do not harm,
especially with iptables :)
> rule #4
> __connman_firewall_enable_snat(struct firewall_context *ctx,
> char *ifname, char *addr);
> __connman_firewall_disable_snat(struct firewall_context *ctx);
Should this be called "add interface" with the code figuring out the
address (or am I getting confused which address this is)?
True, we just could hand in the service:
ipconfig = __connman_service_get_ip4config(session->service);
index = __connman_ipconfig_get_index(ipconfig);
ifname = connman_inet_ifname(index);
addr = __connman_ipconfig_get_local(ipconfig);
id = __connman_firewall_add_rule(session->fw, "nat",
"-o %s -j SNAT --to-source %s",
What happens if one combines this function with and only with
rule #1 above?
Good question. I haven't played with hotspot and session at the same
time. rule #1 is installed in the filter table which will be processed
before the nat table.
> Obviously, the naming sucks.
Hmm, let's see. It could be worse, of course :-)
Don't tease me :)