Re: [OpenWrt-Devel] [PATCH 1/2] lantiq: atm: fix ifx_atm driver integration
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.--- Begin Message --- > On 16 Jun 2018, at 10:43, David Woodhouse wrote: > > >> The correct solution is to drop our ifx_atm_alloc_tx replacement hack >> entirely and let the kernel do its thing. > > You need to kill it in the ltq-atm driver too, surely? If you only kill > the hook, the module won't load. To paraphrase Edmund Blackadder III and the ‘Ravelling Nancy’ - I am one of these people who are quite happy to use modules, but have no idea how they work :-) # lsmod | grep atm atm38610 6 ltq_atm_vr9,pppoatm,br2684 drv_mei_cpe 147967 2 ltq_atm_vr9,drv_dsl_cpe_api ltq_atm_vr928749 1 ppp_generic24546 8 pppoe,pppox,ppp_async,pppoatm pppoatm 4080 1 Looks okay to me but happy to take advice/instruction. Cheers, Kevin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 0/3] ustream-ssl: support openssl 1.1.0, revised security
Tested-by: Rosen Penev On Fri, Jun 15, 2018 at 9:04 PM, Eneas U de Queiroz via openwrt-devel wrote: > 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. > > -- Forwarded message -- > From: Eneas U de Queiroz > To: openwrt-devel@lists.openwrt.org > Cc: Eneas U de Queiroz > Bcc: > Date: Sat, 16 Jun 2018 01:03:40 -0300 > Subject: [PATCH v3 0/3] ustream-ssl: support openssl 1.1.0, revised security > I've fixed a bug in the handling of BIO flags. > > I've made some changes to the security options used in the library, and > made them more uniform across all supported libraries (mbedtls, wolfssl, > openssl 1.0.2 & openssl 1.1.0). > The biggest, and probably most controversial change is in the > ciphersuite ordering. Here's my reasoning: > The first priority was key exchange, to provide forward-security. > Then comes encryption algorithm. AEAD ciphers are chosen first. They are > chacha20-poly1305 (256 bits), and aes-gcm (128 & 256 bits variants). > Among the three, I've selected chacha20-poly1305 because of higher > performance and strength. Here's a table generated by openssl speed on > ramips: > > ((openssl speed -evp chacha20-poly1305 | egrep "^(type|chacha)") && \ > (openssl speed -evp aes-128-gcm && openssl speed -evp aes-256-gcm) | \ > egrep "^aes") 2>/dev/null > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > 16384 bytes > chacha20-poly1305 6873.30k 10734.22k 12217.75k 12613.07k 12769.39k > 12665.00k > aes-128-gcm3759.88k 4280.96k 4415.66k4437.79k 4456.12k > 4436.88k > aes-256-gcm3408.83k 3738.10k 3838.52k3841.90k 3864.31k > 3882.17k > > I'm assuming most routers running openwrt are not going to have > AES-capable chips. If we were to run the benchmark in a newer server, > I'd bump AES-256 to the top. This is what it looks like in my x86_64: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > 16384 bytes > chacha20-poly1305 206412.13k 400740.77k 788942.85k 869130.38k 899400.83k > 893596.97k > aes-128-gcm 283449.15k 730408.60k 1074886.58k 1176372.95k 1232831.03k > 1245781.87k > aes-256-gcm 238760.79k 660843.45k 967903.44k 1071756.62k 1089887.49k > 1089552.89k > > This could be added as an option, or selected automatically depending on > architecture. The difference is more dramatic for the lesser capable > chips anyway. > You can check your "grade" at https://www.ssllabs.com/ssltest/. You'll > get an A on openssl and mbedtls, and an A- with wolfssl--the minus is > due to lack of secure renegotiation. There's an option to enable it, but > wolfssl does not recommend using it.I've made some changes to the > security options used in the library, and made them more uniform across > all supported libraries (mbedtls, wolfssl, openssl 1.0.2 & openssl > 1.1.0) > > The mbedtls patch can be applied on its own, independent of the openssl > patch. > > Eneas U de Queiroz (3): > ustream-ssl: add openssl-1.1.0 compatibility > ustream-ssl: Revised security on openssl/wolfssl > ustream-ssl: Revised security on mbedtls > > openssl_bio_compat.h | 33 ++ > ustream-io-openssl.c | 46 +++--- > ustream-mbedtls.c| 49 +++- > ustream-openssl.c| 80 > > 4 files changed, 146 insertions(+), 62 deletions(-) > create mode 100644 openssl_bio_compat.h > > -- > 2.16.4 > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] dropbear: Install to /(s)bin instead of /usr so OpenSSH can coexist
If you run opkg install openssh-client and then remove it, the ssh client symlink that was initially there goes away. This avoids that problem. Signed-off-by: Rosen Penev --- package/network/services/dropbear/Makefile | 18 +- .../services/dropbear/files/dropbear.init | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/package/network/services/dropbear/Makefile b/package/network/services/dropbear/Makefile index 21ac09f724..41f51b284b 100644 --- a/package/network/services/dropbear/Makefile +++ b/package/network/services/dropbear/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=dropbear PKG_VERSION:=2017.75 -PKG_RELEASE:=5 +PKG_RELEASE:=6 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:= \ @@ -57,7 +57,7 @@ endef define Package/dropbear/conffiles /etc/dropbear/dropbear_rsa_host_key -/etc/config/dropbear +/etc/config/dropbear endef define Package/dropbearconvert @@ -128,13 +128,13 @@ define Build/Compile endef define Package/dropbear/install - $(INSTALL_DIR) $(1)/usr/sbin - $(INSTALL_BIN) $(PKG_BUILD_DIR)/dropbearmulti $(1)/usr/sbin/dropbear - $(INSTALL_DIR) $(1)/usr/bin - $(LN) ../sbin/dropbear $(1)/usr/bin/scp - $(LN) ../sbin/dropbear $(1)/usr/bin/ssh - $(LN) ../sbin/dropbear $(1)/usr/bin/dbclient - $(LN) ../sbin/dropbear $(1)/usr/bin/dropbearkey + $(INSTALL_DIR) $(1)/sbin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/dropbearmulti $(1)/sbin/dropbear + $(INSTALL_DIR) $(1)/bin + $(LN) ../sbin/dropbear $(1)/bin/scp + $(LN) ../sbin/dropbear $(1)/bin/ssh + $(LN) ../sbin/dropbear $(1)/bin/dbclient + $(LN) ../sbin/dropbear $(1)/bin/dropbearkey $(INSTALL_DIR) $(1)/etc/config $(INSTALL_DATA) ./files/dropbear.config $(1)/etc/config/dropbear $(INSTALL_DIR) $(1)/etc/init.d diff --git a/package/network/services/dropbear/files/dropbear.init b/package/network/services/dropbear/files/dropbear.init index 2225113498..d9a6bd4959 100755 --- a/package/network/services/dropbear/files/dropbear.init +++ b/package/network/services/dropbear/files/dropbear.init @@ -6,7 +6,7 @@ START=50 STOP=50 USE_PROCD=1 -PROG=/usr/sbin/dropbear +PROG=/sbin/dropbear NAME=dropbear PIDCOUNT=0 EXTRA_COMMANDS="killclients" -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] Regression in interface names & /etc/config/network (ethX order)
Hi, I noticed a regression in openwrt-18.06 and master branches after switching from kernel 4.9 to 4.14. I have Tenda AC9 device which has two Ethernet interfaces connected to the same switch. Only the first interface provides MDIO bus with PHY access to the switch. That is used by b53 switch driver. With 4.9 kernel bgmac gets probed twice. The first probe (for the first Ethernet code) calls mdiobus_register() and it succeeds. That results in eth0 being created. Then second bgmac happens and eth1 is created. With 4.14 kernel bgmac probe for the first Ethernet code fails on the first try. mdiobus_register returns EPROBE_DEFER. Then second Ethernet code is being problem and it succeeds getting eth0 interface. Then the first interface gets probed *again* and is gets eth1. Long story short: with 4.14 eth0 and eth1 are reversed due to the EPROBE_DEFER for the first Ethernet interface. Unfortunately target/linux/bcm53xx/base-files/etc/board.d/02_network depends on eth0 and eth1 order. Having it different breaks network configuration. Do you have any suggestion on the fix? Should we debug why EPROBE_DEFER happens? Or should we rather make 02_network more generic and somehow: 1) Wait for all interfaces to be ready 2) Find interface name by Ethernet code number Please note that above solution, as it sounds nice, will still break for sysupgrade. Any comments, ideas? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/4] ath79: add Netgear WNR612 v2
On 13.06.2018 11:51, Zoltan HERPAI wrote: + ucidef_set_led_wlan "wlan" "WLAN" "netgear:green:wlan" "phy0tpt" is this needed ? @juppin just made a cleanup for wifi triggers https://github.com/openwrt/openwrt/commit/14cb05909a8dc6e42008697b4fe47b8fa00789d8 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
On Sat, 2018-06-16 at 09:48 +, David Woodhouse wrote: > > > Backport a hot off the press upstream kernel ATM fix: > > > > Preserve value of skb->truesize when accounting to vcc > > > > "There's a hack in pskb_expand_head() to avoid adjusting skb->truesize > > for certain skbs. Ideally it would cover ATM too. It doesn't. Just > > stashing the accounted value and using it in atm_raw_pop() is probably > > the easiest way to cope." > > > > The issue was introduced in upstream by: > > > > commit 14afee4b6092fde451ee17604e5f5c89da33e71e > > Author: Reshetova, Elena > > Date: Fri Jun 30 13:08:00 2017 +0300 > > > > net: convert sock.sk_wmem_alloc from atomic_t to refcount_t > > > > Sincerest thanks to Mathias Kresin for debugging > > assistance and to David Woodhouse for further > > guidance, cajoling & patience in interpreting the debug I was giving him > > and producing a fix! > > > > Fixes FS#1567 > > Is it tested with PPPoA+LLC-encaps and (more importantly) PPPoE+BR2684? > (Please) Ah, I see your 5am assertion that it is. Thanks again for going above and beyond to help diagnose and fix this. smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
> Backport a hot off the press upstream kernel ATM fix: > > Preserve value of skb->truesize when accounting to vcc > > "There's a hack in pskb_expand_head() to avoid adjusting skb->truesize > for certain skbs. Ideally it would cover ATM too. It doesn't. Just > stashing the accounted value and using it in atm_raw_pop() is probably > the easiest way to cope." > > The issue was introduced in upstream by: > > commit 14afee4b6092fde451ee17604e5f5c89da33e71e > Author: Reshetova, Elena > Date: Fri Jun 30 13:08:00 2017 +0300 > > net: convert sock.sk_wmem_alloc from atomic_t to refcount_t > > Sincerest thanks to Mathias Kresin for debugging > assistance and to David Woodhouse for further > guidance, cajoling & patience in interpreting the debug I was giving him > and producing a fix! > > Fixes FS#1567 Is it tested with PPPoA+LLC-encaps and (more importantly) PPPoE+BR2684? (Please) -- dwmw2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] lantiq: atm: fix ifx_atm driver integration
> The correct solution is to drop our ifx_atm_alloc_tx replacement hack > entirely and let the kernel do its thing. You need to kill it in the ltq-atm driver too, surely? If you only kill the hook, the module won't load. -- dwmw2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/2] lantiq: atm: fix ifx_atm driver integration
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.--- Begin Message ---
When upstream kernel introduced commit c55fa3cccbc2c672e7f118be8f7484e53a8e9e77
we incorrectly updated our hack integration patch that updates atm/common.c
+++ b/net/atm/common.c
@@ -62,10 +62,16 @@ static void vcc_remove_socket(struct soc
write_unlock_irq(_sklist_lock);
}
+struct sk_buff* (*ifx_atm_alloc_tx)(struct atm_vcc *, unsigned int) = NULL;
+EXPORT_SYMBOL(ifx_atm_alloc_tx);
+
static bool vcc_tx_ready(struct atm_vcc *vcc, unsigned int size)
{
struct sock *sk = sk_atm(vcc);
+ if (ifx_atm_alloc_tx != NULL)
+ return ifx_atm_alloc_tx(vcc, size)
The correct solution is to drop our ifx_atm_alloc_tx replacement hack
entirely and let the kernel do its thing.
In reality neither pppoatm or BR2684 interfaces actually hit this code,
so the incorrect integration would only be noticed with direct socket
calls which we are unaware of a use-case.
This is not the solution to pppoatm vc-mux failing to work which started
the whole investigation, but let's fix it up anyway.
With sincerest thanks to David Woodhouse &
Mathias Kresin .
Tested-on: lantiq, BT HomeHub 5a
Signed-off-by: Kevin Darbyshire-Bryant
---
v2 - tweak to contributor credits, signed off by typo and a bit of
original fix residue that was missed.
.../patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch | 19 ---
1 file changed, 19 deletions(-)
diff --git
a/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
b/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
index 2c73cec55c..66ca2fd5ac 100644
--- a/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
+++ b/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
@@ -467,25 +467,6 @@ Signed-off-by: John Crispin
struct atm_trafprm {
unsigned char traffic_class; /* traffic class (ATM_UBR, ...) */
int max_pcr;/* maximum PCR in cells per second */
a/net/atm/common.c
-+++ b/net/atm/common.c
-@@ -62,10 +62,16 @@ static void vcc_remove_socket(struct soc
- write_unlock_irq(_sklist_lock);
- }
-
-+struct sk_buff* (*ifx_atm_alloc_tx)(struct atm_vcc *, unsigned int) = NULL;
-+EXPORT_SYMBOL(ifx_atm_alloc_tx);
-+
- static bool vcc_tx_ready(struct atm_vcc *vcc, unsigned int size)
- {
- struct sock *sk = sk_atm(vcc);
-
-+ if (ifx_atm_alloc_tx != NULL)
-+ return ifx_atm_alloc_tx(vcc, size);
-+
- if (sk_wmem_alloc_get(sk) && !atm_may_send(vcc, size)) {
- pr_debug("Sorry: wmem_alloc = %d, size = %d, sndbuf = %d\n",
-sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
--- a/net/atm/proc.c
+++ b/net/atm/proc.c
@@ -155,7 +155,7 @@ static void *vcc_seq_next(struct seq_fil
--
2.15.1 (Apple Git-101)
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 2/2] kernel: atm: pppoatm fix vc-mux connection failures
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.--- Begin Message ---
Backport a hot off the press upstream kernel ATM fix:
Preserve value of skb->truesize when accounting to vcc
"There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
for certain skbs. Ideally it would cover ATM too. It doesn't. Just
stashing the accounted value and using it in atm_raw_pop() is probably
the easiest way to cope."
The issue was introduced in upstream by:
commit 14afee4b6092fde451ee17604e5f5c89da33e71e
Author: Reshetova, Elena
Date: Fri Jun 30 13:08:00 2017 +0300
net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
Sincerest thanks to Mathias Kresin for debugging
assistance and to David Woodhouse for further
guidance, cajoling & patience in interpreting the debug I was giving him
and producing a fix!
Fixes FS#1567
Signed-off-by: Kevin Darbyshire-Bryant
---
...-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch | 186 +
1 file changed, 186 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
diff --git
a/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
b/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
new file mode 100644
index 00..8108d99348
--- /dev/null
+++
b/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
@@ -0,0 +1,186 @@
+From 99967eb67d14b2ed17b194a8dac357d641a06e43 Mon Sep 17 00:00:00 2001
+From: David Woodhouse
+Date: Fri, 15 Jun 2018 21:00:27 +0100
+Subject: [PATCH] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
+
+On Fri, 2018-06-15 at 14:44 +0100, David Woodhouse wrote:
+>
+> > Or simply use a new field in ATM_SKB(skb) to remember a stable
+> > truesize used in both sides (add/sub)
+>
+> Right, that was my second suggestion ("copy the accounted value...").
+>
+> It's a bit of a hack, and I think that actually *using* sock_wfree()
+> instead of what's currently in atm_pop_raw() would be the better
+> solution. Does anyone remember why we didn't do that in the first
+> place?
+
+That does end up being quite hairy. I don't think it's worth doing.
+
+This should probably suffice to fix it...
+
+Kevin this is going to conflict with the ifx_atm_alloc_skb() hack in
+the tree you're working on, but that needs to be killed with fire
+anyway. It's utterly pointless as discussed.
+
+From 3368eaeb0a2f09138894dde0f26f879e5228005a Mon Sep 17 00:00:00 2001
+From: David Woodhouse
+Date: Fri, 15 Jun 2018 20:49:20 +0100
+Subject: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
+
+There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
+for certain skbs. Ideally it would cover ATM too. It doesn't. Just
+stashing the accounted value and using it in atm_raw_pop() is probably
+the easiest way to cope.
+
+Signed-off-by: David Woodhouse
+Signed-off-by: Kevin Darbyshire-Bryant
+---
+ include/linux/atmdev.h | 15 +++
+ net/atm/br2684.c | 3 +--
+ net/atm/clip.c | 3 +--
+ net/atm/common.c | 3 +--
+ net/atm/lec.c | 3 +--
+ net/atm/mpc.c | 3 +--
+ net/atm/pppoatm.c | 3 +--
+ net/atm/raw.c | 4 ++--
+ 8 files changed, 23 insertions(+), 14 deletions(-)
+
+diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
+index 0c27515d..8124815e 100644
+--- a/include/linux/atmdev.h
b/include/linux/atmdev.h
+@@ -214,6 +214,7 @@ struct atmphy_ops {
+ struct atm_skb_data {
+ struct atm_vcc *vcc; /* ATM VCC */
+ unsigned long atm_options;/* ATM layer options */
++ unsigned intacct_truesize; /* truesize accounted to vcc */
+ };
+
+ #define VCC_HTABLE_SIZE 32
+@@ -241,6 +242,20 @@ void vcc_insert_socket(struct sock *sk);
+
+ void atm_dev_release_vccs(struct atm_dev *dev);
+
++static inline void atm_account_tx(struct atm_vcc *vcc, struct sk_buff *skb)
++{
++ /*
++ * Because ATM skbs may not belong to a sock (and we don't
++ * necessarily want to), skb->truesize may be adjusted,
++ * escaping the hack in pskb_expand_head() which avoids
++ * doing so for some cases. So stash the value of truesize
++ * at the time we accounted it, and atm_pop_raw() can use
++ * that value later, in case it changes.
++ */
++ refcount_add(skb->truesize, _atm(vcc)->sk_wmem_alloc);
++ ATM_SKB(skb)->acct_truesize = skb->truesize;
++ ATM_SKB(skb)->atm_options = vcc->atm_options;
++}
+
+ static inline void atm_force_charge(struct atm_vcc *vcc,int truesize)
+ {
+diff --git a/net/atm/br2684.c b/net/atm/br2684.c
+index 4e96..bc21f8e8 100644
+--- a/net/atm/br2684.c
Re: [OpenWrt-Devel] [PATCH 1/4] tools: build squashfs (v3) for ath79
14.06.2018 22:38, Zoltan HERPAI: Felix Fietkau wrote: How about this instead: tools-$(CONFIG_TARGET_ar71xx)$(CONFIG_TARGET_ath79) += squashfs - Felix I'm happy with either, whichever you guys fancy. Thanks, -w- I like felix proposed solution more than what I had and committed it instead. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: fixup TL-WR703N/TL-MR10U split
12.06.2018 22:54, Alex Maclean: Readd SoC compatible strings and correct model names mangled in a51078f7354fac9e31f6956cbddc77aaef02c67b, cleanup dts to remove duplication, rename dtsi for clarity, use correct GPIO for TL-MR10U USB power. Tested only on TL-WR703N due to lack of a TL-MR10U. Signed-off-by: Alex Maclean Merged, thanks! Would be anyone so kind to set the patch status to accepted in patchwork. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] lantiq: atm: fix ifx_atm driver integration
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.--- Begin Message ---
When upstream kernel introduced commit c55fa3cccbc2c672e7f118be8f7484e53a8e9e77
we incorrectly updated our hack integration patch that updates atm/common.c
+++ b/net/atm/common.c
@@ -62,10 +62,16 @@ static void vcc_remove_socket(struct soc
write_unlock_irq(_sklist_lock);
}
+struct sk_buff* (*ifx_atm_alloc_tx)(struct atm_vcc *, unsigned int) = NULL;
+EXPORT_SYMBOL(ifx_atm_alloc_tx);
+
static bool vcc_tx_ready(struct atm_vcc *vcc, unsigned int size)
{
struct sock *sk = sk_atm(vcc);
+ if (ifx_atm_alloc_tx != NULL)
+ return ifx_atm_alloc_tx(vcc, size)
The correct solution is to drop our ifx_atm_alloc_tx replacement hack
entirely and let the kernel do its thing.
In reality neither pppoatm or BR2684 interfaces actually hit this code,
so the incorrect integration would only be noticed with direct socket
calls which we are unaware of a use-case.
This is not the solution to pppoatm vc-mux failing to work which started
the whole investigation, but let's fix it up anyway.
With sincerest thanks to dwmw2 & mkresin.
Tested-on: lantiq, BT HomeHub 5a
Signed-of-by: Kevin Darbyshire-Bryant
Signed-off-by: Kevin Darbyshire-Bryant
---
.../lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
a/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
b/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
index 2c73cec55c..a3441f8533 100644
--- a/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
+++ b/target/linux/lantiq/patches-4.14/0004-MIPS-lantiq-add-atm-hack.patch
@@ -469,7 +469,7 @@ Signed-off-by: John Crispin
int max_pcr;/* maximum PCR in cells per second */
--- a/net/atm/common.c
+++ b/net/atm/common.c
-@@ -62,10 +62,16 @@ static void vcc_remove_socket(struct soc
+@@ -62,6 +62,9 @@ static void vcc_remove_socket(struct soc
write_unlock_irq(_sklist_lock);
}
@@ -479,13 +479,6 @@ Signed-off-by: John Crispin
static bool vcc_tx_ready(struct atm_vcc *vcc, unsigned int size)
{
struct sock *sk = sk_atm(vcc);
-
-+ if (ifx_atm_alloc_tx != NULL)
-+ return ifx_atm_alloc_tx(vcc, size);
-+
- if (sk_wmem_alloc_get(sk) && !atm_may_send(vcc, size)) {
- pr_debug("Sorry: wmem_alloc = %d, size = %d, sndbuf = %d\n",
-sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
--- a/net/atm/proc.c
+++ b/net/atm/proc.c
@@ -155,7 +155,7 @@ static void *vcc_seq_next(struct seq_fil
--
2.15.1 (Apple Git-101)
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] kernel: atm: pppoatm fix vc-mux connection failures
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.--- Begin Message ---
Backport a hot off the press upstream kernel ATM fix:
Preserve value of skb->truesize when accounting to vcc
"There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
for certain skbs. Ideally it would cover ATM too. It doesn't. Just
stashing the accounted value and using it in atm_raw_pop() is probably
the easiest way to cope."
The issue was introduced in upstream by:
commit 14afee4b6092fde451ee17604e5f5c89da33e71e
Author: Reshetova, Elena
Date: Fri Jun 30 13:08:00 2017 +0300
net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
Sincerest thanks to Mathias Kresin for debugging
assistance and to David Woodhouse for further
guidance, cajoling & patience in interpreting the debug I was giving him
and producing a fix!
Fixes FS#1567
Signed-off-by: Kevin Darbyshire-Bryant
---
...-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch | 186 +
1 file changed, 186 insertions(+)
create mode 100644
target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
diff --git
a/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
b/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
new file mode 100644
index 00..8108d99348
--- /dev/null
+++
b/target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch
@@ -0,0 +1,186 @@
+From 99967eb67d14b2ed17b194a8dac357d641a06e43 Mon Sep 17 00:00:00 2001
+From: David Woodhouse
+Date: Fri, 15 Jun 2018 21:00:27 +0100
+Subject: [PATCH] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
+
+On Fri, 2018-06-15 at 14:44 +0100, David Woodhouse wrote:
+>
+> > Or simply use a new field in ATM_SKB(skb) to remember a stable
+> > truesize used in both sides (add/sub)
+>
+> Right, that was my second suggestion ("copy the accounted value...").
+>
+> It's a bit of a hack, and I think that actually *using* sock_wfree()
+> instead of what's currently in atm_pop_raw() would be the better
+> solution. Does anyone remember why we didn't do that in the first
+> place?
+
+That does end up being quite hairy. I don't think it's worth doing.
+
+This should probably suffice to fix it...
+
+Kevin this is going to conflict with the ifx_atm_alloc_skb() hack in
+the tree you're working on, but that needs to be killed with fire
+anyway. It's utterly pointless as discussed.
+
+From 3368eaeb0a2f09138894dde0f26f879e5228005a Mon Sep 17 00:00:00 2001
+From: David Woodhouse
+Date: Fri, 15 Jun 2018 20:49:20 +0100
+Subject: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc
+
+There's a hack in pskb_expand_head() to avoid adjusting skb->truesize
+for certain skbs. Ideally it would cover ATM too. It doesn't. Just
+stashing the accounted value and using it in atm_raw_pop() is probably
+the easiest way to cope.
+
+Signed-off-by: David Woodhouse
+Signed-off-by: Kevin Darbyshire-Bryant
+---
+ include/linux/atmdev.h | 15 +++
+ net/atm/br2684.c | 3 +--
+ net/atm/clip.c | 3 +--
+ net/atm/common.c | 3 +--
+ net/atm/lec.c | 3 +--
+ net/atm/mpc.c | 3 +--
+ net/atm/pppoatm.c | 3 +--
+ net/atm/raw.c | 4 ++--
+ 8 files changed, 23 insertions(+), 14 deletions(-)
+
+diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
+index 0c27515d..8124815e 100644
+--- a/include/linux/atmdev.h
b/include/linux/atmdev.h
+@@ -214,6 +214,7 @@ struct atmphy_ops {
+ struct atm_skb_data {
+ struct atm_vcc *vcc; /* ATM VCC */
+ unsigned long atm_options;/* ATM layer options */
++ unsigned intacct_truesize; /* truesize accounted to vcc */
+ };
+
+ #define VCC_HTABLE_SIZE 32
+@@ -241,6 +242,20 @@ void vcc_insert_socket(struct sock *sk);
+
+ void atm_dev_release_vccs(struct atm_dev *dev);
+
++static inline void atm_account_tx(struct atm_vcc *vcc, struct sk_buff *skb)
++{
++ /*
++ * Because ATM skbs may not belong to a sock (and we don't
++ * necessarily want to), skb->truesize may be adjusted,
++ * escaping the hack in pskb_expand_head() which avoids
++ * doing so for some cases. So stash the value of truesize
++ * at the time we accounted it, and atm_pop_raw() can use
++ * that value later, in case it changes.
++ */
++ refcount_add(skb->truesize, _atm(vcc)->sk_wmem_alloc);
++ ATM_SKB(skb)->acct_truesize = skb->truesize;
++ ATM_SKB(skb)->atm_options = vcc->atm_options;
++}
+
+ static inline void atm_force_charge(struct atm_vcc *vcc,int truesize)
+ {
+diff --git a/net/atm/br2684.c b/net/atm/br2684.c
+index 4e96..bc21f8e8 100644
+--- a/net/atm/br2684.c
