TC Slicing not applying to the intended class – all traffic goes to default slice

[ELENA VENTURA]

Hello!

I’m running some slicing experiments in Mininet-WiFi using tc (htb).

I’ve set up a simple topology with 4 stations and 1 access point. On the AP interface (ap1-wlan1), I configured a root qdisc with two slices:

• 1:30 → the default slice

• 1:20 → a slice where the other three stations should send traffic (based on IP filters)

Then, I started an iperf test:

sta4 iperf3 -s & 

sta2 sh -c "echo 'START: ' \$(date +%T) | tee sta2.log; iperf3 -c 10.10.10.4 --bidir -t 10 -i 2 | tee -a sta2.log; echo 'END: ' \$(date +%T) | tee -a sta2.log"

However, when checking the class statistics on ap1, I noticed that no packets go through class 1:20, and all traffic is going through the default slice 1:30, as shown here:

mininet-wifi> ap1 tc -s class show dev ap1-wlan1 

class htb 1:20 parent 1:1 leaf 20: rate 2Mbit ceil 2Mbit 

Sent 0 bytes 0 pkt class htb 1:30 parent 1:1 leaf 30: rate 512Kbit ceil 512Kbit Sent 1025195 bytes 1284 pkt (dropped 57, overlimits 1262)

Here is the full script I used to configure the slices and filters:

#!/bin/bash

tc qdisc del dev ap1-wlan1 root 2>/dev/null

tc qdisc add dev ap1-wlan1 root handle 1: htb default 30
tc class add dev ap1-wlan1 parent 1: classid 1:1 htb rate 4mbit ceil 4mbit

# DEFAULT slice
tc class add dev ap1-wlan1 parent 1:1 classid 1:30 htb rate 512kbit ceil 512kbit
tc qdisc add dev ap1-wlan1 parent 1:30 handle 30: pfifo limit 100

# NON-PRIORITARY slice
tc class add dev ap1-wlan1 parent 1:1 classid 1:20 htb rate 2mbit ceil 2mbit
tc qdisc add dev ap1-wlan1 parent 1:20 handle 20: pfifo limit 100

# Filter rules for slice 1:20

tc filter add dev ap1-wlan1 protocol ip parent 1:0 prio 1 u32 \
  match ip src 10.0.0.2 match ip dst 10.0.0.4 flowid 1:20

tc filter add dev ap1-wlan1 protocol ip parent 1:0 prio 1 u32 \
  match ip src 10.0.0.4 match ip dst 10.0.0.2 flowid 1:20



Despite this setup, none of the traffic is being classified into slice 1:20. Everything goes through the default slice instead.

Any idea what I might be missing? 
Thanks in advance for your help!

Best regards,
Elena

[Ramon Fontes]

Given that tc handles ingress traffic, it seems you're not utilizing ifb: https://wiki.linuxfoundation.org/networking/ifb.

--
You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/597534f3-d48f-4db3-80cc-84f5cf629c1en%40googlegroups.com.

[ELENA VENTURA]

Thank you for your previous reply.

Sorry to bother you, but I’m trying to fully understand a behavior I encountered while working with tc in Mininet-WiFi.

I’ve already read about IFB and I understand it’s useful to manage ingress shaping (since tc normally works only on egress). However, my current issue seems different.

In my setup, I have an AP with HTB configured with two classes:

• 1:30 → default slice (limited to 512Kbit)

• 1:20 → target slice for selected stations (limited to 2Mbit)

I’ve installed u32 filters to direct traffic to class 1:20 based on IP source/destination. However, all traffic always ends up in the default slice (1:30). The shaping works there — packets are limited correctly — but they never get matched by the filters and never go through 1:20.

From what I can tell, the filters should be correct. Yet, once a flow fails to match any filter, it’s sent to the default class, and it never tries to match any other slice.

Could it be that a single mismatch (e.g. one direction not matching) causes the entire bidirectional flow to be handled by the default class?

Or is there something deeper I may be missing in how tc handles packet classification?

Thanks so much for your time and for all the amazing work on Mininet-WiFi.

Best regards,

Elena

[Ramon Fontes]

> Sorry to bother you, but I’m trying to fully understand a behavior I encountered while working with tc in Mininet-WiFi.

There’s something important I’d like to point out: this is an issue you encountered while working with tc in Mininet-WiFi, but it’s something you might also encounter in real-world setups. Mininet-WiFi uses real-world applications, and Wi-Fi introduces specific challenges that can lead to situations like this. For example, switches typically have separate interfaces for ingress and egress traffic, while access points (APs) usually have a single wireless interface that handles both ingress and egress. This can affect how traffic control behaves. I believe the examples/simplewifitopology.py script could be helpful for your case, as it includes client isolation (a feature provided by hostapd), which may align with your use case.

> Thanks so much for your time and for all the amazing work on Mininet-WiFi.

Thank you :)

Please try examples/simplewifitopology.py and let me know what happens.

To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/c58be58d-6cbd-4857-8c3b-0743ded743f6n%40googlegroups.com.

[ELENA VENTURA]

  Thank you very much! I really appreciate the explanation — I’ll also look into how to apply IFB as part of the solution.

[ELENA VENTURA]

I'm trying to enable IFB (Intermediate Functional Block) support in Mininet-WiFi to handle ingress traffic shaping, as suggested in previous discussions in this group.

In my script I use:

net.useIFB()

But I get the following error:

AttributeError: 'Mininet_wifi' object has no attribute 'useIFB'

I installed Mininet-WiFi from the official GitHub repo about 4 months ago, but it seems the useIFB() method is not defined in my net.py file. I also checked using grep and confirmed the method is missing.

Has this method been removed?
Or is it only available in a specific branch or fork?

I'm currently working on bandwidth slicing experiments using tc and would really like to handle ingress shaping properly. If anyone has an updated version of the code with working useIFB() or knows how to enable it manually, I'd really appreciate your help.

[Ramon Fontes]

Did you try examples/simplewifitopology.py with the client isolation?? 

To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/e7305697-3a70-4752-b277-cdb985f448c9n%40googlegroups.com.

[ELENA VENTURA]

Yes, I’ve already tried using simplewifitopology.py several times, but it doesn’t implement the kind of topology I’m aiming for, so I’d prefer to stick with something similar to position.py. That’s where I’d like to implement IFB, as you previously suggested. Unfortunately, client isolation is not suitable for what I need to do, since I need the clients to actively compete for bandwidth.  

[Ramon Fontes]

> Yes, I’ve already tried using simplewifitopology.py several times, but it doesn’t implement the kind of topology I’m aiming for, so I’d prefer to stick with something similar to position.py.

You can then use any of the scripts (including yours with client isolation)

> Unfortunately, client isolation is not suitable for what I need to do.  

You actually don't need IFB. I think this only works with client isolation.

> since I need the clients to actively compete for bandwidth

A brief description of the client isolation:

# Client isolation can be used to prevent low-level bridging of frames between 

# associated stations in the BSS. By default, this bridging is allowed. 

#ap_isolate=1

source: https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf

To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/57e76c95-c7f8-4bed-8e89-2032f00c1234n%40googlegroups.com.