*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:
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!
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!
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!
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.
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.
@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:
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.
