[B.A.T.M.A.N.] How is the metric calculated and interpreted?

2016-02-16 Thread Sutter Nino
Hello there I have some basic Issues which I was not able to solve with the Wiki. How is the metric (?/255) calculated? Concerning the output of "batctl o" below, how can I interpret the following? -What is the meaning when the originator is the same as the next hop (Line 1)? -Is that correct

Re: [B.A.T.M.A.N.] pull request [net]: batman-adv 20160216

2016-02-16 Thread Antonio Quartulli
On Tue, Feb 16, 2016 at 11:01:25PM +0800, Antonio Quartulli wrote: > Hello David, > > this pull request is intended for net. David, when merging net into net-next these patches will create a conflict which git should try to fix on its own. However, it will still ask you to confirm something.

[B.A.T.M.A.N.] [PATCH] alfred: Allow setting the source mac via unix sock

2016-02-16 Thread Dominik Heidler
The server will only overwrite the mac if it is zero. Signed-off-by: Dominik Heidler --- The alfred client sets the mac to zero by default so this shouldn't break existing behaviour. unix_sock.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[B.A.T.M.A.N.] [PATCH 3/3] batman-adv: Avoid endless loop in bat-on-bat netdevice check

2016-02-16 Thread Antonio Quartulli
From: Andrew Lunn batman-adv checks in different situation if a new device is already on top of a different batman-adv device. This is done by getting the iflink of a device and all its parent. It assumes that this iflink is always a parent device in an acyclic graph. But this

[B.A.T.M.A.N.] [PATCH 1/3] batman-adv: Only put gw_node list reference when removed

2016-02-16 Thread Antonio Quartulli
From: Sven Eckelmann The batadv_gw_node reference counter in batadv_gw_node_update can only be reduced when the list entry was actually removed. Otherwise the reference counter may reach zero when batadv_gw_node_update is called from two different contexts for the same

[B.A.T.M.A.N.] [PATCH 2/3] batman-adv: Only put orig_node_vlan list reference when removed

2016-02-16 Thread Antonio Quartulli
From: Sven Eckelmann The batadv_orig_node_vlan reference counter in batadv_tt_global_size_mod can only be reduced when the list entry was actually removed. Otherwise the reference counter may reach zero when batadv_tt_global_size_mod is called from two different contexts for

[B.A.T.M.A.N.] pull request [net]: batman-adv 20160216

2016-02-16 Thread Antonio Quartulli
Hello David, this pull request is intended for net. Two of the fixes included in this patchset prevent a wrong memory access - it was triggered when removing an object from a list after it was already free'd due to bad reference counting. This misbehaviour existed for both the gw_node and the

[B.A.T.M.A.N.] [PATCH] batman-adv: Fix integer overflow in batadv_iv_ogm_calc_tq

2016-02-16 Thread Sven Eckelmann
From: Sven Eckelmann The undefined behavior sanatizer detected an signed integer overflow in a setup with near perfect link quality UBSAN: Undefined behaviour in net/batman-adv/bat_iv_ogm.c:1246:25 signed integer overflow: 8713350 * 255 cannot be

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: fix logic error in batadv_v_ogm_forward

2016-02-16 Thread Marek Lindner
On Monday, February 15, 2016 09:30:09 Sven Eckelmann wrote: > On Friday 12 February 2016 11:35:35 Simon Wunderlich wrote: > > From: Simon Wunderlich > > > > My latest restructure attempt of the BATMAN v forward function > > introduced a regression, causing kernel

Re: [B.A.T.M.A.N.] [PATCH 2/4] batman-adv: Speed up dat by snooping received ip traffic

2016-02-16 Thread Andreas Pape
> > @@ -412,11 +414,28 @@ void batadv_interface_rx(struct net_device > > *soft_iface, > > ethhdr = eth_hdr(skb); > > > > switch (ntohs(ethhdr->h_proto)) { > > + case ETH_P_IP: > > + iphdr = (struct iphdr *)(skb->data + ETH_HLEN); > > + /* snoop

[B.A.T.M.A.N.] Antwort: Re: [PATCH 3/4] batman-adv: prevent duplication of ARP replies in BLA setups when DAT does address resolution

2016-02-16 Thread Andreas Pape
Simon Wunderlich schrieb am 15.02.2016 09:27:02: > Von: Simon Wunderlich > An: b.a.t.m.a.n@lists.open-mesh.org > Kopie: Andreas Pape , Antonio Quartulli > > Datum: 15.02.2016 09:27 > Betreff: Re: