Adding OpenWrt support for custom device - Contract opportunity

2022-02-10 Thread Cristian Morales Vega 
We're working with an ODM vendor in China to develop a new hardware
device. The hardware is based on the Mediatek MT7622 SoC (already
supported in OpenWRT), with a Realtek 2.5GbE PHY and MTK Wi-Fi 6. We
have limited knowledge about the details of the hardware, and frankly
we don't even know the right questions to ask. The ODM vendor is
willing and able to help with hardware matters, but has little
software expertise. We have a relationship with MTK so can request the
necessary SDKs if needed.

The ODM has already provided a more or less working demo firmware
based on an old LEDE version (probably based on a SDK from Mediatek),
but they can't provide the sources. We also have a development device
locally. From this demo firmware we can extract the Device Tree and
other basic information about the hardware.

The ask here is for a contractor to help develop an OpenWrt based
firmware to support the hardware provided by the ODM.

-- 
Cristian Morales Vega

Email crist...@samknows.com
Office +44 (0) 20 3111 4330
Web:  www.samknows.com


This email is sent for and on behalf of SamKnows Limited.

This email and any attachments are confidential, legally privileged
and protected by copyright. If you are not the intended recipient
dissemination or copying of this email is prohibited. If you have
received this in error, please notify the sender by replying by email
and then delete the email completely from your system.

SamKnows Limited, Registered Number: 06510477, Registered Office: Hill
House, 1 Little New Street, London, EC4A 3TR. Registered in England
and Wales. Trade Mark 2507103

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] mvebu: mark all mtd partitions on GL.iNet GL-MV1000 read-only

2022-02-10 Thread Enrico Mioso 
On this device, two of the three defined MTD partitions arre
automatically set to read-only, since they do not end at an erase/write
block boundary.
In particular, the only partition remaining writable is the one holding
the u-boot bootloader.
Mark all of the partitions read-only, at least until a better
understanding of why the layout has been laid out this way is gained.

Signed-off-by: Enrico Mioso 
---
 .../arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts
 
b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts
index cdc91880ee..acf15e8ca9 100644
--- 
a/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts
+++ 
b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-3720-gl-mv1000.dts
@@ -91,16 +91,19 @@
partition@0 {
label = "u-boot";
reg = <0 0xf>;
+   read-only;
};
 
partition@f {
label = "u-boot-env";
reg = <0Xf 0x8000>;
+   read-only;
};
 
factory: partition@f8000 {
label = "factory";
reg = <0xf8000 0x8000>;
+   read-only;
};
};
};
-- 
2.35.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02 and 19.07 minor release

2022-02-10 Thread Seo Suchan 

looks like those dnsmasq exploits aren't real

bugs never looked by human (no commit related by it), but bots confirmed 
that thoses look fixed by commit 011f8cf1d011ade2f9e7231fca3cabfb1e8eaf06


https://oss-fuzz.com/revisions?job=afl_asan_dnsmasq&range=202112300601:202201020605 



when I read that commit it looks like 2.86 had bug that faild to build 
on gcc 4.8 and it caused fuzzer to get immediately crash, producing 
bunch of 'exploits'



2022-02-10 오전 7:58에 Hauke Mehrtens 이(가) 쓴 글:> On 1/25/22 00:07, 
Hauke Mehrtens wrote:

>> On 1/24/22 22:53, Hauke Mehrtens wrote:
>>> Hi,
>>>
>>> I would like to tag a new 21.02 and 19.07 minor release in about one
>>> week. I am not aware of a severe security problem, it was just some
>>> time since the last release.
>>>
>>> Are there any known regressions in the current stable branches
>>> compared to the last release and should we fix them?
>>>
>>> If we should backport some changes from master please just answer to
>>> this mail with the commit and a reason why you need it.
>>>
>>> There are already some pull requests on github:
>>> 
https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F21.02 


>>>
>>>
>>> 
https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F19.07 


>>>
>>>
>>> Hauke
>>
>> There are some security patches available for hostapd. Is someone
>> working on backporting them to OpenWrt 21.02 or 19.07?
>> https://w1.fi/security/2022-1/
>>
>> Dnsmasq also has some new CVEs assigned.
>> Is someone working on backporting these fixes?
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45951
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45952
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45953
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45954
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45955
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45956
>> https://nvd.nist.gov/vuln/detail/CVE-2021-45957
>>
>> Hauke
>
> Hi,
>
> Sorry for the delay, I haven't found the time to take care of these
> CVEs yet and I would like to get them fixed before the release.
>
> There are also some CVEs fixed in wolfssl:
> https://github.com/openwrt/openwrt/pull/4910
> This will probably break the ABI again.
>
> It would be nice if someone could tak over one component to get this
> fixed faster.
>
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

