The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
---
net/batman-adv/distributed-arp-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c
index 3d21dd83f8cc..b85da4b7a77b 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -88,7 +88,7 @@ struct batadv_dhcp_packet {
__u8 sname[64];
__u8 file[128];
__be32 magic;
- __u8 options[0];
+ __u8 options[];
};
#define BATADV_DHCP_YIADDR_LEN sizeof(((struct batadv_dhcp_packet *)0)->yiaddr)
--
2.25.0
I looking for clarification about the following question
How can I connect non-mesh clients to my batman-adv network ?
Does this mean that for an existing batman node to allow non-mesh
clients to join (I.E. cell phone, wifi camera, etc..), then 2
interfaces are required?
For example, if I have a pi-zero W in a wooded area, and I want a
camera to connect to it, then do I need to add an additional usb
network adapter to the Pi. One Interface for the Bat0 Mesh and One
interface an an entry point for non-mesh clients.
any information is greatly appreciated.
Thanks
Zach
Hi all
I have tried to set up a mesh network according to the following tutorial:
https://www.open-mesh.org/projects/batman-adv/wiki/Quick-start-guide
Everything goes well until the steps for creating a bridge between
eth0 and bat0.
When running the command as shown below, it fails.
root@OpenWrt:~# ip link set eth0 master mesh-bridge
ip: either "dev" is duplicate, or "master" is garbage
I suspect that the ip version (BusyBox v1.28.4) I got does not support bridging?
Sincerely hope that someone can please guide me to solve this issue.
This is my HW/SW:
HW: TP-Link TL-WR841N and Ubiquiti M2 Bullet
OpenWrt 18.06.4, r7808-ef686b7292
As you see I have not the newest HW so that's the reason why I have
initially tried to use OpenWrt version 18.06.4 and not the newest
version.
Anyone that have experience with Batman on these wifi devices, please share.
Many thanks in advance for your help.
--
Regards
Emilie
On 2/7/20 9:51 AM, Simon Wunderlich wrote:
> On Friday, February 7, 2020 3:13:47 PM CET Steve Newcomb wrote:
>> @rpc152:/tmp/log# echo "$(logread)" | grep batman
>> Thu Feb 6 15:21:13 2020 kern.warn kernel: [174193.938445] batman_adv:
>> [Deprecated]: batctl (pid 22747) Use of debugfs file "nc_nodes".
>> @rpc152:/tmp/log#
>>
>>
>> What have I missed?
> Hi Steve,
>
> you can use "batctl log" to retrieve the log. It will not appear in your
> logread.
Alas, that doesn't work either, and I don't know why:
root@rpc152:~# batctl log
Error - no valid command or debug table specified: log
Usage: batctl [options] command|debug table [parameters]
options:
-h print this help (or 'batctl <command|debug table> -h' for
the parameter help)
-v print version
commands:
meshif <netdev> aggregation|ag [0|1] display or modify
aggregation setting
...
>
> When the problem happens, you can also check "iw wlan0 station dump"
> and other
> debug files (batctl n for neighbors) to find out if the WiFi layer is
> still
> working. It wouldn't be the first time that actually the WiFi chip or
> driver
> has a problem, not batman-adv.
I've seen that "batctl n" works, and "iw mesh0 station dump" works, too.
I am arranging for the nodes to send me such mail when things have gone
awry, but prior to rebooting. I've written a tiny mail queueing system
that optionally uses nonvolatile memory for the queue.
On Mon, 17 Feb 2020 22:16:59 +0800 Sven Eckelmann wrote:
>
> A transmission scheduling for an interface which is currently dropped by
> batadv_iv_ogm_iface_disable could still be in progress. The B.A.T.M.A.N. V
> is simply cancelling the workqueue item in an synchronous way but this is
> not possible with B.A.T.M.A.N. IV because the OGM submissions are
> intertwined.
>
> Instead it has to stop submitting the OGM when it detect that the buffer
> pointer is set to NULL.
>
> Reported-by: syzbot+a98f2016f40b9cd3818a(a)syzkaller.appspotmail.com
> Reported-by: syzbot+ac36b6a33c28a491e929(a)syzkaller.appspotmail.com
> Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
> Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
> ---
> Cc: Hillf Danton <hdanton(a)sina.com>
>
> I had this one in the pipeline but didn't find the time to correctly test
> it. You already send your one to syzkaller - do you want to rework your one
> (to also catch the broken submission on the same interface) and submit it?
> Or is this patch also ok for you? If it is, do you want to be mentioned in
Your work looks better, thanks :P
And a Cc is more than enough.
Hillf
> some way or form in this patch?
> ---
> net/batman-adv/bat_iv_ogm.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/batman-adv/bat_iv_ogm.c b/net/batman-adv/bat_iv_ogm.c
> index 5b0b20e6..bd514c36 100644
> --- a/net/batman-adv/bat_iv_ogm.c
> +++ b/net/batman-adv/bat_iv_ogm.c
> @@ -789,6 +789,10 @@ static void batadv_iv_ogm_schedule_buff(struct batadv_hard_iface *hard_iface)
>
> lockdep_assert_held(&hard_iface->bat_iv.ogm_buff_mutex);
>
> + /* interface already disabled in batadv_iv_ogm_iface_disable */
> + if (!*ogm_buff)
> + return;
> +
> /* the interface gets activated here to avoid race conditions between
> * the moment of activating the interface in
> * hardif_activate_interface() where the originator mac is set and
> --
> 2.20.1