Need people testing ipq40xx DSA PR

For Developers
1

The ipq40xx - DSA patch is pending almost a year. What is missing are people who test the conversions.

What you can do is to check the devices in the PR. (Please have a look at the complete list in the PR, the image is just an example)
image

If you have a device that is not already checked, please write me and I will do the conversion and send you an image and you test it. Or you do it at your own.

6 Likes
2

Hi,

I could help with this. I have the hAP ac2. Let me know what I need to do to test this.

-ianp

3

Thanks for your help, but the MikroTik hAP ac2 is already converted and tested. :slight_smile:

1 Like
4

And thank you for your work. :relaxed:

5

I have a GL-AP1300 and a GL-S1300. Happy to test if you can send me an image for each of them.

1 Like
6

@PolynomialDivision in the mean time i'm preparing the qca8k driver upstream so we can push it in the future :smiley:

4 Likes
7

GL-AP1300. You have to flash with -n. I also enabled the wifi by default so recovery is easy. I also added mac address cells to the device tree. Would be nice if you could check also the mac addresses. The image is contained as zip in the PR: https://github.com/sartura/openwrt/pull/31

2 Likes
8

Here is the GL-S1300:

Again -n and wifi should be enabled by default. I also added mac addresses, however, I guess at least 1 mac will fail. Probably I have to add mac-address-increment = <1>; to the one cell instead of trying to read it from art.

9

OK got it running. It was an "as new" unit with the GL-inet proprietory firmware.
To get round multiple brickings, I had to:
1.uboot and flash with the "official" snapshot factory.ubi image
2. copy your image to the AP-1300
3. sysupgrade -n
4. Wait a few minutes after all light flashing stopped
5. Power cycle to actually get it to come up.

Mac addresses are:

root@OpenWrt:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 94:83:c4:0d:29:60 brd ff:ff:ff:ff:ff:ff
3: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 94:83:c4:0d:29:60 brd ff:ff:ff:ff:ff:ff
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether 94:83:c4:0d:29:60 brd ff:ff:ff:ff:ff:ff
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 94:83:c4:0d:29:60 brd ff:ff:ff:ff:ff:ff
8: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 94:83:c4:0d:29:62 brd ff:ff:ff:ff:ff:ff
9: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 94:83:c4:0d:29:63 brd ff:ff:ff:ff:ff:ff

The label mac is :29:60
What happened to :29:61? Maybe it is the 4g modem...

Will do more testing eg changing something :wink:

1 Like
10

Thanks. I just wonder why the mac addresses are the same for both lan ports. ^^

You should be also able to read the mac with hexdump (if I don't do a mistake), e.g. by doing (if mtd7 is your art partition):

hexdump -C -s 0xe010 -n 48 /dev/mtd7

and

hexdump -C -s 0xe018 -n 48 /dev/mtd7
11 
root@OpenWrt:~# hexdump -C -s 0xe010 -n 48 /dev/mtd7
0000e010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
 *
 0000e040

root@OpenWrt:~# hexdump -C -s 0xe018 -n 48 /dev/mtd7
0000e018  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0000e048
12

Okay, my calculation seems wrong. ^^

13

That is how it is in the GL firmware (I think), wan and lan. I could get another out of stock and double check......

14

@bluewavenet I updated now the PR and also uploaded a new image. The wan port should now be a wan port also in OpenWrt. :slight_smile:

15

Well it works but now the ports are the wrong way round :smiley: ie one marked wan on the case is actually lan.

16

Updated again. Had a 50% making it wrong, and I did it. xD

1 Like
17

Perfect! Looking good to go.

1 Like
18

I'll try this next!

1 Like
19

It's not quite perfect, a particular sequence is required:

  1. enter uboot and flash with the standard snapshot factory.ubi
    It boots automatically once finished and everything works.
  2. scp your firmware to /tmp and sysupgrade -n
    Goes through flashing leds stage then stops at the normal "booted up" power light only stage.
  3. No response from pings using the static ip laptop on ethernet that was used for uboot.
  4. No wifi ssid broadcast on either radio. It is as if all networks fail to come up
  5. Power cycle and it boots with ssids on 2g and 5g , ethernet working on wan and lan ports and dhcp/dns working.

If I choose to reflash again using your firmware and sysupgrade, it still boots ok with everything working.

The factory.ubi uboot flash seems to be required if starting from the Gl-inet firmware. If you flash this DSA firmware or standard snapshot firmware using sysupgrade from Gl firmware, it bricks into a boot loop (as indicated by periodic sessions of led flashing).

IMO this is good enough to go with as long as the wiki is updated, although most people would power cycle at some stage anyway, then discover it is working.

1 Like
20

@PolynomialDivision , I know that the Fritzbx 4040 has already been converted, but I would like to do some tests.
Is there a kind of prebuild sysupgrade image or do I have to compile it on my own ?
(could you please provide build instructions, I'm a kind of "github dummy")

Thanks,
Thomas