2022-02-10 Thread Arınç ÜNAL 

On 09/02/2022 09:18, Arınç ÜNAL wrote:

On 09/02/2022 01:29, Rosen Penev wrote:

On Tue, Feb 8, 2022 at 1:02 PM Arınç ÜNAL  wrote:




On 08/02/2022 18:02, Arınç ÜNAL wrote:

Hey Chuanhong,

On 08/02/2022 17:20, Chuanhong Guo wrote:

Hi!

On Tue, Feb 8, 2022 at 3:38 AM Arınç ÜNAL  
wrote:

diff --git a/target/linux/ramips/dts/mt7621.dtsi
b/target/linux/ramips/dts/mt7621.dtsi
index 9256e118e4..95113d4e11 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -456,6 +456,9 @@

  mediatek,ethsys = <&sysc>;

+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
+


There are devices using rgmii2 pins as GPIO. (e.g. PBR-M1)
rgmii2_pins should be excluded from pinctrl-0 in dts of these routers
if you enable it by default here.


Thanks for pointing this out. These are the devicetrees which use 
any of

the GPIOs for rgmii2 (GPIO 22 - 33).

mt7621_xzwifi_creativebox-v1.dts
mt7621_tplink_rexx0-v1.dtsi
mt7621_firefly_firewrt.dts
mt7621_alfa-network_quad-e4g.dts
mt7621_winstars_ws-wn583a6.dts
mt7621_mikrotik_routerboard-m11g.dts
mt7621_sercomm_na502.dts
mt7621_mtc_wr1201.dts
mt7621_tplink_re350-v1.dts
mt7621_d-team_pbr-m1.dts
mt7621_telco-electronics_x1.dts
mt7621_wavlink_wl-wn531a6.dts
mt7621_zbtlink_zbt-wg3526.dtsi
mt7621_zbtlink_zbt-wg2626.dts
mt7621_gnubee_gb-pc2.dts
mt7621_gnubee_gb-pc1.dts
mt7621_wevo_w2914ns-v2.dtsi
mt7621_tplink_archer-x6-v3.dtsi
mt7621_netgear_ex6150.dts

I will send v2 where the pinctrl-0 property for ethernet is overwritten
with only the rgmii1_pins and mdio_pins values for these devices.


On a second note, I see that the devicetrees of these devices set rgmii2
pins to function as gpio. Even with this, do we still need to prevent
calling rgmii2_pins on the ethernet node for these devices?

Note that the GnuBee PC2 has an ethernet interface connected to
RGMII2. dts probably needs updating.


Honestly, I don't think the ethernet interface (external phy) on the 
RGMII2 bus on GB-PC2 ever worked. The device already uses two of the 
RGMII2 GPIOs for lan1 and lan2 LEDs. The external phy is not defined on 
the OpenWrt dts and it mustn't have worked until my patch here and 
upstream:


https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=0a93c0d75809582893e82039143591b9265b520e 



I'm still not convinced as I believe it's sufficient to tell pinctrl to 
initialise the rgmii2 group to function as GPIO which is already the 
case on these devices' devicetrees.


Because of this uncertainty, this patch is a no go until someone with 
any of these devices confirm that the RGMII2 GPIOs work as intended on 
their device with this patch applied.


I bought a TP-Link RE650 v1 just to test this. You are right Chuanhong, 
we indeed need to remove rgmii2_pins from ethernet node for devices that 
use rgmii2 pins as GPIO. With the current patch, this is what I get:


[1.177349] rt2880-pinmux pinctrl: pin io22 already requested by 
pinctrl; cannot claim for 1e10.ethernet

[1.196966] rt2880-pinmux pinctrl: pin-22 (1e10.ethernet) status -22
[1.210312] rt2880-pinmux pinctrl: could not request pin 22 (io22) 
from group rgmii2  on device rt2880-pinmux
[1.230058] mtk_soc_eth 1e10.ethernet: Error applying setting, 
reverse things back

[1.245853] mtk_soc_eth: probe of 1e10.ethernet failed with error -22

I've made sure overwriting the pinctrl-0 property on the device specific 
devicetree works. I will send v2 to address this.


Cheers.
Arınç

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] firewall3: remove unnecessary fw3_has_table

2022-02-10 Thread Wenli Looi 
Hi Rui and Ansuel,

Can you take a look at this patch I sent a while ago for firewall3? I
think it is a better solution for the problem in kernel 5.15+ that is
identified here.

