[LEDE-DEV] [PATCH] netifd-proto.sh: add ip4table & ip6table to `proto_add_dynamic_defaults()`

[Alexandru Ardelean]

On Tue, Sep 5, 2017 at 11:05 PM, Hans Dedecker <dedeckeh at gmail.com> wrote:
> On Tue, Sep 5, 2017 at 1:39 PM, Alexandru Ardelean
> <ardeleanalex at gmail.com> wrote:
>> The `proto_add_dynamic_defaults()` seems to be called mostly
>> in the context of LTE/3G modems (via wwan, qmi, etc) setup.
>>
>> When they get setup, these devices override default routes.
>>
>> However, depending on setup, we want these modems to
>> be part of a another routing table.
>> This change allows that.
>>
>> ip4table/ip6table are of string type in netifd to allow
>> for `default`, `local` routing table names to be specified.
>>
>> Signed-off-by: Alexandru Ardelean <ardeleanalex at gmail.com>
>> ---
>>  scripts/netifd-proto.sh | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
>> index cc7031a..fd7b596 100644
>> --- a/scripts/netifd-proto.sh
>> +++ b/scripts/netifd-proto.sh
>> @@ -26,6 +26,8 @@ proto_add_dynamic_defaults() {
>>         [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute"
>>         [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns"
>>         [ -n "$metric" ] && json_add_int metric "$metric"
>> +       [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
>> +       [ -n "$ip6table" ] && json_add_string ip6table "$ip6table"
> I doubt this is a correct approach as the defaults defaultroute,
> peerdns and metric are common defaults for all IPv4/IPv6 interfaces
> while ip4table is only relevant for IPv4 interface while ip6table only
> for IPv6 interfaces.
> Looking into directip.sh and the usage of proto_add_dynamic_defaults
> this change would add both ip4table but also ip6table (if defined) to
> the dynamic created DHCP interface.
> A better approach would be to add ip4table and ip6table individually
> similar as is done for the extendprefix option (which is also only
> relevant for the DHCPv6 interfaces)
>
> Hans

Thanks for the quick reply.

Will check on your proposed alternative.

Thanks
Alex

>>  }
>>
>>  _proto_do_teardown() {
>> --
>> 2.11.0
>>