similar to: [Bridge] Netfilter hooks

Hi, I found this block of code in br_dev_queue_xmit() @ br_forward.c, after applying 'netfilter' patch for 2.4.21 kernel Can someone explain what this block of code is doin? #ifdef CONFIG_NETFILTER if (skb->nf_bridge) memcpy(skb->data - 16, skb->nf_bridge->hh, 16); #endif 1. What is 16 bytes here...? Ethernet hdr is just 14 bytes 2. Why the ethernet

Hi all, The patch below does four trivial changes and one big change Trivial changes, these are all in br_netfilter.c: - check ar_pln==4 when giving bridged ARP packets to arptables - delete unnecessary if in br_nf_local_in - add more logging for the "Argh" message - add some brag-comments in the file head comment Big change: let {ip,arp}tables see VLAN tagged {I,AR}P packets. This

This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase readability. Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990 at gmail.com> --- net/bridge/netfilter/ebtable_broute.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/bridge/netfilter/ebtable_broute.c b/net/bridge/netfilter/ebtable_broute.c index 40d8258..70f656c 100644 ---

Hi, i am currently trying to code a little netfilter plugin, to be placed into the bridge forwarding path. In such plugin, i would like to test if a packet is: - unicast - multicast - broadcast The starting condition is that the bridge has no knowledge of the IP configuration of the sending and receiving stations. It does not know about their netmask e.g. I have tried the following function

On Wed, Aug 16, 2023 at 05:34:43PM +0800, GONG, Ruiqi wrote: > From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> > > As suggested by Kees[1], replace the old-style 0-element array members > of multiple structs in ebtables.h with modern C99 flexible array. > > [1]: https://lore.kernel.org/all/5E8E0F9C-EE3F-4B0D-B827-DC47397E2A4A at kernel.org/ > > Link:

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

An earlier variant of your patch was applied already, included below. You'll need to submit the newer parts relative to the current tree. diff-tree 7ad4d2f6901437ba4717a26d395a73ea362d25c6 (from b8282dcf0417bbc8a0786c129fdff9cc768f8f3c) Author: Jayachandran C <c.jayachandran@gmail.com> Date: Tue Apr 11 17:25:38 2006 -0700 [BRIDGE] ebtables: fix allocation in

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to ?__read_overflow2_field? declared with attribute warning: detected read beyond

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> As suggested by Kees[1], replace the old-style 0-element array members of multiple structs in ebtables.h with modern C99 flexible array. [1]: https://lore.kernel.org/all/5E8E0F9C-EE3F-4B0D-B827-DC47397E2A4A at kernel.org/ Link: https://github.com/KSPP/linux/issues/21 Signed-off-by: GONG, Ruiqi <gongruiqi1 at huawei.com>

Hello I'm iCAROS7 and my syzkaller hit vmalloc-OOB in net/bridge/netfilter/ebtables.c:1168 I not sure about that and related bridge. But report for just-in-case. I attached C reproducer and syzkaller report. Thank you for your deication. >From iCAROS7. <Information of my syzkaller system> CPU: Intel i7-12700K OS: Kubuntu 22.04.1 LTS (amd64) Kernel: 5.18.19-051819-generic Syzkaller

Hi folks, in 2.4 kernels, device matching for bridged packets was done with iptables -i/-o. Since 2.6, I was used to use -m physdev here. In 2.6.18, This seems to be more complicated. At least the filter/INPUT chain now doesn't match with -m physdev --physdev-in anymore, but FORWARD and OUTPUT does. I also read the note that -m phydev is now deprecated for non-bridged traffic. Does this

Hi, I met a problem when using bridge with netfilter. The kernel version 2.4.20, and the patch is bridge-nf-0.0.10-against-2.4.20.diff. Our firewall configuration is as follows, eth3,eth4,eth5,eth6 configured as a bridge with an IP address 10.0.0.1. The local net connect to the internet via the gateway 10.0.0.1 and SNAT is applied on the firewall. It worked but sometimes there are some

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> It's a known issue that the password will be set to silly value, most likely 'yes'. </div> <div> <br> </div> <div> You should generate the user key during provisioning with `doveadm cryptokey generate -Uu

Hi, This is a second try to fix the long chain call lengths in netfilter. The difference with the previous patch is that I got rid of the extra argument. I somehow didn't see it could be done without using the 'int *ret2' argument. A comment on the number of arguments to nf_hook_slow: I don't think the number of arguments should be decreased. For the bridge-nf code, f.e., the

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> Technically creating and encrypting folder key does not require decrypting user's private key. All folder keys are encrypted with user's public key. </div> <div> <br> </div> <div> Aki </div>