[PATCH v4] kernel: backport MT7530 IRQ support
Support MT7530 PHY link change interrupts, and enable for MT7621.
For external MT7530, a GPIO IRQ line is required, which is
board-specific, so it should be added to each DTS. In case the
interrupt-controller property is missing, it will fall back to
polling mode.
Signed-off-by: DENG Qingfang
---
v4: fix build
...net-dsa-mt7530-add-interrupt-support.patch | 425 ++
target/linux/ramips/dts/mt7621.dtsi | 3 +
2 files changed, 428 insertions(+)
create mode 100644
target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
diff --git
a/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
new file mode 100644
index 00..9890015301
--- /dev/null
+++
b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
@@ -0,0 +1,425 @@
+From ba751e28d44255744a30190faad0ca09b455c44d Mon Sep 17 00:00:00 2001
+From: DENG Qingfang
+Date: Wed, 19 May 2021 11:32:00 +0800
+Subject: [PATCH] net: dsa: mt7530: add interrupt support
+
+Add support for MT7530 interrupt controller to handle internal PHYs.
+In order to assign an IRQ number to each PHY, the registration of MDIO bus
+is also done in this driver.
+
+Signed-off-by: DENG Qingfang
+Reviewed-by: Andrew Lunn
+Reviewed-by: Florian Fainelli
+Reviewed-by: Vladimir Oltean
+Signed-off-by: David S. Miller
+---
+ drivers/net/dsa/mt7530.c | 264 +++
+ drivers/net/dsa/mt7530.h | 20 ++-
+ 2 files changed, 256 insertions(+), 28 deletions(-)
+
+--- a/drivers/net/dsa/mt7530.c
b/drivers/net/dsa/mt7530.c
+@@ -10,6 +10,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -602,18 +603,14 @@ mt7530_mib_reset(struct dsa_switch *ds)
+ mt7530_write(priv, MT7530_MIB_CCR, CCR_MIB_ACTIVATE);
+ }
+
+-static int mt7530_phy_read(struct dsa_switch *ds, int port, int regnum)
++static int mt7530_phy_read(struct mt7530_priv *priv, int port, int regnum)
+ {
+- struct mt7530_priv *priv = ds->priv;
+-
+ return mdiobus_read_nested(priv->bus, port, regnum);
+ }
+
+-static int mt7530_phy_write(struct dsa_switch *ds, int port, int regnum,
++static int mt7530_phy_write(struct mt7530_priv *priv, int port, int regnum,
+ u16 val)
+ {
+- struct mt7530_priv *priv = ds->priv;
+-
+ return mdiobus_write_nested(priv->bus, port, regnum, val);
+ }
+
+@@ -791,9 +788,8 @@ out:
+ }
+
+ static int
+-mt7531_ind_phy_read(struct dsa_switch *ds, int port, int regnum)
++mt7531_ind_phy_read(struct mt7530_priv *priv, int port, int regnum)
+ {
+- struct mt7530_priv *priv = ds->priv;
+ int devad;
+ int ret;
+
+@@ -809,10 +805,9 @@ mt7531_ind_phy_read(struct dsa_switch *d
+ }
+
+ static int
+-mt7531_ind_phy_write(struct dsa_switch *ds, int port, int regnum,
++mt7531_ind_phy_write(struct mt7530_priv *priv, int port, int regnum,
+u16 data)
+ {
+- struct mt7530_priv *priv = ds->priv;
+ int devad;
+ int ret;
+
+@@ -828,6 +823,22 @@ mt7531_ind_phy_write(struct dsa_switch *
+ return ret;
+ }
+
++static int
++mt753x_phy_read(struct mii_bus *bus, int port, int regnum)
++{
++ struct mt7530_priv *priv = bus->priv;
++
++ return priv->info->phy_read(priv, port, regnum);
++}
++
++static int
++mt753x_phy_write(struct mii_bus *bus, int port, int regnum, u16 val)
++{
++ struct mt7530_priv *priv = bus->priv;
++
++ return priv->info->phy_write(priv, port, regnum, val);
++}
++
+ static void
+ mt7530_get_strings(struct dsa_switch *ds, int port, u32 stringset,
+ uint8_t *data)
+@@ -1824,6 +1835,210 @@ mt7530_setup_gpio(struct mt7530_priv *pr
+ return devm_gpiochip_add_data(dev, gc, priv);
+ }
+
++static irqreturn_t
++mt7530_irq_thread_fn(int irq, void *dev_id)
++{
++ struct mt7530_priv *priv = dev_id;
++ bool handled = false;
++ u32 val;
++ int p;
++
++ mutex_lock_nested(>bus->mdio_lock, MDIO_MUTEX_NESTED);
++ val = mt7530_mii_read(priv, MT7530_SYS_INT_STS);
++ mt7530_mii_write(priv, MT7530_SYS_INT_STS, val);
++ mutex_unlock(>bus->mdio_lock);
++
++ for (p = 0; p < MT7530_NUM_PHYS; p++) {
++ if (BIT(p) & val) {
++ unsigned int irq;
++
++ irq = irq_find_mapping(priv->irq_domain, p);
++ handle_nested_irq(irq);
++ handled = true;
++ }
++ }
++
++ return IRQ_RETVAL(handled);
++}
++
++static void
++mt7530_irq_mask(struct irq_data *d)
++{
++ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
++
++ priv->irq_enable &= ~BIT(d->hwirq);
++}
++
++static void
++mt7530_irq_unmask(struct irq_data *d)
++{
++ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
++
++ priv->irq_enable |= BIT(d->hwirq);
++}
++
Re: [PATCH v3] kernel: backport MT7530 IRQ support
On Thu, Feb 10, 2022 at 12:00:25PM +0800, DENG Qingfang wrote:
> Support MT7530 PHY link change interrupts, and enable for MT7621.
>
> For external MT7530, a GPIO IRQ line is required, which is
> board-specific, so it should be added to each DTS. In case the
> interrupt-controller property is missing, it will fall back to
> polling mode.
I've tried building this and it breaks. See comments inline:
>
> Signed-off-by: DENG Qingfang
> ---
> ...net-dsa-mt7530-add-interrupt-support.patch | 417 ++
> target/linux/ramips/dts/mt7621.dtsi | 3 +
> 2 files changed, 420 insertions(+)
> create mode 100644
> target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
>
> diff --git
> a/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
>
> b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
> new file mode 100644
> index 00..47ac779efa
> --- /dev/null
> +++
> b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
> @@ -0,0 +1,417 @@
> +From ba751e28d44255744a30190faad0ca09b455c44d Mon Sep 17 00:00:00 2001
> +From: DENG Qingfang
> +Date: Wed, 19 May 2021 11:32:00 +0800
> +Subject: [PATCH] net: dsa: mt7530: add interrupt support
> +
> +Add support for MT7530 interrupt controller to handle internal PHYs.
> +In order to assign an IRQ number to each PHY, the registration of MDIO bus
> +is also done in this driver.
> +
> +Signed-off-by: DENG Qingfang
> +Reviewed-by: Andrew Lunn
> +Reviewed-by: Florian Fainelli
> +Reviewed-by: Vladimir Oltean
> +Signed-off-by: David S. Miller
> +---
> + drivers/net/dsa/mt7530.c | 263 +++
> + drivers/net/dsa/mt7530.h | 21 +++-
> + 2 files changed, 255 insertions(+), 29 deletions(-)
> +
> +--- a/drivers/net/dsa/mt7530.c
> b/drivers/net/dsa/mt7530.c
> +@@ -10,6 +10,7 @@
> + #include
> + #include
> + #include
> ++#include
> + #include
> + #include
> + #include
> +@@ -602,18 +603,14 @@ mt7530_mib_reset(struct dsa_switch *ds)
> + mt7530_write(priv, MT7530_MIB_CCR, CCR_MIB_ACTIVATE);
> + }
> +
> +-static int mt7530_phy_read(struct dsa_switch *ds, int port, int regnum)
> ++static int mt7530_phy_read(struct mt7530_priv *priv, int port, int regnum)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> +-
> + return mdiobus_read_nested(priv->bus, port, regnum);
> + }
> +
> +-static int mt7530_phy_write(struct dsa_switch *ds, int port, int regnum,
> ++static int mt7530_phy_write(struct mt7530_priv *priv, int port, int regnum,
> + u16 val)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> +-
> + return mdiobus_write_nested(priv->bus, port, regnum, val);
> + }
> +
> +@@ -791,9 +788,8 @@ out:
> + }
> +
> + static int
> +-mt7531_ind_phy_read(struct dsa_switch *ds, int port, int regnum)
> ++mt7531_ind_phy_read(struct mt7530_priv *priv, int port, int regnum)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> + int devad;
> + int ret;
> +
> +@@ -809,10 +805,9 @@ mt7531_ind_phy_read(struct dsa_switch *d
> + }
> +
> + static int
> +-mt7531_ind_phy_write(struct dsa_switch *ds, int port, int regnum,
> ++mt7531_ind_phy_write(struct mt7530_priv *priv, int port, int regnum,
> + u16 data)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> + int devad;
> + int ret;
> +
> +@@ -828,6 +823,22 @@ mt7531_ind_phy_write(struct dsa_switch *
> + return ret;
> + }
> +
> ++static int
> ++mt753x_phy_read(struct mii_bus *bus, int port, int regnum)
> ++{
> ++struct mt7530_priv *priv = bus->priv;
> ++
> ++return priv->info->phy_read(priv, port, regnum);
> ++}
> ++
> ++static int
> ++mt753x_phy_write(struct mii_bus *bus, int port, int regnum, u16 val)
> ++{
> ++struct mt7530_priv *priv = bus->priv;
> ++
> ++return priv->info->phy_write(priv, port, regnum, val);
> ++}
> ++
> + static void
> + mt7530_get_strings(struct dsa_switch *ds, int port, u32 stringset,
> +uint8_t *data)
> +@@ -1991,6 +2002,211 @@ mt7530_setup(struct dsa_switch *ds)
> + return 0;
> + }
> +
> ++static irqreturn_t
> ++mt7530_irq_thread_fn(int irq, void *dev_id)
> ++{
> ++struct mt7530_priv *priv = dev_id;
> ++bool handled = false;
> ++u32 val;
> ++int p;
> ++
> ++mutex_lock_nested(>bus->mdio_lock, MDIO_MUTEX_NESTED);
> ++val = mt7530_mii_read(priv, MT7530_SYS_INT_STS);
> ++mt7530_mii_write(priv, MT7530_SYS_INT_STS, val);
> ++mutex_unlock(>bus->mdio_lock);
> ++
> ++for (p = 0; p < MT7530_NUM_PHYS; p++) {
> ++if (BIT(p) & val) {
> ++unsigned int irq;
> ++
> ++irq = irq_find_mapping(priv->irq_domain, p);
> ++handle_nested_irq(irq);
> ++handled = true;
> ++}
> ++}
> ++
> ++return IRQ_RETVAL(handled);
> ++}
> ++
> ++static void
> ++mt7530_irq_mask(struct irq_data *d)
[PATCH v3] kernel: backport MT7530 IRQ support
Support MT7530 PHY link change interrupts, and enable for MT7621.
For external MT7530, a GPIO IRQ line is required, which is
board-specific, so it should be added to each DTS. In case the
interrupt-controller property is missing, it will fall back to
polling mode.
Signed-off-by: DENG Qingfang
---
...net-dsa-mt7530-add-interrupt-support.patch | 417 ++
target/linux/ramips/dts/mt7621.dtsi | 3 +
2 files changed, 420 insertions(+)
create mode 100644
target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
diff --git
a/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
new file mode 100644
index 00..47ac779efa
--- /dev/null
+++
b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
@@ -0,0 +1,417 @@
+From ba751e28d44255744a30190faad0ca09b455c44d Mon Sep 17 00:00:00 2001
+From: DENG Qingfang
+Date: Wed, 19 May 2021 11:32:00 +0800
+Subject: [PATCH] net: dsa: mt7530: add interrupt support
+
+Add support for MT7530 interrupt controller to handle internal PHYs.
+In order to assign an IRQ number to each PHY, the registration of MDIO bus
+is also done in this driver.
+
+Signed-off-by: DENG Qingfang
+Reviewed-by: Andrew Lunn
+Reviewed-by: Florian Fainelli
+Reviewed-by: Vladimir Oltean
+Signed-off-by: David S. Miller
+---
+ drivers/net/dsa/mt7530.c | 263 +++
+ drivers/net/dsa/mt7530.h | 21 +++-
+ 2 files changed, 255 insertions(+), 29 deletions(-)
+
+--- a/drivers/net/dsa/mt7530.c
b/drivers/net/dsa/mt7530.c
+@@ -10,6 +10,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -602,18 +603,14 @@ mt7530_mib_reset(struct dsa_switch *ds)
+ mt7530_write(priv, MT7530_MIB_CCR, CCR_MIB_ACTIVATE);
+ }
+
+-static int mt7530_phy_read(struct dsa_switch *ds, int port, int regnum)
++static int mt7530_phy_read(struct mt7530_priv *priv, int port, int regnum)
+ {
+- struct mt7530_priv *priv = ds->priv;
+-
+ return mdiobus_read_nested(priv->bus, port, regnum);
+ }
+
+-static int mt7530_phy_write(struct dsa_switch *ds, int port, int regnum,
++static int mt7530_phy_write(struct mt7530_priv *priv, int port, int regnum,
+ u16 val)
+ {
+- struct mt7530_priv *priv = ds->priv;
+-
+ return mdiobus_write_nested(priv->bus, port, regnum, val);
+ }
+
+@@ -791,9 +788,8 @@ out:
+ }
+
+ static int
+-mt7531_ind_phy_read(struct dsa_switch *ds, int port, int regnum)
++mt7531_ind_phy_read(struct mt7530_priv *priv, int port, int regnum)
+ {
+- struct mt7530_priv *priv = ds->priv;
+ int devad;
+ int ret;
+
+@@ -809,10 +805,9 @@ mt7531_ind_phy_read(struct dsa_switch *d
+ }
+
+ static int
+-mt7531_ind_phy_write(struct dsa_switch *ds, int port, int regnum,
++mt7531_ind_phy_write(struct mt7530_priv *priv, int port, int regnum,
+u16 data)
+ {
+- struct mt7530_priv *priv = ds->priv;
+ int devad;
+ int ret;
+
+@@ -828,6 +823,22 @@ mt7531_ind_phy_write(struct dsa_switch *
+ return ret;
+ }
+
++static int
++mt753x_phy_read(struct mii_bus *bus, int port, int regnum)
++{
++ struct mt7530_priv *priv = bus->priv;
++
++ return priv->info->phy_read(priv, port, regnum);
++}
++
++static int
++mt753x_phy_write(struct mii_bus *bus, int port, int regnum, u16 val)
++{
++ struct mt7530_priv *priv = bus->priv;
++
++ return priv->info->phy_write(priv, port, regnum, val);
++}
++
+ static void
+ mt7530_get_strings(struct dsa_switch *ds, int port, u32 stringset,
+ uint8_t *data)
+@@ -1991,6 +2002,211 @@ mt7530_setup(struct dsa_switch *ds)
+ return 0;
+ }
+
++static irqreturn_t
++mt7530_irq_thread_fn(int irq, void *dev_id)
++{
++ struct mt7530_priv *priv = dev_id;
++ bool handled = false;
++ u32 val;
++ int p;
++
++ mutex_lock_nested(>bus->mdio_lock, MDIO_MUTEX_NESTED);
++ val = mt7530_mii_read(priv, MT7530_SYS_INT_STS);
++ mt7530_mii_write(priv, MT7530_SYS_INT_STS, val);
++ mutex_unlock(>bus->mdio_lock);
++
++ for (p = 0; p < MT7530_NUM_PHYS; p++) {
++ if (BIT(p) & val) {
++ unsigned int irq;
++
++ irq = irq_find_mapping(priv->irq_domain, p);
++ handle_nested_irq(irq);
++ handled = true;
++ }
++ }
++
++ return IRQ_RETVAL(handled);
++}
++
++static void
++mt7530_irq_mask(struct irq_data *d)
++{
++ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
++
++ priv->irq_enable &= ~BIT(d->hwirq);
++}
++
++static void
++mt7530_irq_unmask(struct irq_data *d)
++{
++ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
++
++ priv->irq_enable |= BIT(d->hwirq);
++}
++
++static void
++mt7530_irq_bus_lock(struct irq_data *d)
Re: OpenWrt 21.02 and 19.07 minor release
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
Re: Firewall question
Hi Jo, I do not understand however how the guest routing works in your network currently... Guest network is wifi only with wan access, but without access to the lan network. It is used for cell phones only, which does synchronize data with nextcloud via a ddns name over the wan address. This shall work, independently if they are using the data plan or the wifi network. To generate the rules for the hotplug script, I looked to the generated forward and reflection rules for lan: iptables-save | grep '...' -A zone_lan_postrouting -s 192.168.199.0/24 -d 192.168.199.80/32 -p tcp -m tcp --dport 8443 -j SNAT --to-source 192.168.199.1 -A zone_lan_prerouting -s 192.168.199.0/24 -d 93.x.y.z/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.199.80:8443 -A zone_wan_prerouting -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.199.80:8443 From this, I generate this three rules for the hotplug script: iptables-save | grep '...' -A postrouting_guest_rule -s 10.1.0.0/16 -d 192.168.199.80/32 -p tcp -m tcp --dport 8443 -j SNAT --to-source 192.168.199.1 -A postrouting_guest_rule -s 10.1.0.0/16 -d 192.168.199.80/32 -p tcp -m tcp --dport 8443 -j SNAT --to-source 10.1.0.1 -A prerouting_guest_rule -s 10.1.0.0/16 -d 93.x.y.z/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.199.80:8443 For the postrouting rule, it wasn't clear for me which gateway address I've to use. Reflection did work. I saw an increasing package counter of the prerouting rule. The package counters of both postrouting rules did remain at 0. The package counter of the lan postrouting rule was increase instead. So I did remove both guest postrouting rules. I am not sure what you mean with 3rd network. Does it mean the server has an address in the guest subnet? Maybe you can describe its network setup in more detail... Simply generate a network for the server only like the lan network, use the forward/reflection rule for the server with the new network and use two rules for lan and guest like the old rule from hotplug script with the new destination address of the server. The following should be equivalent: config redirect option name 'guest: Redirect wan HTTPS from port 443 to 192.168.199.80 on port 8443' option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option family 'ipv4' option src_ip '10.1.0.0/16' #option src_ip 'guest' # alternative that does not hardcode guest subnet option src_dip 'wan' # sic! "wan" is resolved to the current IP option src_dport '443' option dest_ip '192.168.199.80' option dest_port '8443' option reflection '0' Yeah, this does the trick. Reflection does work, if exchange 'option src wan' by 'option src guest'. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Firewall question
Hello Hartmut, [...] > If I check the logs from apache2, I see from lan network only the gateway > or router ip and no client ip's. From guest network, I see every individual > client ip's. Yeah, for lan this is expected. The automatic NAT reflection consists of one DNAT rule to forward the current_ext_iface_addr:port to the internal destination and one SNAT rule to rewrite the source of such reflected traffic to the external (or internal) router IP in order to force responses via the router which in turn forwards them back to the original requesting client. Without that additional SNAT, the replies would come from a different source (DNAT target's internal IP) than were the request was initially sent to (external WAN IP) from a requesting host's pov. Such unexpected response is usually ignored and discard by the network stack of the requesting host. Unfortunately that also means that the DNAT target never sees the actual source IP for reflected traffic. I do not understand however how the guest routing works in your network currently... > Does exist a way to see the individual client ip's from lan network too? Or > is this only possible, if I configure a third network for the linux > server? I am not sure what you mean with 3rd network. Does it mean the server has an address in the guest subnet? Maybe you can describe its network setup in more detail... > > It is possible to do the things of hotplug script by a standard firewall > rule in '/etc/config/firewall' ? You mean a DNAT rule that specifically uses the current WAN IP as destination match (not all WAN interfaces) and not doing reflection? The following should be equivalent: config redirect option name 'guest: Redirect wan HTTPS from port 443 to 192.168.199.80 on port 8443' option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option family 'ipv4' option src_ip '10.1.0.0/16' #option src_ip 'guest' # alternative that does not hardcode guest subnet option src_dip 'wan' # sic! "wan" is resolved to the current IP option src_dport '443' option dest_ip '192.168.199.80' option dest_port '8443' option reflection '0' ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Firewall question
Hi,
I've configured a lan and a guest network on my router. To the lan network is a
linux server
connected with an apache2 running. The apache2 provides nextcloud, gitweb and a
few other
things. Nextcloud and gitweb are reachable from the wan network. I do forward
port 443 from
wan to port 8443 to the ip of the linux server. I'm using for external access
port 8443 and
for internal access port 443 for a clear differentiation between external and
internal
access. Apache2 at port 8443 use always authentication and most things on port
443 not.
The apache2 is reachable from the wan and lan network via the wan ip. This
means nat
loopback is working. To reach the apache2 from guest network via wan ip, I add
an
additional DNAT rule via a hotplug script on ifup and delete the rule on
ifdown. The apache2
is reachable from the guest network via the wan ip too.
If I check the logs from apache2, I see from lan network only the gateway or
router ip and
no client ip's. From guest network, I see every individual client ip's.
Does exist a way to see the individual client ip's from lan network too? Or is
this only
possible, if I configure a third network for the linux server?
It is possible to do the things of hotplug script by a standard firewall rule in
'/etc/config/firewall' ?
Firewall is fw3.
Regards,
Hartmut
/etc/config/network:
config interface 'lan'
option proto 'static'
option device 'br-lan'
option ipaddr '192.168.199.1'
option netmask '255.255.255.0'
...
config interface 'wan'
option proto 'pppoe'
option device 'br-wan.7'
...
config interface 'guest'
option type 'bridge'
option proto 'static'
option ipaddr '10.1.0.1'
...
/etc/config/firewall:
config zone
option name 'lan'
list network 'lan'
...
config zone
option name 'wan'
list network 'wan'
...
config zone
option name 'guest'
list network 'guest'
...
config forwarding
option src 'lan'
option dest 'wan'
config forwarding
option src 'guest'
option dest 'wan'
config redirect
option name 'Redirect wan HTTPS from port 443 to 192.168.199.80 on port
8443'
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option family 'ipv4'
option src_dport '443'
option dest_ip '192.168.199.80'
option dest_port '8443'
/etc/hotplug.d/iface/24-firewall:
COMMENT="guest: Redirect wan HTTPS from port 443 to 192.168.199.80 on port 8443"
[ "$INTERFACE" = "wan" ] && {
[ "$ACTION" = "ifup" ] && {
network_get_ipaddr "IP" "$INTERFACE"
iptables -t nat -A prerouting_guest_rule -p tcp -s 10.1.0.0/16
-d ${IP} \
-m tcp --dport 443 -m comment --comment "${COMMENT}" -j
DNAT \
--to-destination 192.168.199.80:8443
}
[ "$ACTION" = "ifdown" ] && {
RULES=$( iptables -t nat --line-number -nL
prerouting_guest_rule | \
grep "${COMMENT}" | awk '{print $1}' | tac)
for rule in $RULES; do
iptables -t nat -D prerouting_guest_rule $rule
sleep 1
done
}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 firmware-utils] iptime-crc32: add support for AX8004M
This commit is preparations for adding support for device AX8004M
similar to AX2004M.
Signed-off-by: Kim Namu
---
src/iptime-crc32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/iptime-crc32.c b/src/iptime-crc32.c
index 51b0519..ef08afa 100644
--- a/src/iptime-crc32.c
+++ b/src/iptime-crc32.c
@@ -53,6 +53,7 @@ struct board_info {
struct board_info boards[] = {
{ .model = "ax2004m", .payload_offset = 0x38 },
+ { .model = "ax8004m", .payload_offset = 0x38 },
{ /* sentinel */ }
};
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv2 firmware-utils] iptime-crc32: add support for AX8004BCM
sorry, I'm confused so I'll resend v3.
2022년 2월 9일 (수) 오후 11:37, Kim Namu 님이 작성:
>
> This commit is preparations for adding support for device AX8004BCM
> similar to AX2004BCM.
>
> Signed-off-by: Kim Namu
> ---
> src/iptime-crc32.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/iptime-crc32.c b/src/iptime-crc32.c
> index 51b0519..ef08afa 100644
> --- a/src/iptime-crc32.c
> +++ b/src/iptime-crc32.c
> @@ -53,6 +53,7 @@ struct board_info {
>
> struct board_info boards[] = {
> { .model = "ax2004m", .payload_offset = 0x38 },
> + { .model = "ax8004m", .payload_offset = 0x38 },
> { /* sentinel */ }
> };
>
> --
> 2.35.1
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCHv2 firmware-utils] iptime-crc32: add support for AX8004BCM
This commit is preparations for adding support for device AX8004BCM
similar to AX2004BCM.
Signed-off-by: Kim Namu
---
src/iptime-crc32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/iptime-crc32.c b/src/iptime-crc32.c
index 51b0519..ef08afa 100644
--- a/src/iptime-crc32.c
+++ b/src/iptime-crc32.c
@@ -53,6 +53,7 @@ struct board_info {
struct board_info boards[] = {
{ .model = "ax2004m", .payload_offset = 0x38 },
+ { .model = "ax8004m", .payload_offset = 0x38 },
{ /* sentinel */ }
};
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firmware-utils] iptime-crc32: add support for AX8004BCM
>No pseudonym, please. :
that is my real name :)
>And please add a proper commit message.
okay I will add it.
>Are you also planning on adding device support for AX8004BCM?
maybe "Yes".
2022년 2월 9일 (수) 오후 9:55, Sungbo Eo 님이 작성:
>
> Hi,
>
> On 2022-02-09 15:46, Kim Namu wrote:
> > Signed-off-by: Kim Namu
>
> No pseudonym, please. :)
> And please add a proper commit message.
>
> Are you also planning on adding device support for AX8004BCM?
>
> > ---
> > src/iptime-crc32.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/src/iptime-crc32.c b/src/iptime-crc32.c
> > index 51b0519..ef08afa 100644
> > --- a/src/iptime-crc32.c
> > +++ b/src/iptime-crc32.c
> > @@ -53,6 +53,7 @@ struct board_info {
> >
> > struct board_info boards[] = {
> > { .model = "ax2004m", .payload_offset = 0x38 },
> > + { .model = "ax8004m", .payload_offset = 0x38 },
> > { /* sentinel */ }
> > };
> >
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firmware-utils] iptime-crc32: add support for AX8004BCM
Hi,
On 2022-02-09 15:46, Kim Namu wrote:
Signed-off-by: Kim Namu
No pseudonym, please. :)
And please add a proper commit message.
Are you also planning on adding device support for AX8004BCM?
---
src/iptime-crc32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/iptime-crc32.c b/src/iptime-crc32.c
index 51b0519..ef08afa 100644
--- a/src/iptime-crc32.c
+++ b/src/iptime-crc32.c
@@ -53,6 +53,7 @@ struct board_info {
struct board_info boards[] = {
{ .model = "ax2004m", .payload_offset = 0x38 },
+ { .model = "ax8004m", .payload_offset = 0x38 },
{ /* sentinel */ }
};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[VOTE CLOSED] Use GitHub issues instead of bugs.openwrt.org
Heads up > Hi, > > I herewith close this vote. Future votes or vote changes should not change > the result. > > The switch to GitHub Issues was accepted, 20 out of 37 eligible voters are in > favor. > > Additionally, 4 are against, 7 stayed neutral and 6 did not participate the > vote. > > A vote record is available below: > https://openwrt.org/voting/2022-02-28 > > I’ll proceed and open the GitHub issues and figure out a strategy to keep the > knowledge of bugs.openwrt.org available. Logins to the current bug tracker > will be disabled (except admins) and a notification is added describing the > move. > > For everyone voting against GitHub Issues or raising concerns, this is not > necessarily an eternal decision, if alternatives turn out to be better > solutions, we move again. > > Thanks everyone for participating and the lively discussion. > > Best, > Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
I've made more tests, with previous patches together with the last ones. Backported 22ca05b and a071912 without luck. Then I commented out the macronix_nand_block_protection_support(chip) at the nand_macronix driver, but this time it didn't boot: [0.837831] bcm6368_nand 1200.nand: there is not valid maps for state default [0.849939] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [0.856524] nand: Macronix MX30LF1G18AC [0.860414] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [0.868274] bcm6368_nand 1200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4 [0.880972] Bad block table not found for chip 0 [0.887741] Bad block table not found for chip 0 [0.892523] Scanning device for bad blocks [1.390737] random: crng init done [1.558746] Bad block table written to 0x07fe, version 0x01 [1.566540] Bad block table written to 0x07fc, version 0x01 [1.605787] 9 fixed-partitions partitions found on MTD device brcmnand.0 [1.612696] Creating 9 MTD partitions on "brcmnand.0": [1.617940] 0x-0x0002 : "cferom" [1.625694] 0x0002-0x000c : "part_map" [1.633460] 0x000c-0x0020 : "cferam1" [1.643765] 0x0020-0x0034 : "cferam2" [1.653770] 0x0692-0x06a6 : "bootflag1" [1.661594] 0x06a6-0x06ba : "bootflag2" [1.669758] 0x0052-0x0692 : "wfi" [1.711952] [ cut here ] [1.716699] WARNING: CPU: 1 PID: 1 at kernel/sched/core.c:3609 finish_task_switch+0x19c/0x1a8 [1.721282] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 80090e08 [1.7213 And this was the last message from this unit. The router got bricked and now there is no message from the bootloader at the console. Sadly I won't be able to make more tests. Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
Hi Florian,
El mar, 8 feb 2022 a las 17:19, Florian Fainelli
() escribió:
>
>
>
> On 2/4/2022 2:57 PM, Florian Fainelli wrote:
> >
> >
> > On 2/4/2022 2:50 PM, Florian Fainelli wrote:
> >>
> >>
> >> On 2/4/2022 2:45 PM, Florian Fainelli wrote:
> >>>
> >>>
> >>> On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:
> El vie, 4 feb 2022 a las 23:02, Florian Fainelli
> () escribió:
> >
> >
> >
> > On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:
> >> So the problem is that SET_FEATURES and GET_FEATURES isn’t
> >> supported by versions 2.1, 2.2 and 4.0 of the nand controller,
> >> which are the ones present on bcm63xx, right?
> >
> > Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
> > being defined in the register database for the controllers v2.1 and
> > v2.2, v3.3. Staring with v4.0, the controllers do have the
> > CMD_LOW_LEVEL_OP. This is the version/feature table that I could
> > programmatically compile:
> >
> > version: 0.1, ll: no
> > version: 1.0, ll: no
> > version: 2.0, ll: no
> > version: 2.1, ll: no
> > version: 2.2, ll: no
> > version: 3.0, ll: no
> > version: 3.2, ll: no
> > version: 3.3, ll: no
> > version: 3.4, ll: no
> > version: 4.0, ll: yes
> > version: 5.0, ll: yes
> > version: 6.0, ll: yes
> > version: 6.2, ll: yes
> > version: 7.0, ll: yes
> > version: 7.1, ll: yes
> > version: 7.2, ll: yes
> > version: 7.3, ll: yes
> >
> > How about this patch, does it work better?
> >
> > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > index f75929783b94..06ac593beec0 100644
> > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > @@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
> > *chip, unsigned command,
> > break;
> > case NAND_CMD_SET_FEATURES:
> > case NAND_CMD_GET_FEATURES:
> > + if (ctrl->nand_version < 0x0400)
> > + break;
> > brcmnand_low_level_op(host, LL_OP_CMD, command,
> > false);
> > brcmnand_low_level_op(host, LL_OP_ADDR, column,
> > false);
> > break;
> >
> > --
> > Florian
>
> No, it didn't help:
> >>>
> >>> OK, last tentative and then I think you should report this to
> >>> linux-mtd such that the MTD maintainers may suggest whether we are
> >>> missing something obvious here:
> >>
> >> scratch that, can you try this instead:
> >
> > And also try this patch because I don't believe there is sufficient
> > protection in macronix_nand_block_protection_support to ensure that the
> > NAND chip is ONFI capable:
>
> Could you try this patch?
>
> >
> > diff --git a/drivers/mtd/nand/raw/nand_macronix.c
> > b/drivers/mtd/nand/raw/nand_macronix.c
> > index 1472f925f386..78f893add636 100644
> > --- a/drivers/mtd/nand/raw/nand_macronix.c
> > +++ b/drivers/mtd/nand/raw/nand_macronix.c
> > @@ -219,9 +219,13 @@ static int mxic_nand_unlock(struct nand_chip *chip,
> > loff_t ofs, uint64_t len)
> >
> > static void macronix_nand_block_protection_support(struct nand_chip
> > *chip)
> > {
> > + struct nand_parameters *p = >parameters;
> > u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
> > int ret;
> >
> > + if (!p->onfi || !chip->parameters.supports_set_get_features)
> > + return;
> > +
> > bitmap_set(chip->parameters.get_feature_list,
> > ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);
> >
> > Thanks!
>
> --
> Florian
I re-tested it again, it didn't work.
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
