MediaTek Wireless Etherent Dispatch and HW Offload Questions

I see the following [examples] when I run cat /sys/kernel/debug/ppe0/entries - they appear to be wireless entries, as:

  1. there's currently no wired client traffic
  2. the MAC always seems to be 00:00:00:00:00:00 - and
  3. They never appear at /sys/kernel/debug/ppe0/bind
#From Internet to WAN port (DST ?):
002f6 UNB IPv4 5T orig=3.167.xxx.xxx:443->yyy.yyy.yyy.yyy:57181 new=38.0.64.64:48382->47.55.122.0:20999 eth=00:00:00:00:00:00->00:00:00:00:00:00 etype=0000 vlan=0,0 ib1=10001e0a ib2=0000005f packets=0 bytes=0

#From WAN6 to LAN2
0033c UNB IPv6 5T orig=2a01:b740:1362:0002:0000:0000:0000:0009:443->2600:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:65423 eth=00:00:00:00:00:00->00:00:00:00:00:00 etype=0000 vlan=0,0 ib1=5a00010d ib2=00000000 packets=0 bytes=0

#From LAN1 (VLAN 1) to LAN2 (VLAN 3)
012f2 UNB IPv4 5T orig=192.168.1.xxx:41484->192.168.255.xxx:554 new=32.1.4.112:2560->224.207.190.239:10239 eth=00:00:00:00:00:00->00:00:00:00:00:00 etype=7f47 vlan=10506,0 ib1=10001e0e ib2=11419001 packets=0 bytes=0
  • What are these odd "new" IP address/port combinations?
  • Why does the VLAN read '0,0` and '10506,0' in these entries?
  • What are ib1, ib2?
  • Why are no packets/bytes listed?
  • What do the first hextets mean preceding "UNB"
  • Does UNB mean "Unicast Non Broadcast"?
  • 5T - what does it mean?
  • Should these show up in the /sys/kernel/debug/ppe0/bind too (they don't)?

@nbd

We both have same source code...

2 it is filled on egress
3 try conntrack -L -u offload

A the real conmection from public ip to web server
B It is dsa-not-really-ethernet-but-vlan
C offset of ct transform data
D maybe ABI is 1 version off from backend
E id in soft offload table (not ct id)
F No idea
G five-element tuple
H No idea

Basically hw offload is small lru always backed by soft offoad
Soft offload is big and by sysctl timer returns to...
Normal conntrack till a new flow add statement restarts the cycle
Ayay?

1 Like

The "new" IPs are invalid (notice one ends in x.x.x.0 - another is a Class D, multicast). Additionally, in the third LAN-to-LAN example, the old and new IPs are in fact the same (on network) - at least they should be.

Even if I managed to read it, I donno where to [easily] locate it.

That procfs file is more or less garbage, you have better chance looking at it from high level side.

1 Like