QoS map not getting updated in the kernel

[shergillg]

I am using rtnl_link_vlan_set_egress_map() to update the qos map for an existing VLAN link/interface in the kernel. The code shown below executes without any failures but qos mapping on the interface in the kernel remain the same.

        /* Let's find the link we are interested in. */                                   
        link = rtnl_link_get_by_name (link_cache, ifname);                                
        if (link == NULL) {                                                               
            printf ("Link not found in cache.\n");                                        
            return -1;                                                                    
        }
                                                                  
        /* Alloc a new vlan link and make the change to it. */                        
        change = rtnl_link_vlan_alloc();                                              
                                                                                      
        rval = rtnl_link_vlan_set_egress_map (change, qos_from, qos_to);              
        if (rval < 0) {                                                               
            printf ("Error: rtnl_vlan_set_egress_map() call failed. rval=%d\n", rval);
            return -1;                                                                
        }                                                                             
                                                                                      
        /* Now apply the change to the actual link. */                                
        rval = rtnl_link_change (sk, link, change, 0);                                
        if (rval < 0) {                                                               
            printf ("Error: rtnl_link_change() call failed. rval=%d\n", rval);        
            return -1;                                                                
        }

To confirm that "change" is getting applied to "link", I also tried calling rtnl_link_vlan_get_egress_map() after the call to rtnl_link_change(). That confirmed that qos map "change" is making it on to the "link". But the update is not making it to the kernel.

What am I missing or doing wrong here ? Do rtnl_link_vlan_set_*() APIs not work on existing VLAN links ?

[thom311]

I don't know the answer to your question.

As hints for debugging:

• check whether libnl sends the requested settings on the netlink socket. Possibly run the test program with strace.
• review the libnl3 code, that it does what you expect it to do.
• find a ip link command that does what you aim to do. Then compare what this command writes to the netlink socket (e.g. using strace or code review).

[shergillg]

I captured the request message sent by ip link command and a simple program trying to do the same.

Here is the request with ip link:

sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12,
 msg_iov=[{iov_base=[{nlmsg_len=64, nlmsg_type=RTM_NEWLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=1745091821, nlmsg_pid=0},
  {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=if_nametoindex("v100"), ifi_flags=0, ifi_change=0},
   [{nla_len=32, nla_type= IFLA_LINKINFO}, [[{nla_len=8, nla_type=IFLA_INFO_KIND}, "vlan"...],
    [{nla_len=20, nla_type=IFLA_INFO_DATA}, "\x10\x00\x03\x00\x0c\x00\x01\x00\x01\x00\x00\x00\x05\x00\x00\x00"]]]], iov_len=64}],
 msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64

And here it is with a simple program calling rtnl_link_change() as shown above:

sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12,
 msg_iov=[{iov_base=[{nlmsg_len=68, nlmsg_type=RTM_NEWLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2549876496, nlmsg_pid=-1471012447},
  {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=if_nametoindex("v100"), ifi_flags=0, ifi_change=0},
   [{nla_len=36, nla_type=NLA_F_NESTED|IFLA_LINKINFO}, [[{nla_len=9, nla_type=IFLA_INFO_KIND}, "vlan"],
    [{nla_len=20, nla_type=NLA_F_NESTED|IFLA_INFO_DATA}, "\x10\x00\x03\x80\x0c\x00\x00\x00\x02\x00\x00\x00\x06\x00\x00\x00"]]]], iov_len=68}],
  msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 68

Looking closely at the two calls I see following differences:

1. The whole request size is 4-bytes less with ip link (64-bytes vs 68-bytes). The nla_type=IFLA_INFO_KIND is 8-bytes for ip link and 9-bytes in the other case but the content appears to be the same. So, I don't get why the difference in size.
2. The ip link request doesn't have NLA_F_NESTED flag set. I don't know why it's set in one case and not set in the other.
3. Finally, the nla_type=IFLA_INFO_DATA payload is also different. I can confirm that both have the correct QoS "from" and "to" values (from=1 and to=5). IOW, the QoS data that I pass on the command line is going thru to the kernel in both the cases. However, only with ip link the QoS values are actually getting applied. In both the case Kernel responds that the request succeed.

1. IP cmd : "\x10\x00\x03\x00\x0c\x00\x01\x00\x01\x00\x00\x00\x05\x00\x00\x00"
2. My code: "\x10\x00\x03\x80\x0c\x00\x00\x00\x01\x00\x00\x00\x05\x00\x00\x00"

First 16-bits is the len and is the same for 1 and 2. Following 16-bits, I believe is a flag, it has IFLA_VLAN_EGRESS_QOS set for both, which makes sense, and has NLA_F_NESTED for 2. After that byte-6 is different but I don't know why.

Given this data, are you able to say more about what might be going on here ? or what to try next ?

[cpaasch-oai]

I tried to repro this issue and am unable to.

It looks to me like dd0889f fixed the problem. @shergillg did you have this issue with the mentioned commit included ?