AX3600 and suspicious missing packets in tcpdump

*Before I explain the issue, I want to preface that I am actually using the original CN firmware from the Xiaomi AX3600 with ssh unlocked based on the QSDK tree. I thought this would be the best place to ask this since QSDK is based on OpenWRT and there were other people in the forum with the same device.

Basically, I am trying to capture traffic on my iPhone passing through a VPN, to my router using tcpdump on br-lan but when I did it, no packets were logged except for the few ARPs and airplay:

22:49:43.079051 ARP, Reply iPhone is-at xx:xx:xx:xx:xx:xx (oui Unknown), length 28
22:49:43.079051 ARP, Reply iPhone is-at xx:xx:xx:xx:xx:xx (oui Unknown), length 28
22:50:19.057546 ARP, Request who-has XiaoQiang tell iPhone, length 28
22:50:19.057546 ARP, Request who-has XiaoQiang tell iPhone, length 28

I thought I used the tcpdump wrong but even with different parameters such as -vv -n -i any -p, I still couldn't get any VPN packets from my iPhone. I started doubting that something was wrong with the router so I tried tethering my Android phone network to my iPhone, and as expected, it captured the VPN packets using the Android tcpdump without any parameters. I thought this was really suspicious since this was as if the VPN packets were routed through some secret interface or maybe somehow bypass the pcap capture. Note that on the packets captured on my Android device, the packets are going to the ms-SQL-s port or 1433. Even if I try to specifically listen for that port, I was not able to get anything on my router. Some help would be appreciated!

They are offloaded to the NSS.

1 Like

Hey, thank you so much for the reply. I have seen you quite often on the porting AX3600 to OpenWRT thread so I really appreciate you taking the time to answer my thread.

I am not too familiar with NSS routing so I was wondering if there were any resources on that. I ran a IP route on the router and didn't notice any particular routing, except for 192.168.31.0/24 dev br-lan proto kernel scope link src 192.168.31.1 and even that does not seem anything out of the ordinary. I am thinking that there must be a way to disable the offloading or maybe to force tcpdump to capture them as the packets have to reach the router before being processed and offloaded to NSS (right?). Any resources would be greatly appreciated!

@sunbinyuan, welcome to the community!

Because you should be monitoring the WiFi interface.

No. For official support for your device, see:

1 Like

Thanks for the reply.

I also tried that while fiddling with the tcpdump parameters but to no avail. Also, wouldn't the -i any also include the wifi interfaces?

I read through the two sections and I am not quite sure I understood the meaning since there doesn't seem to be any device specific subforum on this site. Please let me know if I misunderstood your comments, thanks!

No, -i includes the interface you specify after the argument.

???

They have a forum like OpenWrt...only thing is, it's their firmware!

You'll get better answers there. It even explains where to get help for their supported software (i.e. the router firmware).

Thanks for the reply again.

I might be wrong but I think the any identifier matches any of the interfaces.

I am a bit confused here since the link you sent seems to be a forum about the XWiki software which doesn't seem to have anything to do with firmware haha.

After a bit of research on NSS, I came across a slide on netfilter where they which describes the routing of packets on a NSS firmware:

.

It seems to me that VPN packets are matching the offloading route which is why they never actually reach the Linux net stack, where the tcpdump capture happens. However, it would seem that it is possible to actually modify the rules to force all the packets to go to the Linux net stack. I tried looking on the /etc/config/firewall file and stumble upon this entry:

config include 'qcanssecm'
        option type 'script'
        option path '/etc/firewall.d/qca-nss-ecm'
        option family 'any'
        option reload '1'

The loaded script is the following:

ecm_type=`uci -q get ecm.global.acceleration_engine`
if [ $ecm_type = "nss" -o $ecm_type = "auto" ]; then
        chk=$(iptables -L FORWARD 2>/dev/null | grep -c 'PHYSDEV')
        if [ $chk -lt 1 ]; then
                iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
        fi
        ipv6_fw_disable=$(uci -q get firewall.@defaults[0].disable_ipv6)
        chk6=$(ip6tables -L FORWARD 2>/dev/null | grep -c 'PHYSDEV')
        if [ $chk6 -lt 1 -a "$ipv6_fw_disable" = "0" ]; then
                ip6tables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
        elif [ "$ipv6_fw_disable" = "1" ]; then
                ip6tables -D FORWARD -m physdev --physdev-is-bridged -j ACCEPT 2>/dev/null
        fi
else
        iptables -D FORWARD -m physdev --physdev-is-bridged -j ACCEPT 2>/dev/null
        ip6tables -D FORWARD -m physdev --physdev-is-bridged -j ACCEPT 2>/dev/null
fi

The script tries to perform a check on the uci -q get ecm.global.acceleration_engine and depending on its type, it would apply different iptable rules. Interestingly, on the AX3600, the acceleration engine I get is sfe-cm which doesn't match any of the engine in the first if block, thus only the second block is applied. However, the only thing that the second block performs is to remove some FORWARD rules that don't seem to cause the NSS offloading.

Some clarifications would be greatly appreciated!

@Crect made fun of me instead of looking at their site and realizing it was support for your firmware. I responded with all the information and references regarding your firmware and their support there, with all past references to seeking them for support:

As you can see in the "Need help? section at https://wiki.codeaurora.org/xwiki/bin/QSDK/ -

screen144

You just don't get it. Xwiki is a wiki software. Codeaurora is using it for their own wiki like probably thousands of others.

When you look at the xwiki forums, you'll see it's just for the wiki software but not affiliated with codeaurora in any way man.

Hey @lleachii, thanks for the reply. I think this is probably the link you wanted to send me

since XWiki is simply software that they use to host their wiki as @Crect mentioned. As shown in your picture, the help section was about the XWiki software, and not QSDK (I would assume that it is the default sidebar text displayed by any new XWiki wiki). This being said, I was unfortunately not able to find a forum about QSDK to ask my question, thus I still believe this is the best place to ask my question.

Sidetacks aside, I was actually able to find a solution to my issue for now. It seems that there is a service with the same name qca-nss-ecm that is being started which manages the routing of packets to the NSS processors. Using service qca-nss-ecm stop, I was then able to stop the routing of those packets thus see the VPN packets in tcpdump. I'll try to investigate a bit more on the possibility of capturing the accelerated packets without disabling the NSS service.