http://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037534.html

Note that Ansuel's commit also seems to fix the problem with
LXC/LXD/Docker, because poking the table with fw3_ipt_open makes it
show up in ip_tables_names under Linux containers. However, as stated
in the commit, I don't think we need to check ip_tables_names at all?

Thanks!
Wenli


On Wed, Jun 9, 2021 at 9:51 PM Wenli Looi  wrote:
>
> Given that firewall3 already skips the table when fw3_ipt_open fails,
> there is no need for fw3_has_table.
>
> Furthermore, /proc/net/ip_tables_names is not reliable under linux
> containers (e.g. Docker/LXC/LXD). This patch will remove the need for
> existing hacks required for OpenWrt to run on those platforms.
>
> Signed-off-by: Wenli Looi 
> ---
> Additional comments:
>
> Under linux containers, I believe /proc/net/ip_tables_names does not
> contain the name of a table until it is accessed at least once.
>
> This patch makes firewall3 consistent with the iptables command, which
> fully works under linux containers and will output "Table does not
> exist" when iptc_init/ip6tc_init returns ENOENT.
>
> Examples of existing hacks required to run OpenWrt on those platforms:
>
> LXC: https://github.com/openwrt/openwrt/pull/2525
> LXD: 
> https://github.com/cvmiller/openwrt-lxd/blob/bc09dc7ebf4f2904a9b717ed8a8a4065b5f8aaa5/init.sh#L67
> Docker: 
> https://github.com/oofnikj/docker-openwrt/commit/a4f19bbbe1932e3b36690eb9ed75a273287120e3
>
> I've tested this patch on LXD and firewall3 appears to work without the
> above hack.
>
>  main.c  | 15 ---
>  utils.c |  9 -
>  utils.h |  2 --
>  3 files changed, 26 deletions(-)
>
> diff --git a/main.c b/main.c
> index 7ad00b4..7deb636 100644
> --- a/main.c
> +++ b/main.c
> @@ -195,9 +195,6 @@ stop(bool complete)
>
> for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; 
> table++)
> {
> -   if (!fw3_has_table(family == FW3_FAMILY_V6, 
> fw3_flag_names[table]))
> -   continue;
> -
> if (!(handle = fw3_ipt_open(family, table)))
> continue;
>
> @@ -268,9 +265,6 @@ start(void)
>
> for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; 
> table++)
> {
> -   if (!fw3_has_table(family == FW3_FAMILY_V6, 
> fw3_flag_names[table]))
> -   continue;
> -
> if (!(handle = fw3_ipt_open(family, table)))
> continue;
>
> @@ -339,9 +333,6 @@ reload(void)
>
> for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; 
> table++)
> {
> -   if (!fw3_has_table(family == FW3_FAMILY_V6, 
> fw3_flag_names[table]))
> -   continue;
> -
> if (!(handle = fw3_ipt_open(family, table)))
> continue;
>
> @@ -368,9 +359,6 @@ start:
>
> for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; 
> table++)
> {
> -   if (!fw3_has_table(family == FW3_FAMILY_V6, 
> fw3_flag_names[table]))
> -   continue;
> -
> if (!(handle = fw3_ipt_open(family, table)))
> continue;
>
> @@ -426,9 +414,6 @@ gc(void)
>
> for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; 
> table++)
> {
> -   if (!fw3_has_table(family == FW3_FAMILY_V6, 
> fw3_flag_names[table]))
> -   continue;
> -
> if (!(handle = fw3_ipt_open(family, table)))
> continue;
>
> diff --git a/utils.c b/utils.c
> index 17d5bf9..36897b0 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -339,15 +339,6 @@ file_contains(const char *path, const char *str)
> return seen;
>  }
>
> -bool
> -fw3_has_table(const bool ipv6, const char *table)
> -{
> -   const char *path = ipv6
> -   ? "/proc/net/ip6_tables_names" : "/proc/net/ip_tables_names";
> -
> -   return file_contains(path, table);
> -}
> -
>  bool
>  fw3_has_target(const bool ipv6, const char *target)
>  {
> diff --git a/utils.h b/utils.h
> index 884907d..5b17a2d 100644
> --- a/utils.h
> +++ b/utils.h
> @@ -102,8 +102,6 @@ void fw3_command_close(void);
>  void fw3_pr(const char *fmt, ...)
> __attribute__ ((format (printf, 1, 2)));
>
> -bool fw3_has_table(const bool ipv6, const char *table);
> -
>  bool fw3_has_target(const bool ipv6, const char *target);
>
>  bool fw3_lock(void);
> --
> 2.25.1
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.