Adding OpenWrt support for Arcadyan WE420223-99 (KPN Experia WiFi)

For Developers
6

For development, booting through TFTP can be handy. The U-Boot can load and start a kernel through TFTP but the process is a bit annoying. The code tries to do some TRX verification but hangs/fails. Luckily, the function can be patched at runtime to skip the verification. I've made a ckermit script to easily boot it: https://gist.github.com/hberntsen/9bfd7e9c25948c796656fc0ab802d6c9
Just run a TFTP server at 192.168.11.2

If you want to play with the kernel arguments, the way OpenWRT compiles the Linux kernel prevents it from loading them from U-Boot. After changing that through make kernel_menuconfig you can set the bootargs U-Boot environment variable.

1 Like
7

I welcome you here :smiley:

It looks like this device is also with U-boot Arcadyan password, but the hash is different from MTS & Flash.

Can you describe in more detail the actions of LEDs on OEM firmware?) Based on this, I think it will be easier to offer solutions)

Can you post a spi-nor dump or mtd partition backup? Or you can send it in a private message.

1 Like
8

I've looked at the manual for the LEDs, it says:

  • Power: Green when on (I've got that working in OpenWRT ;))
  • WiFi: will blink green and turn blue when WiFi is available.
  • WPS: on when WPS is enabled
  • Followme: Lights up green when a device is connected.
9

It also has to do with your device)

10

Nice! Will definitely look into that.

I'd like to add a note that dual-booting also requires a change in the kernel bootargs (ubi.mtd=5 to ubi.mtd=7). Given that the default OpenWRT kernel configuration does not take arguments from U-Boot you'd need to change the .dts for this (or change the kernel config of course :))

11

I've tested this, it negatively affects using the device as a switch. See the 2gb branch in my repo.

Baseline, without the WE420223-99:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   931 Mbits/sec    0             sender
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   930 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  2.17 GBytes   931 Mbits/sec    0             sender
[  7][RX-C]   0.00-20.00  sec  2.17 GBytes   930 Mbits/sec                  receiver

With the WE420223-99 as NAT, no hw offloading and both ports in the switch (in the dts):

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec   411 MBytes   172 Mbits/sec  1965             sender
[  5][TX-C]   0.00-20.00  sec   410 MBytes   172 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  1.11 GBytes   478 Mbits/sec  1511             sender
[  7][RX-C]   0.00-20.00  sec  1.11 GBytes   478 Mbits/sec                  receiver

Single direction:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  1.49 GBytes   639 Mbits/sec  166             sender
[  5]   0.00-20.02  sec  1.49 GBytes   638 Mbits/sec                  receiver

With hw offloading we are indeed limited to 1Gb:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec   375 MBytes   157 Mbits/sec  5505             sender
[  5][TX-C]   0.00-20.00  sec   374 MBytes   157 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  1.75 GBytes   751 Mbits/sec  6735             sender
[  7][RX-C]   0.00-20.00  sec  1.75 GBytes   750 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  2.15 GBytes   926 Mbits/sec  455             sender
[  5]   0.00-20.00  sec  2.15 GBytes   925 Mbits/sec                  receiver

With the WE420223-99 used as a switch (both ports in the switch (in the dts) and lan0 and lan1 in br-lan):

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec  2.17 GBytes   931 Mbits/sec    0             sender
[  5][TX-C]   0.00-20.00  sec  2.16 GBytes   930 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  2.17 GBytes   933 Mbits/sec    0             sender
[  7][RX-C]   0.00-20.00  sec  2.17 GBytes   931 Mbits/sec                  receiver

So now with the 2Gb patches:

With NAT and no hw offloading:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec   888 MBytes   372 Mbits/sec  284             sender
[  5][TX-C]   0.00-20.00  sec   885 MBytes   371 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  1.26 GBytes   541 Mbits/sec  937             sender
[  7][RX-C]   0.00-20.00  sec  1.26 GBytes   540 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  1.93 GBytes   830 Mbits/sec  216             sender
[  5]   0.00-20.00  sec  1.93 GBytes   829 Mbits/sec                  receiver

Enabling HW offloading makes NAT very fast:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec  2.16 GBytes   927 Mbits/sec  263             sender
[  5][TX-C]   0.00-20.00  sec  2.16 GBytes   927 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  2.13 GBytes   916 Mbits/sec    2             sender
[  7][RX-C]   0.00-20.00  sec  2.13 GBytes   914 Mbits/sec                  receiver

Unless you want to use it as a switch:

[ ID][Role] Interval           Transfer     Bitrate         Retr
[  5][TX-C]   0.00-20.00  sec  1.52 GBytes   651 Mbits/sec   92             sender
[  5][TX-C]   0.00-20.00  sec  1.51 GBytes   650 Mbits/sec                  receiver
[  7][RX-C]   0.00-20.00  sec  1.57 GBytes   676 Mbits/sec   21             sender
[  7][RX-C]   0.00-20.00  sec  1.57 GBytes   675 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  2.13 GBytes   915 Mbits/sec  466             sender
[  5]   0.00-20.00  sec  2.13 GBytes   914 Mbits/sec                  receiver

