Mesh++ S618 has below products based on Qualcomm IPQ6018:
* cp03-c1
* cp01-c1
These are Wi-Fi 6 (IEEE 80211.ax) dual band 2x2 mesh routers.
Fixes: WIFI-10561
Signed-off-by: Krishna <krishna@meshplusplus.com>
Signed-off-by: Edward Cheung <edward@meshplusplus.com>
Signed-off-by: Alex Ballmer <alexb@meshplusplus.com>
QCA is still backporting the old OpenWrt hack for BR_HOOK to newer kernels.
This change was identified as a source for bugs and also caused performance
problems in certain scenarios.
And since OpenWrt is now building the bridge as part of the kernel and the
br-netfilter code as module, the build of the QCA kernel fork will also
fail because the kernel binary is depending on a module:
net/built-in.o: in function `BR_HOOK':
net/bridge/br_private.h:929: undefined reference to `br_netfilter_run_hooks'
net/bridge/br_private.h:929: undefined reference to `br_netfilter_run_hooks'
net/bridge/br_private.h:929: undefined reference to `br_netfilter_run_hooks'
net/bridge/br_private.h:929: undefined reference to `br_netfilter_run_hooks'
net/bridge/br_private.h:929: undefined reference to `br_netfilter_run_hooks'
net/built-in.o:net/bridge/br_private.h:929: more undefined references to `br_netfilter_run_hooks' follow
Just getting rid of this patch (as OpenWrt did) is therefore the best
option.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
a074cc0 improve dhcp probe on GRE tunnels
2a66b4c enable the noscan flag on radios to make 40MHz work
4c36050 improve ipv4 wifi client reporting in bridge mode
aed8805 remove openflow support
4597721 add dhcp discovery on gre tunnel interface
Fixes: WIFI-7838
Fixes: WIFI-10549
Fixes: WIFI-10538
Signed-off-by: John Crispin <john@phrozen.org>
sk_buff's cb should be cleared in the entry point for both incoming and outgoing packets at each layer.
At bridge, it is already handled in the outgoing path, but not in the incoming path. We have seen cases
where proxyarp_replied was 1 on sk_buffs coming from the WLAN driver and they were getting dropped in
forwarding path.
Fixes: WIFI-10552
Signed-off-by: Venkat Chimata <venkata@shasta.cloud>
Device specifications:
======================
* Qualcomm IPQ6000
* 256 MB of RAM
* 64 MB of SPI NOR flash
- 2x 28 MB available; but one of the 28 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi (11ax)
* 2T2R 5 GHz Wi-Fi (11ax)
* multi-color LED (controlled via red/green/blue GPIOs)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board
* 2x ethernet
- eth0
+ 1000 Mbps Ethernet
+ used as LAN interface
- eth1
+ 1000 Mbps Ethernet
+ 802.3at POE
+ used as WAN interface
* 12 2A DC
* internal antennas
This device is not exported via a profile in TIP because there were
concerns about the 256MB limitations. But the actual OpenWrt support is
still added for interested parties.
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
setenv bootargs 'console=ttyMSM0,115200n8 rootfstype=squashfs,jffs2 board=PAX1800 root=31:10 mtdparts=spi32766.0:768k(0:SBL1),64k(0:MIBIB),1664k(0:QSEE),64k(0:DEVCFG),128k(0:RPM),64k(0:CDT),64k(0:APPSBLENV),640k(0:APPSBL),256k(0:ART),28672k(inactive),28672k(inactive2),64k(custom),64k(0:KEYS),2304k(0:WIFIFW)'
tftpboot <filename-of-initramfs-kernel>.bin && bootm
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
If it already looks to the system that the flashing of the image data
failed, it is not a good idea to inform the u-boot to switch the inactive
(newly flashed) partition to the active one
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm IPQ6000
* 512 MB of RAM
* 64 MB of SPI NOR flash
- 2x 28 MB available; but one of the 28 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi (11ax)
* 2T2R 5 GHz Wi-Fi (11ax)
* multi-color LED (controlled via red/green/blue GPIOs)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board
* 2x ethernet
- eth0
+ 1000 Mbps Ethernet
+ used as LAN interface
- eth1
+ 1000 Mbps Ethernet
+ 802.3at POE
+ used as WAN interface
* 12 2A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
setenv bootargs 'console=ttyMSM0,115200n8 rootfstype=squashfs,jffs2 board=PAX1800v2 root=31:10 mtdparts=spi32766.0:768k(0:SBL1),64k(0:MIBIB),1664k(0:QSEE),64k(0:DEVCFG),128k(0:RPM),64k(0:CDT),64k(0:APPSBLENV),640k(0:APPSBL),256k(0:ART),28672k(inactive),28672k(inactive2),64k(custom),64k(0:KEYS),2304k(0:WIFIFW)'
tftpboot <filename-of-initramfs-kernel>.bin && bootm
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The toolchain path will not automatically be copied to OpenWrt. So the
build will still fail on recent Debian unstable version. Instead, it must
be applied during the setup.py process via the normal patch procedure.
Reported-by: Marek Lindner <marek.lindner@plasma-cloud.com>
Fixes: 6f6b40a94f ("toolchain/gcc: fix building gcc 5.5 on newer systems")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
