This project is mirrored from https://github.com/luizluca/openwrt.git. Pull mirroring failed .
Last successful update .
  1. 22 Jan, 2021 6 commits
    • Álvaro Fernández Rojas's avatar
      bcm63xx: nand: fix OOB R/W for non Hamming ECC · 2d842284
      Álvaro Fernández Rojas authored
      
      
      Hamming ECC devices do not cover OOB data, as opposed to BCH ECC devices.
      Therefore, disabling ECC for all devices is preventing BCH devices from
      correctly reading and writing the OOB data.
      Signed-off-by: default avatarÁlvaro Fernández Rojas <noltari@gmail.com>
      2d842284
    • Adrian Schmutzler's avatar
      ramips: fix port labels for Xiaomi Mi Router 4 · b3eccbca
      Adrian Schmutzler authored
      The OEM assignment of LAN ports is swapped.
      
      Fixes: c2a7bb52
      
       ("ramips: mt7621: add support for Xiaomi Mi Router 4")
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      b3eccbca
    • Dmytro Oz's avatar
      ramips: mt7621: add support for Xiaomi Mi Router 4 · c2a7bb52
      Dmytro Oz authored
      Xiaomi Mi Router 4 is the same as Xiaomi Mi Router 3G, except for
      the RAM (256Mib→128Mib), LEDs and gpio (MiNet button).
      
      Specifications:
      
      Power: 12 VDC, 1 A
      Connector type: barrel
      CPU1: MediaTek MT7621A (880 MHz, 4 cores)
      FLA1: 128 MiB (ESMT F59L1G81MA)
      RAM1: 128 MiB (ESMT M15T1G1664A)
      WI1 chip1: MediaTek MT7603EN
      WI1 802dot11 protocols: bgn
      WI1 MIMO config: 2x2:2
      WI1 antenna connector: U.FL
      WI2 chip1: MediaTek MT7612EN
      WI2 802dot11 protocols: an+ac
      WI2 MIMO config: 2x2:2
      WI2 antenna connector: U.FL
      ETH chip1: MediaTek MT7621A
      Switch: MediaTek MT7621A
      
      UART Serial
      [o] TX
      [o] GND
      [o] RX
      [ ] VCC - Do not connect it
      
      MAC addresses as verified by OEM firmware:
      
      use   address   source
      LAN   *:c2      factory 0xe000 (label)
      WAN   *:c3      factory 0xe006
      2g    *:c4      factory 0x0000
      5g    *:c5      factory 0x8000
      
      Flashing instructions:
      
      1.Create a simple http server (nginx etc)
      2.set uart enable
      To enable writing to the console, you must reset to factory settings
      Then you see uboot boot, press the keyboard 4 button (enter uboot command line)
      If it is not successful, repeat the above operation of restoring the factory settings.
      After entering the uboot command line, type:
      
      setenv uart_en 1
      saveenv
      boot
      
      3.use shell in uart
      cd /tmp
      wget http://"your_computer_ip:80"/openwrt-ramips-mt7621-xiaomi_mir4-squashfs-kernel1.bin
      wget http://"your_computer_ip:80"/openwrt-ramips-mt7621-xiaomi_mir4-squashfs-rootfs0.bin
      mtd write openwrt-ramips-mt7621-xiaomi_mir4-squashfs-kernel1.bin kernel1
      mtd write openwrt-ramips-mt7621-xiaomi_mir4-squashfs-rootfs0.bin rootfs0
      nvram set flag_try_sys1_failed=1
      nvram commit
      reboot
      4.login to the router http://192.168.1.1/
      
      Installation via Software exploit
      Find the instructions in the https://github.com/acecilia/OpenWRTInvasion
      
      Signed-off-by: default avatarDmytro Oz <sequentiality@gmail.com>
      [commit message facelift, rebase onto shared DTSI/common device
      definition, bump uboot-envtools]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      c2a7bb52
    • Adrian Schmutzler's avatar
      ramips: mt7621: create DTSI for Xiaomi NAND devices · 93be5926
      Adrian Schmutzler authored
      
      
      This creates a DTSI for Xiaomi devices with 128M NAND.
      
      This allows to consolidate the partitions and a few other nodes for
      AC2100 family and Mi Router 3G.
      
      Note that the Mi Router 3 Pro has 256M NAND and differently sized
      partitions.
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      93be5926
    • Adrian Schmutzler's avatar
      ramips: mt7621: reorganize shared device definitions for Xiaomi · 5a46b718
      Adrian Schmutzler authored
      
      
      This creates a shared device definition for Xiaomi devices with
      NAND and "separate" images, i.e. kernel1.bin and rootfs0.bin.
      
      This allows to consolidate similar/duplicate code for AC2100 family
      and Mi Router 3G.
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      5a46b718
    • Robert Marko's avatar
      ipq40xx: fix boards being shown twice · 36347d00
      Robert Marko authored
      Since generic images have been split to their own
      Makefile boards are showing up twice in menuconfig
      as $(eval $(call BuildImage)) was not dropped from
      the new generic.mk.
      
      Hence $(eval $(call BuildImage)) was being called
      twice.
      
      So, lets simply drop it from generic.mk.
      
      Fixes: 378c7ff2
      
       ("ipq40xx: split generic images into own file")
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      36347d00
  2. 21 Jan, 2021 7 commits
  3. 20 Jan, 2021 7 commits
    • Rafał Miłecki's avatar
      bcm4908: add pending mtd patches for BCM4908 partitioning · 20a0d435
      Rafał Miłecki authored
      
      
      BCM4908 can have multiple firmware partitions. MTD needs to detect which
      one is currently used.
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      20a0d435
    • Rafał Miłecki's avatar
      kernel: backport mtd commit converting partitions doc syntax · 7495acb5
      Rafał Miłecki authored
      
      
      1. It's useful for developing & validating DTS files inside OpenWrt
      2. This will allow backporting later changes that depend on it
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      7495acb5
    • John Audia's avatar
      kernel: bump 5.4 to 5.4.91 · 1bd005ea
      John Audia authored
      
      
      All modification made by update_kernel.sh in a fresh clone without
      existing toolchains.
      
      Build system: x86_64
      Build-tested: ipq806x/R7800, bcm27xx/bcm2711
      Run-tested: ipq806x/R7800
      
      No dmesg regressions, everything functional
      Signed-off-by: default avatarJohn Audia <graysky@archlinux.us>
      Tested-by: Curtis Deptuck <curtdept@me.com> [x86/64]
      1bd005ea
    • Sven Eckelmann's avatar
      ath79: Add support for OpenMesh MR1750 v2 · 0988e03f
      Sven Eckelmann authored
      Device specifications:
      ======================
      
      * Qualcomm/Atheros QCA9558 ver 1 rev 0
      * 720/600/240 MHz (CPU/DDR/AHB)
      * 128 MB of RAM
      * 16 MB of SPI NOR flash
        - 2x 7 MB available; but one of the 7 MB regions is the recovery image
      * 3T3R 2.4 GHz Wi-Fi (11n)
      * 3T3R 5 GHz Wi-Fi (11ac)
      * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
      * 1x GPIO-button (reset)
      * external h/w watchdog (enabled by default))
      * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
      * 1x ethernet
        - AR8035 ethernet PHY (RGMII)
        - 10/100/1000 Mbps Ethernet
        - 802.3af POE
        - used as LAN interface
      * 12-24V 1A 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
         tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
      
      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: default avatarSven Eckelmann <sven@narfation.org>
      [rebase, add LED migration]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      0988e03f
    • Sven Eckelmann's avatar
      ath79: Add support for OpenMesh MR1750 v1 · ae7680dc
      Sven Eckelmann authored
      Device specifications:
      ======================
      
      * Qualcomm/Atheros QCA9558 ver 1 rev 0
      * 720/600/240 MHz (CPU/DDR/AHB)
      * 128 MB of RAM
      * 16 MB of SPI NOR flash
        - 2x 7 MB available; but one of the 7 MB regions is the recovery image
      * 3T3R 2.4 GHz Wi-Fi (11n)
      * 3T3R 5 GHz Wi-Fi (11ac)
      * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
      * 1x GPIO-button (reset)
      * external h/w watchdog (enabled by default))
      * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
      * 1x ethernet
        - AR8035 ethernet PHY (RGMII)
        - 10/100/1000 Mbps Ethernet
        - 802.3af POE
        - used as LAN interface
      * 12-24V 1A 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
         tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
      
      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: default avatarSven Eckelmann <sven@narfation.org>
      [rebase, apply shared DTSI/device node, add LED migration]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      ae7680dc
    • Adrian Schmutzler's avatar
      ath79: make OpenMesh MR900 DTSI more general · 847cda16
      Adrian Schmutzler authored
      
      
      The OpenMesh MR900 and to-be-added MR1750 family are very similar.
      Make the existing MR900 DTSI more general so it can be used for
      the MR1750 devices as well.
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      847cda16
    • Adrian Schmutzler's avatar
      ath79: consolidate common definitions for OpenMesh devices · bcb31149
      Adrian Schmutzler authored
      
      
      The shared image definitions for OpenMesh devices are currently
      organized based on device families. This introduces some duplicate
      code, as the image creation code is mostly the same for those.
      
      This patch thus derives two basic shared definitions that work for
      all devices and only requires a few variables to be moved back to
      the device definitions.
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      bcb31149
  4. 19 Jan, 2021 14 commits
    • Sven Eckelmann's avatar
      ath79: apply Engenius ECB1750 style to OpenMesh MR900 RGMII cfg · 4fbdadc0
      Sven Eckelmann authored
      The OpenMesh MR900 is a modified version of the Exx900/Exx1750 family.
      These devices are shipped with an AR803x PHY and had various problems with
      the delay configuration in ar71xx. These problems are now in the past [1]
      and parts of the delay configuration should now be done in the PHY only.
      
      Just switch to the configuration of the ECB1750 to have an already well
      tested configuration for ath79 with the newer kernel versions.
      
      [1] https://github.com/openwrt/openwrt/pull/3505#issuecomment-716050292
      
      Reported-by: default avatarMichael Pratt <mcpratt@pm.me>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      4fbdadc0
    • Sven Eckelmann's avatar
      ath79: Add support for OpenMesh MR900 v2 · 31172e53
      Sven Eckelmann authored
      Device specifications:
      ======================
      
      * Qualcomm/Atheros QCA9558 ver 1 rev 0
      * 720/600/240 MHz (CPU/DDR/AHB)
      * 128 MB of RAM
      * 16 MB of SPI NOR flash
        - 2x 7 MB available; but one of the 7 MB regions is the recovery image
      * 3T3R 2.4 GHz Wi-Fi
      * 3T3R 5 GHz Wi-Fi
      * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
      * 1x GPIO-button (reset)
      * external h/w watchdog (enabled by default))
      * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
      * 1x ethernet
        - AR8035 ethernet PHY (RGMII)
        - 10/100/1000 Mbps Ethernet
        - 802.3af POE
        - used as LAN interface
      * 12-24V 1A 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
         tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
      
      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: default avatarSven Eckelmann <sven@narfation.org>
      [rebase, add LED migration]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      31172e53
    • Sven Eckelmann's avatar
      ath79: Add support for OpenMesh MR900 v1 · e06c9eec
      Sven Eckelmann authored
      Device specifications:
      ======================
      
      * Qualcomm/Atheros QCA9558 ver 1 rev 0
      * 720/600/240 MHz (CPU/DDR/AHB)
      * 128 MB of RAM
      * 16 MB of SPI NOR flash
        - 2x 7 MB available; but one of the 7 MB regions is the recovery image
      * 3T3R 2.4 GHz Wi-Fi
      * 3T3R 5 GHz Wi-Fi
      * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
      * 1x GPIO-button (reset)
      * external h/w watchdog (enabled by default))
      * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
      * 1x ethernet
        - AR8035 ethernet PHY (RGMII)
        - 10/100/1000 Mbps Ethernet
        - 802.3af POE
        - used as LAN interface
      * 12-24V 1A 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
         tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
      
      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: default avatarSven Eckelmann <sven@narfation.org>
      [rebase, add LED migration]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      e06c9eec
    • Sven Eckelmann's avatar
      ath79: apply Engenius EAP600 style to OpenMesh MR600 RGMII cfg · 7b772e07
      Sven Eckelmann authored
      The OpenMesh MR600 is a modified version of the EAP600 family. These
      devices are shipped with an AR803x PHY and had various problems with the
      delay configuration in ar71xx. These problems are now in the past [1] and
      parts of the delay configuration should now be done in the PHY only.
      
      Just switch to the configuration of the EAP600 to have an already well
      tested configuration for ath79 with the newer kernel versions.
      
      [1] https://github.com/openwrt/openwrt/pull/3505#issuecomment-716050292
      
      Reported-by: default avatarMichael Pratt <mcpratt@pm.me>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      7b772e07
    • Sven Eckelmann's avatar
      ath79: Add support for OpenMesh MR600 v2 · d9a3af46
      Sven Eckelmann authored
      Device specifications:
      ======================
      
      * Qualcomm/Atheros AR9344 rev 2
      * 560/450/225 MHz (CPU/DDR/AHB)
      * 128 MB of RAM
      * 16 MB of SPI NOR flash
        - 2x 7 MB available; but one of the 7 MB regions is the recovery image
      * 2T2R 2.4 GHz Wi-Fi
      * 2T2R 5 GHz Wi-Fi
      * 8x GPIO-LEDs (6x wifi, 1x wps, 1x power)
      * 1x GPIO-button (reset)
      * external h/w watchdog (enabled by default))
      * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
      * 1x ethernet
        - AR8035 ethernet PHY (RGMII)
        - 10/100/1000 Mbps Ethernet
        - 802.3af POE
        - used as LAN interface
      * 12-24V 1A 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
         tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
      
      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: default avatarSven Eckelmann <sven@narfation.org>
      [rebase, add LED migration]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      d9a3af46
    • Sven Eckelmann's avatar
      ath79: Add support for OpenMesh MR600 v1 · 4b359995
      Sven Eckelmann authored
      Device specifications:
      ======================
      
      * Qualcomm/Atheros AR9344 rev 2
      * 560/450/225 MHz (CPU/DDR/AHB)
      * 128 MB of RAM
      * 16 MB of SPI NOR flash
        - 2x 7 MB available; but one of the 7 MB regions is the recovery image
      * 2T2R 2.4 GHz Wi-Fi
      * 2T2R 5 GHz Wi-Fi
      * 4x GPIO-LEDs (2x wifi, 1x wps, 1x power)
      * 1x GPIO-button (reset)
      * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
      * 1x ethernet
        - AR8035 ethernet PHY (RGMII)
        - 10/100/1000 Mbps Ethernet
        - 802.3af POE
        - used as LAN interface
      * 12-24V 1A 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
         tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
      
      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: default avatarSven Eckelmann <sven@narfation.org>
      [rebase, make WLAN LEDs consistent, add LED migration]
      Signed-off-by: default avatarAdrian Schmutzler <freifunk@adrianschmutzler.de>
      4b359995
    • Nick Hainke's avatar
      owipcalc: remove clone in cidr_contains6 · 0fda8049
      Nick Hainke authored
      
      
      The "cidr_contains6" functions clones the given cidr. The contains4
      does not clone the cidr. Both functions do not behave the same.
      
      I see no reason to push the cidr. I think that we get only a negligible
      performance gain, but it makes ipv4 and ipv6 equal again.
      Signed-off-by: default avatarNick Hainke <vincent@systemli.org>
      0fda8049
    • John Audia's avatar
      kernel: bump 5.4 to 5.4.90 · 38bdff29
      John Audia authored
      
      
      All modification made by update_kernel.sh in a fresh clone without
      existing toolchains.
      
      Build system: x86_64
      Build-tested: ipq806x/R7800, bcm27xx/bcm2711
      Run-tested: ipq806x/R7800
      
      No dmesg regressions, everything functional
      Signed-off-by: default avatarJohn Audia <graysky@archlinux.us>
      Tested-by: Curtis Deptuck <curtdept@me.com> [x86/64]
      38bdff29
    • Hauke Mehrtens's avatar
      dnsmasq: Update to version 2.83 · e87c0d93
      Hauke Mehrtens authored
      
      
      This fixes the following security problems in dnsmasq:
      * CVE-2020-25681:
        Dnsmasq versions before 2.83 is susceptible to a heap-based buffer
        overflow in sort_rrset() when DNSSEC is used. This can allow a remote
        attacker to write arbitrary data into target device's memory that can
        lead to memory corruption and other unexpected behaviors on the target
        device.
      * CVE-2020-25682:
        Dnsmasq versions before 2.83 is susceptible to buffer overflow in
        extract_name() function due to missing length check, when DNSSEC is
        enabled. This can allow a remote attacker to cause memory corruption
        on the target device.
      * CVE-2020-25683:
        Dnsmasq version before 2.83 is susceptible to a heap-based buffer
        overflow when DNSSEC is enabled. A remote attacker, who can create
        valid DNS replies, could use this flaw to cause an overflow in a heap-
        allocated memory. This flaw is caused by the lack of length checks in
        rtc1035.c:extract_name(), which could be abused to make the code
        execute memcpy() with a negative size in get_rdata() and cause a crash
        in Dnsmasq, resulting in a Denial of Service.
      * CVE-2020-25684:
        A lack of proper address/port check implemented in Dnsmasq version <
        2.83 reply_query function makes forging replies easier to an off-path
        attacker.
      * CVE-2020-25685:
        A lack of query resource name (RRNAME) checks implemented in Dnsmasq's
        versions before 2.83 reply_query function allows remote attackers to
        spoof DNS traffic that can lead to DNS cache poisoning.
      * CVE-2020-25686:
        Multiple DNS query requests for the same resource name (RRNAME) by
        Dnsmasq versions before 2.83 allows for remote attackers to spoof DNS
        traffic, using a birthday attack (RFC 5452), that can lead to DNS
        cache poisoning.
      * CVE-2020-25687:
        Dnsmasq versions before 2.83 is vulnerable to a heap-based buffer
        overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A
        remote attacker, who can create valid DNS replies, could use this flaw
        to cause an overflow in a heap-allocated memory. This flaw is caused
        by the lack of length checks in rtc1035.c:extract_name(), which could
        be abused to make the code execute memcpy() with a negative size in
        sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of
        Service.
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      e87c0d93
    • Hauke Mehrtens's avatar
      uboot-at91: Add PKG_MIRROR_HASH to fix download · 20a7c9d5
      Hauke Mehrtens authored
      
      
      The referenced commit is gone, but we already have this file on our
      mirror, use that one by providing the correct mirror hash.
      
      I generated a tar.xz file with the given git commit hash using a random
      fork on github and it generated the same tar.xz file as found on our
      mirror so this looks correct.
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      20a7c9d5
    • Hauke Mehrtens's avatar
      at91bootstrap: Add PKG_MIRROR_HASH to fix download · a141e7a0
      Hauke Mehrtens authored
      
      
      The referenced commit is gone, but we already have this file on our
      mirror, use that one by providing the correct mirror hash.
      
      I generated a tar.xz file with the given git commit hash using a random
      fork on github and it generated the same tar.xz file as found on our
      mirror so this looks correct.
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      a141e7a0
    • Paul Spooren's avatar
      include: update logo with better kerning · 26d1e529
      Paul Spooren authored
      
      
      Kerning seems to be very off-putting for some people so the logo
      designer thankfully updated guidelines to something which is now
      considered final.
      Signed-off-by: default avatarPaul Spooren <mail@aparcar.org>
      26d1e529
    • David Bauer's avatar
      ath79: rename UniFi AC kernel1 partition · 99f50a75
      David Bauer authored
      
      
      These devices do not run Ubiquiti AirOS. Rename the partition to the
      name used by other UniFi devices with vendor dualboot support.
      Signed-off-by: default avatarDavid Bauer <mail@david-bauer.net>
      99f50a75
    • David Bauer's avatar
      rockchip: use stable MAC-address for NanoPi R2S · a8a17fd2
      David Bauer authored
      
      
      The NanoPi R2S does not have a board specific MAC address written inside
      e.g. an EEPROM, hence why it is randomly generated on first boot.
      
      The issue with that however is the lack of a driver for the PRNG.
      It often results to the same MAC address used on multiple boards by
      default, as urngd is not active at this early stage resulting in low
      available entropy.
      
      There is however a semi-unique identifier available to us, which is the
      CID of the used SD card. It is unique to each SD card, hence we can use
      it to generate the MAC address used for LAN and WAN.
      Signed-off-by: default avatarDavid Bauer <mail@david-bauer.net>
      a8a17fd2
  5. 18 Jan, 2021 5 commits
  6. 17 Jan, 2021 1 commit