This is now slower because all the data goes through the CPU instead of being directly switched as before:

  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
   26     2 root     RW       0   0%  24% [ksoftirqd/3]
   16     2 root     RW       0   0%  23% [ksoftirqd/1]
  398     2 root     RW       0   0%  21% [napi/mtk_eth-6]
  397     2 root     RW       0   0%  18% [napi/mtk_eth-5]
 4003   703 root     R     1332   1%   0% top
    5     2 root     IW       0   0%   0% [kworker/0:0-eve]
  243     2 root     IW       0   0%   0% [kworker/2:1-eve]
  423     2 root     IW<      0   0%   0% [kworker/0:1H-ev]

So somehow we can properly offload the NAT use case but not the switch use case with the 2Gb patch :frowning:

12

This is unrelated to your point but do you see high CPU usage like this between switch ports without my patch?

13

Without your patch I don't see any CPU from the traffic (tested this in both Linux 5.10 and 5.15, previous tests were 5.10 only).

Interestingly enough, I found that in 5.10 (without your patch) bridging two VLANs does allow traffic between the bridged interfaces. So:

# brctl show
bridge name	bridge id		STP enabled	interfaces
br-lan		7fff.bc30d90a8d18	no		lan0
							lan1.1000

A device sending out tagged frames to lan1 can ping OpenWRT but not a device on the lan0 side. After upgrading the kernel to 5.15 this works! Though at that point the CPU is busy again handling the packets with a hit in speed and a lot of CPU usage So without VLANs involved the traffic is switched through hardware on 5.15, otherwise in software.

14

Note that on 5.15, I only get 6.0 dBm power for every frequency and only one wiphy. This is similar to when I did not configure the mtd-eeprom in the device tree on 5.10. I'm not sure what is going on.

15

The same for Beeline SmartBox Flash. I suppose all mt7615 dbdc devices are affected.

16

Greetings,
Just wondering if there is a workable .bin yet for idiots like me to try :grimacing:

17

Sure! I've uploaded a build here.

18

Thanks mate but forgot KPN gestapo locks these via web interface.. little experiance with serial flash so to avoid turning this into a howto topic I'll wait for a release.

19

I'm still awaiting feedback on my patch series on the mailing list, after that I'll write some documentation on the OpenWRT wiki.

In order to flash without touching the hardware we'll need an exploit to do so. For old firmware versions there is this: https://7bits.nl/journal/posts/cve-2021-38703-kpn-experia-wifi-root-shell/ . As far as I know nobody is working on exploiting newer firmware versions. That means you'll need to directly modify the contents of the flash chip as I described earlier here.

1 Like
20

Unfortunately no response on my patches yet. I've written the wiki page: https://openwrt.org/inbox/toh/arcadyan/astoria/we420223-99 . Will post the OpenWRT bootlog later.

21

Great work both wiki and code, can't wait till a SOIP/SOIC16 clip arives and can test both from Raspberry and CH341.

As I understand there are 2 revisions of this model, which each a different kind of SPI flash chip both 16pins. For further completion could you also post/hint on the wiki which spi pins on the flashchips needs to be connected or a link to the datasheets for the chips?

PS: also have 3 of these devices 2 with older Firmware, but I wasn't able to get a root shell with the linked exploit in the past, could be pebcak...

22

There are indeed two revisions with different chips but they have the same pinout.

So this is the flash chip, the physical package also has a clear marking of pin 1 with a dot:

qY016a4hr8XqEzlA6DSdp9Xt
qY016a4hr8XqEzlA6DSdp9Xt960×556 9.86 KB

You can find the Winbond datasheet here: https://www.winbond.com/hq/support/documentation/levelOne.jsp?__locale=en&DocNo=DA00-W25Q256JV

The raspberry pi pins are documented at https://pinout.xyz/pinout/spi# . I used SPI0. That means that:

Flash Chip -- Raspberry Pi

/HOLD -- 3v3 or not connected
VCC -- 3v3 Power
/RESET -- 3v3 Power
NC -- Nothing
/CS -- GPIO 8 (SPI0 CE0)
DO -- GPIO 9 (SPI0 MISO)

CLK -- GPIO11 (SPI0 SCLK)
DI -- GPIO 10 (SPI0 MOSI)
GND -- Ground
/WP -- 3v3 or not connected

I don't remember whether I connected /HOLD and /WP to the pi at all. Could you try and report back? I'll update the wiki later :slight_smile:

I can't help you with the exploit, my devices all had newer firmware. You could ask Habbie in the #openwrt-devel chat for more information.

23

Thanks for the pinout details. In the mean time received the 16pin clip, but will will do some experimenting somewhere end of this month.

If I'm not mistaken I have access to at least 2 or maybe 3 experia devices with dated firmware versions (exploitable). If I'm able to backup these flashchips are you interested in the files to see if a easier exploit can be used for flashing OpenWrt without opening the device?

24

@walterav I'm interested!

I received some feedback on my patches on the mailing list and I've updated my repo on GitHub accordingly. Users who are already run a build and are going to upgrade need to rename their network ports in the configuration. This can be done by renaming lan0 and lan1 to sw0 and sw1 in the /etc/config files. After renaming, do not restart/reload anything and directly flash the new build.

25

Since snapshots have moved to kernel 5.15, Wifi no longer works properly on my device. Seems to be related to this?