[FS#1425] iproute2: tc qdisc produces incorrect output

[LEDE Bugs]

A new Flyspray task has been opened.  Details are below. 

User who did this - Kevin Darbyshire-Bryant (kdarbyshirebryant) 

Attached to Project - OpenWrt/LEDE Project
Summary - iproute2: tc qdisc produces incorrect output
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - AR71xx - Archer c7 v2

tc qdisc output is producing bizarre output:

tc qdisc
qdisc noqueue 0: dev lo root refcnt 4486716 
qdisc fq_codel 0: dev eth1 root refcnt 4486716 limit 4498840p flows 4536204 quantum 4539856 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
qdisc noqueue 0: dev br-lan root refcnt 4486716 
qdisc noqueue 0: dev eth1.2 root refcnt 4486716 
qdisc noqueue 0: dev br-wifi_guest root refcnt 4486716 
qdisc noqueue 0: dev eth1.15 root refcnt 4486716 
qdisc noqueue 0: dev wlan1 root refcnt 4486716 
qdisc noqueue 0: dev wlan0 root refcnt 4486716 
qdisc noqueue 0: dev wlan1-1 root refcnt 4486716 
qdisc noqueue 0: dev wlan0-1 root refcnt 4486716 


Note refcnt, (and for fq_codel) limit, flows & quantum are all highly unlikely values.  For more curiosity factor, if you ask for json output from tc you get the correct results:

tc -j qdisc 
[{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "lo",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "fq_codel",
        "handle": "0:",
        "dev": "eth1",
        "root": true,
        "refcnt": 2,
        "options": {
            "limit": 10240,
            "flows": 1024,
            "quantum": 1514,
            "target": 4999,
            "interval": 99999,
            "memory_limit": 4194304,
            "ecn": true
        }
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "br-lan",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "eth1.2",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "br-wifi_guest",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "eth1.15",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "wlan1",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "wlan0",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "wlan1-1",
        "root": true,
        "refcnt": 2,
        "options": {}
    },{
        "kind": "noqueue",
        "handle": "0:",
        "dev": "wlan0-1",
        "root": true,
        "refcnt": 2,
        "options": {}
    }
]


That suggests the netlink data transfer mechanism used by iproute2/kernel is okay.  Instead it looks like iproute2 tc's print_uint(PRINT_ANY.... ) functions are broken in some way, possibly only on some architectures.

The print_* functions are pre-processor expanded functions mixed across lib/json_print.c & include/json_print.h found in iproute2.

I'm afraid I can't work out what's going on/wrong here.

 

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=1425