On Mon, Sep 29, 2014 at 12:55 AM, Catalin Patulea <c...@vv.carleton.ca> wrote:
> On Sun, Sep 28, 2014 at 3:34 PM, Hans Dedecker <dedec...@gmail.com> wrote:
>> diff --git a/system-linux.c b/system-linux.c
>> index c4d89be..7f14ca9 100644
>> --- a/system-linux.c
>> +++ b/system-linux.c
>> @@ -1703,6 +1705,29 @@ static int system_add_gre_tunnel(const char *name,
>> const char *kind,
>>
>> nla_put_u8(nlm, IFLA_GRE_TTL, ttl);
>>
>> + if ((cur = tb[TUNNEL_ATTR_TOS])) {
>> + char *str = blobmsg_get_string(cur);
>> + if (strcmp(str, "inherit")) {
>> + unsigned uval;
>> + char *e;
>> +
>> + uval = strtoul(str, &e, 16);
>> + if (!e || e == str || *e || uval > 255) {
> Under what conditions is e set to NULL? I can't find anything about
> that case in strtoul(3) GNU 2011-09-15.
Correct bad copy paste habit from my side; will change it
>
>> diff --git a/system.h b/system.h
>> index e3187fb..b1215d1 100644
>> --- a/system.h
>> +++ b/system.h
>> @@ -28,6 +28,7 @@ enum tunnel_param {
>> TUNNEL_ATTR_MTU,
>> TUNNEL_ATTR_DF,
>> TUNNEL_ATTR_TTL,
>> + TUNNEL_ATTR_TOS,
>> TUNNEL_ATTR_6RD_PREFIX,
>> TUNNEL_ATTR_6RD_RELAY_PREFIX,
>> TUNNEL_ATTR_LINK,
> Any binary compatibility issues here? Do the numerical values of
> TUNNEL_ATTR_x leak out of the netifd binary at any point (perhaps via
> ubus)?
Don't think this is an issue as TUNNEL_ATTR_X are not leaked out of
netifd as blobmsg parsing is string based which is also the case for
ubus
Bye,
Hans
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
