All devices are using nand images. Built-in SATA modules are not needed
anymore.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
[only move CONFIG_SATA_MV]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Pawel Dembicki <paweldembicki@gmail.com> [pogo v4]
This patch moves led trigger settings from 01_leds file to dts.
Now "linux,default-trigger" property is used.
Tested-by: Alberto Bursi <bobafetthotmail@gmail.com> [nsa310,nsa325]
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
The ZyXEL NBG6617 has a separate kernel partition which is 4MiB large.
Add the kernel size to validate the kernel won't be bigger than this
fixed limit.
Signed-off-by: David Bauer <mail@david-bauer.net>
To prevent "wrong" musl packages which have a new version number
but the package still contains an old version, because
PKG_SOURCE_VERSION was unchanged.
Ref: musl ml https://www.openwall.com/lists/musl/2020/05/22/4
Reviewed-by: Petr Štetiar <ynezz@true.cz>
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Bringing up of station vlan fails if the optional mac entry isn't set.
The default mac "00:00:00:00:00:00", which should match all stations,
is mistakenly set to the non used variable "isolate". This results in
a wrong formatted .psk file which has to be "vlan_id mac key".
fixes: 5aa2ddd0: hostapd: add support for wifi-station and wifi-vlan sections
Signed-off-by: Johann Neuhauser <johann@it-neuhauser.de>
The NETGEAR EX61500v2 and EX6150v2 U-Boot does not support booting LZMA
compressed images. Currently, they are using GZIP compressed kernels,
which results in ledd flash being available to the root and overlay
filesystems.
Using a zImage results in a smaller kernel and therefore increases
available space for rootfs and overlayfs.
Size reduced: ~1.1 MiB
Signed-off-by: David Bauer <mail@david-bauer.net>
ipq40xx is still using swconfig based switch management. This might
change in he future, however disable the DSA and Switchdev support for
now.
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
[rephrased commit message]
Signed-off-by: David Bauer <mail@david-bauer.net>
SOC: IPQ4018 / QCA Dakota
CPU: Quad-Core ARMv7 Processor rev 5 (v7l) Cortex-A7
DRAM: 256 MiB
NOR: 32 MiB
ETH: Qualcomm Atheros QCA8072 (2 ports)
USB: 1 x 2.0 (Host controller in the SoC)
WLAN1: Qualcomm Atheros QCA4018 2.4GHz 802.11bgn 2:2x2
WLAN2: Qualcomm Atheros QCA4018 5GHz 802.11a/n/ac 2:2x2
INPUT: RESET Button
LEDS: White, Blue, Red, Orange
Flash instruction:
From EnGenius firmware to OpenWrt firmware:
In Firmware Upgrade page, upgrade your openwrt-ipq40xx-generic-engenius_emr3500-squashfs-factory.bin directly.
From OpenWrt firmware to EnGenius firmware:
1. Setup a TFTP server on your computer and configure static IP to 192.168.99.8
Put the EnGenius firmware in the TFTP server directory on your computer.
2. Power up EMR3500. Press 4 and then press any key to enter u-boot.
3. Download EnGenius firmware
(IPQ40xx) # tftpboot 0x84000000 openwrt-ipq40xx-emr3500-nor-fw-s.img
4. Flash the firmware
(IPQ40xx) # imgaddr=0x84000000 && source 0x84000000:script
5. Reboot
(IPQ40xx) # reset
Signed-off-by: Yen-Ting-Shen <frank.shen@senao.com>
[squashed update patch, updated to 5.4, dropped BOARD_NAME,
migrated to SOC]
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
It was noticed that the the whole MAC can hang when transferring data from
one ar40xx port (WAN ports) to the CPU and from the CPU back to another
ar40xx port (LAN ports). The CPU was doing only NATing in that process.
Usually, the problem first starts with a simple data corruption:
$ wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso -O /dev/null
...
Connecting to saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected.
...
Read error at byte 48807936/352321536 (Decryption has failed.). Retrying.
But after a short while, the whole MAC will stop to react. No traffic can
be transported anymore from the CPU port from/to the AR40xx PHY/switch and
the MAC has to be resetted.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Acked-by: John Crispin <john@phrozen.org>
With the new driver, MAC addresses are not set up in DTS anymore,
and therefore label-mac-device will be useless there.
Setup is done properly in 02_network, so this just removes the
obsolete alias.
Fixes: 5e50515fa6 ("ramips/mt7621: mikrotik: don't use
mtd-mac-address in DTS")
Suggested-by: John Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
With several subtargets, the image/Makefile becomes crowded after a
while. Many targets have moved their device definitions to $subtarget.mk
files to have them more organized, let's do this here as well.
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This updates the display port order for the TEW-810DR to be in line
with the DIR-810L. Both share the same board and pictures on the
vendors' pages indicate the same external numbering scheme as well.
Signed-off-by: J. Scott Heppler <shep971@centurylink.net>
[replace commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
NETGEAR WAC104 is an AP based on castrated R6220, without WAN
port and USB.
SoC: MediaTek MT7621ST
RAM: 128M DDR3
FLASH: 128M NAND
WiFi: MediaTek MT7612EN an+ac
MediaTek MT7603EN bgn
ETH: MediaTek MT7621ST (4x LAN)
BTN: 1x Connect (WPS), 1x WLAN, 1x Reset
LED: 7x (3x GPIO controlled)
Installation:
Login to netgear webinterface and flash factory.img
Back to stock:
Use nmrpflash to revert stock image.
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Hardware:
* SoC: Qualcomm Atheros QCA9558
* RAM: 256MB
* Flash: 16MB SPI NOR
* Ethernet: 2x 10/100/1000 (1x 802.3at PoE-PD)
* WiFi 2.4GHz: Qualcomm Atheros QCA9558
* WiFi 5GHz: Qualcomm Ahteros QCA9880-2R4E
* LEDS: 1x 5GHz, 1x 2.4GHz, 1x LAN1(POE), 1x LAN2, 1x POWER
* Buttons: 1x RESET
* UART: 1x RJ45 RS-232 Console port
Installation via stock firmware:
* Install the factory image via the stock firmware web interface
Installation via bootloader Emergency Web Server:
* Connect your PC to the LAN1(PoE) port
* Configure your PC with IP address 192.168.0.90
* Open a serial console to the Console port (115200,8n1)
* Press "q" within 2s when "press 'q' to stop autoboot" appears
* Open http://192.168.0.50 in a browser
* Upload either the factory or the sysupgrade image
* Once you see "write image into flash...OK,dest addr=0x9f070000" you
can power-cycle the device. Ignore "checksum bad" messages.
Setting the MAC addresses for the ethernet interfaces via
/etc/board.d/02_network adds the following snippets to
/etc/config/network:
config device 'lan_eth0_1_dev'
option name 'eth0.1'
option macaddr 'xx:xx:xx:xx:xx:xx'
config device 'wan_eth1_2_dev'
option name 'eth1.2'
option macaddr 'xx:xx:xx:xx:xx:xx'
This would result in the proper MAC addresses being set for the VLAN
subinterfaces, but the parent interfaces would still have a random MAC
address. Using untagged VLANs could solve this, but would still leave
those extra snippets in /etc/config/network, and then the device VLAN
setup would differ from the one used in ar71xx. Therefore, the MAC
addresses of the ethernet interfaces are being set via preinit instead.
The bdcfg partition contains 4 MAC address labels:
- lanmac
- wanmac
- wlanmac
- wlanmac_a
The first 3 all contain the same MAC address, which is also the one on
the label.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Reviewed-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
IPKG_INSTROOT is only set under image builder and we won't be running
this script at build time either, so remove the reference before it gets
cargo-culted into other scripts.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Acked-by: Hans Dedecker <dedeckeh@gmail.com>
The interface mode number of RGMII_33V is 7 on RTL8367, but it's 9 on
RTL8367B.
the external interface modes for RTL8367 are follows:
- 0, Disabled
- 1, RGMII
- 2, MII_MAC
- 3, MII_PHY
- 4, TMII_MAC
- 5, TMII_PHY
- 6, GMII
- 7, RGMII_33V
the external interface modes for RTL8367B are follows:
- 0, Disabled
- 1, RGMII
- 2, MII_MAC
- 3, MII_PHY
- 4, TMII_MAC
- 5, TMII_PHY
- 6, GMII
- 7, RMII_MAC
- 8, RMII_PHY
- 9, RGMII_33V
But the driver in U-Boot of RT-N56U GPL tar blocks using RGMII_33V (9)
mode and it seems to be unsupported on RTL8367B, so drop it from
switch-case in rtl8367b_extif_set_mode.
ref (RTL8367):
- TL-WR2453ND v1
ref (RTL8367B):
- ASUS RT-N56U
- TP-Link Archer C2 v1
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
The folder `json_info_files` contains multiple JSON files which describe
created firmware images. The folder is not removed between builds as the
ImageBuilder does not use `image.mk`.
Not removing the JSON files result in a merged `profiles.json` file
containing entries for outdated or non-existing images.
This commit adds the `json_info_files/` cleanup step to the ImageBuilder
Makefile.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The patch 4a1a58a3 build, imagebuilder: Do not require libncurses-dev
was supposed to remove libncurses as a requirement for the ImageBuilder.
However as the IB=1 is only exported during building, not for checking
requirements, it did never actually work.
This commit export IB=1 to the requirement check.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The port order displayed in LuCI is currently inverted for this
devices:
LuCI - Device
LAN1 - LAN4
LAN2 - LAN3
LAN3 - LAN2
LAN4 - LAN1
Fix it.
Strangely, the owner of a TRENDnet TEW-810DR reports that the
initial port order is correct, while both devices share the
same board and look similar from the outside. Since I cannot
investigate this without having any of the devices, this does
only touch the DIR-810L for now.
While at it, also merge in the case for zbtlink,zbt-we2026, as
the display port specified for WAN there won't have any effect
anyway.
Reported-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The WAN LED on DIR-810L was actually blinking on LAN1 port
activity. This has already been improved for the TEW-810DR, where
the GPIO has been set up explicitly rather than having it controlled
by the switch.
This patch also applies this setup to the DIR-810L.
In addition, the trigger in 01_leds is set up with
ucidef_set_led_switch for both devices now, so state changes should
be displayed correctly as well.
Reported-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Roger Pueyo Centelles <roger.pueyo@guifi.net> [DIR-810L]
Tested-by: J. Scott Heppler <shep971@centurylink.net> [TEW-810DR]
The folder for the uci-defaults file of this package is wrong, so
the file most probably has not been executed at all for several
years at least.
Fix the folder and remove the useless shebang for the file.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
With several subtargets, the image/Makefile becomes crowded after a
while. Many targets have moved their device definitions to $subtarget.mk
files to have them more organized, let's do this here as well.
While at it, also move subtarget-specific build recipes.
Cc: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Many target use a repetitive if-include scheme for their subtarget
image files, though their names are consistent with the subtarget
names.
This patch removes these redundant conditions and just uses the
variable for the include where the target setup allows it.
For sunxi, this includes a trivial rename of the subtarget image
Makefiles.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The Netgear WNDRMAC v1 is a hardware variant of the Netgear WNDR3700 v2
Specifications
==============
* SoC: Atheros AR7161
* RAM: 64mb
* Flash on board: 16mb
* WiFi: Atheros AR9220 (a/n), Atheros AR9223 (b/g/n)
* Ethernet: RealTek RTL8366SR (1xWAN, 4xLAN, Gigabit)
* Power: 12 VDC, 2.5 A
* Full specs on [openwrt.org](https://openwrt.org/toh/hwdata/netgear/netgear_wndrmac_v1)
Flash Instructions
==================
It is possible to use the OEM Upgrade page to install the `factory`
variant of the firmware.
After the initial upgrade, you will need to telnet into the router
(default IP 192.168.1.1) to install anything. You may install LuCI
this way. At this point, you will have a web interface to configure
OpenWRT on the WNDRMAC v1.
Please use the `sysupgrade` variant for subsequent flashes.
Recovery Instructions
=====================
A TFTP-based recovery flash is possible if the need arises. Please refer
to the WNDR3700 page on openwrt.org for details.
https://openwrt.org/toh/netgear/wndr3700#troubleshooting_and_recovery
Signed-off-by: Renaud Lepage <root@cybikbase.com>
[update DTSI include name]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The Netgear WNDRMAC v2 is a hardware variant of the Netgear WNDR3800
Specifications
==============
* SoC: Atheros AR7161
* RAM: 128mb
* Flash on board: 16mb
* WiFi: Atheros AR9220 (a/n), Atheros AR9223 (b/g/n)
* Ethernet: RealTek RTL8366SR (1xWAN, 4xLAN, Gigabit)
* Serial console: Yes, 115200 / 8N1 (JTAG)
* USB: 1x2.0
* Power: 12 VDC, 2.5 A
* Full specs on [openwrt.org](https://openwrt.org/toh/hwdata/netgear/netgear_wndrmac_v2)
Flash Instructions
==================
It is possible to use the OEM Upgrade page to install the `factory`
variant of the firmware.
After the initial upgrade, you will need to telnet into the router
(default IP 192.168.1.1) to install anything. You may install LuCI
this way. At this point, you will have a web interface to configure
OpenWRT on the WNDRMAC v2.
Please use the `sysupgrade` variant for subsequent flashes.
Recovery Instructions
=====================
A TFTP-based recovery flash is possible if the need arises. Please refer
to the WNDR3800 page on openwrt.org for details.
https://openwrt.org/toh/netgear/wndr3800#recovery_flash_in_failsafe_mode
Signed-off-by: Renaud Lepage <root@cybikbase.com>
[do not add device to uboot-envtools, update DTSI name]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This renames the DTSI for Netgear WNDR devices based on ar7161 to
indicate that the file is not limited to WNDR3700 models.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Since 01_enable_packet_steering only touches the network config,
limit the uci commit to this as well.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
According to the manual, the amber power LED is used to indicate boot,
while the green LED is meant to indicate a running system.
While at it, also adjust the DT node names for all LEDs.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Specifications:
* SoC: MT7620A
* CPU: 580 MHz
* RAM: 64 MB DDR
* Flash: 8MB NOR SPI flash
* WiFi: MT7612E (5GHz) and builtin MT7620A (2.4GHz)
* LAN: 1x100M
The device is identical to the EX6130 except
for the mains socket and the hardware ID.
Installation:
The -factory images can be flashed from the
device's web interface or via nmrpflash.
Notes:
MAC addresses were set up based on the EX6130 setup.
This is based on prior work of Adam Serbinski and Mathias Buchwald.
Tested by Mathias Buchwald.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch adds ar71xx's GPIO setup for the 2.4GHz and 5GHz antennae
demultiplexer:
| 158 /* 2.4 GHz uses the first fixed antenna group (1, 0, 1, 0) */
| 159 ap9x_pci_setup_wmac_gpio(0, (0xf << 6), (0xa << 6));
| 160
| 161 /* 5 GHz uses the second fixed antenna group (0, 1, 1, 0) */
| 162 ap9x_pci_setup_wmac_gpio(1, (0xf << 6), (0x6 << 6));
This should restore the range and throughput of the 2.4GHz radio
on all the derived wndr3700 variants and versions with the AR7161 SoC.
A special case is the 5GHz radio. The original wndr3700(v1) will
benefit from this change. However the wndr3700v2 and later revisions
were unaffected by the missing bits, as there is no demultiplexer
present in the later designs.
This patch uses gpio-hogs within the device-tree for all
wndr3700/wndr3800/wndrmac variants.
Notes:
Based on the PCB pictures, the WNDR3700(v1) really had eight
independent antennae. Four antennae for each radio and all of
those were printed on the circut board.
The WNDR3700v2 and later have just six antennae. Four of those
are printed on the circuit board and serve the 2.4GHz radio.
Whereas the remaining two are special 5GHz Rayspan Patch Antennae
which are directly connected to the 5GHz radio.
Hannu Nyman dug pretty deep and unearthed a treasure of information
regarding the history of how these values came to be in the OpenWrt
archives: <https://dev.archive.openwrt.org/ticket/6533.html>.
Mark Mentovai came across the fixed antenna group when he was looking
into the driver:
fixed_antenna_group 1, (0, 1, 0, 1)
fixed_antenna_group 2, (0, 1, 1, 0)
fixed_antenna_group 3, (1, 0, 0, 1)
fixed_antenna_group 4, (1, 0, 1, 0)
Fixes: FS#3088
Reported-by: Luca Bensi
Reported-by: Maciej Mazur
Reported-by: Hannu Nyman <hannu.nyman@iki.fi>
Debugged-by: Hannu Nyman <hannu.nyman@iki.fi>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
CONFIG_VLAN_8021Q was explicitely disabled in oxnas kernel config.
Don't do that, so VLANs can be used on the target.
Fixes: dcc34574ef ("oxnas: bring in new oxnas target")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Bump to latest Git and refresh all patches in order to get fix for "UPnP
SUBSCRIBE misbehavior in hostapd WPS AP" (CVE-2020-12695).
General security vulnerability in the way the callback URLs in the UPnP
SUBSCRIBE command are used were reported (VU#339275, CVE-2020-12695).
Some of the described issues may be applicable to the use of UPnP in WPS
AP mode functionality for supporting external registrars.
Ref: https://w1.fi/security/2020-1/
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This partially reverts commit 5acd1ed0be ("ramips: mt7621: fix
Ubiquiti ER-X ports names and MAC addresses"), this change was discussed
in https://github.com/openwrt/openwrt/pull/2901#discussion_r407238452
With commit 5acd1ed0be ("ramips: mt7621: fix Ubiquiti ER-X ports names
and MAC addresses"), all the ports were put into the LAN bridge, with
the argument that the OEM firmware does not have a WAN port enabled. In
the default OEM setup, all of the ports except eth0 are dead and eth0 is
set to a static IP address without providing DHCP services when
connected. It is only after the wizard has been run that eth0 becomes
the WAN port and all the rest of the ports belong to LAN with DHCP
enabled.
Having all of the ports set to the LAN bridge does not mirror the default
OEM setup. To accomplish that, then only eth0 would be in the LAN bridge.
But this is not the expected behaviour of OpenWrt.
Therefore this proposal to set eth0 to WAN and eth1-N to LAN provides
the expected behaviour expected from OpenWrt, maintains the current
documentation as up-to-date, and does not require the user to manually
detach eth0 from the LAN bridge, create the WAN(6) interface(s), and set
eth0 to the WAN(6) interface(s).
Fixes: 5acd1ed0be ("ramips: mt7621: fix Ubiquiti ER-X ports names and MAC addresses")
Signed-off-by: Perry Melange <isprotejesvalkata@gmail.com>
[commit subject and description tweaks]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This patch changes the version code of the image header
from `1.1.99_0.0.0.0` to `99.99.99_99.99.99.99`. This
is neccessary on some devices where the stock firmware
checks the version field, possibly preventing third-party
firmware from being installed.
Reviewed-by: Thibaut VARÈNE <hacks@slashdirt.org>
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
d13290b Fix advertised IPv6 addresses
Don't just serve link-local addresses via mdns, offer all.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
When bringing up wifi the first time after boot, these warnings appear:
netifd: radio0 (1370): rm: can't remove '/var/run/hostapd-wlan0.psk': No such file or directory
netifd: radio0 (1370): rm: can't remove '/var/run/hostapd-wlan0.vlan': No such file or directory
Silence them by adding the "-f" option to rm.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: John Crispin <john@phrozen.org>
