Re: [B.A.T.M.A.N.] [PATCH 1/2] batman-adv: remove forward declaration by including proper header

On Friday 13 May 2016 05:07:18 Antonio Quartulli wrote: [...] > ok, how about adding it to any header file than (which is probably what you > were suggesting in the first place)? Yes, this was my first suggestion. Just packet.h and main.h have to be left out. I can also add a check to the daily

[B.A.T.M.A.N.] [PATCH v2] batman-adv: B.A.T.M.A.N. V - implement hard-iface init function

Some fields in the hard-interface data structure are specific to the B.A.T.M.A.N. V protocol and have to be initialized only when such protocol is compiled in. Instead of having a #ifdef block in the middle of the hard-interface.c code it is better to have an algorithm private function that hides

Re: [B.A.T.M.A.N.] [PATCH 1/2] batman-adv: remove forward declaration by including proper header

On Wed, May 11, 2016 at 02:24:04PM +0200, Sven Eckelmann wrote: > On Wednesday 11 May 2016 18:47:30 Antonio Quartulli wrote: > [...] > > Maybe I could include it only when really needed, i.e. > > * net/batman-adv/bat_algo.h > > * net/batman-adv/bat_v_ogm.h > > > > (netlink.h does not seem to be

Re: [B.A.T.M.A.N.] [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper

On 05/03/2016 10:33 AM, Florian Westphal wrote: > Replace all trans_start updates with netif_trans_update helper. > change was done via spatch: > > struct net_device *d; > @@ > - d->trans_start = jiffies > + netif_trans_update(d) > > Compile tested only. > > Cc:

[B.A.T.M.A.N.] [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

If a VLAN tagged frame is received and the corresponding VLAN is not configured on the soft interface, it will splat a WARN on every packet received. This is a quite annoying behaviour for some scenarios, e.g. if bat0 is bridged with eth0, and there are arbitrary VLAN tagged frames from Ethernet

[B.A.T.M.A.N.] [PATCH-maint] batman-adv: replace WARN with rate limited output on non-existing VLAN

If a VLAN tagged frame is received and the corresponding VLAN is not configured on the soft interface, it will splat a WARN on every packet received. This is a quite annoying behaviour for some scenarios, e.g. if bat0 is bridged with eth0, and there are arbitrary VLAN tagged frames from Ethernet

Re: [B.A.T.M.A.N.] [PATCHv15 4/4] batman-adv: Add debugfs table for mcast flags

On Tuesday, May 10, 2016 18:41:27 Linus Lüssing wrote: > This patch adds a debugfs table with originators and their according > multicast flags to help users figure out why multicast optimizations > might be enabled or disabled for them. > > Tested-by: Simon Wunderlich >

Re: [B.A.T.M.A.N.] [PATCHv15 3/4] batman-adv: Adding logging of mcast flag changes

On Tuesday, May 10, 2016 18:41:26 Linus Lüssing wrote: > With this patch changes relevant to a node's own multicast flags are > printed to the 'mcast' log level. > > Tested-by: Simon Wunderlich > Signed-off-by: Linus Lüssing > --- >

Re: [B.A.T.M.A.N.] [PATCHv15 2/4] batman-adv: Add multicast optimization support for bridged setups

On Tuesday, May 10, 2016 18:41:25 Linus Lüssing wrote: > With this patch we are finally able to support multicast optimizations > in bridged setups, too. So far, if a bridge was added on top of a > soft-interface (e.g. bat0) the batman-adv multicast optimizations > needed to be disabled to avoid

Re: [B.A.T.M.A.N.] [PATCHv15 1/4] batman-adv: Always flood IGMP/MLD reports

On Tuesday, May 10, 2016 18:41:24 Linus Lüssing wrote: > With this patch IGMP or MLD reports are always flooded. This is > necessary for the upcoming bridge integration to function without > multicast packet loss. > > With the report handling so far bridges might miss interested multicast >

Re: [B.A.T.M.A.N.] Problem with DHCP on batman-adv V

Thank you Sven and Antonio, I will try both options. Best regards, On Thu, May 12, 2016 at 5:57 AM, Antonio Quartulli wrote: > On Thu, May 12, 2016 at 07:05:20AM +0200, Sven Eckelmann wrote: >> On Wednesday 11 May 2016 18:58:48 Alvaro Antelo wrote: >> > Hi everyone, >> > >> >

Re: [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: Include frame priority in fragment header

On Monday, May 09, 2016 20:03:36 Andrew Lunn wrote: > Unfragmented frames which traverse a node have their skb->priority set > by looking at the IP ToS byte, or the 802.1p header. However for > fragments this is not possible, only one of the fragments will contain > the headers. Instead, place the

Re: [B.A.T.M.A.N.] Problem with DHCP on batman-adv V

On Thu, May 12, 2016 at 07:05:20AM +0200, Sven Eckelmann wrote: > On Wednesday 11 May 2016 18:58:48 Alvaro Antelo wrote: > > Hi everyone, > > > > I am testing batman-adv V5 from the development feed on Chaos Calmer > > and so far everything is working except for DHCP IPv4, only static > >

[B.A.T.M.A.N.] [PATCH v4 6/6] batman-adv: handle race condition for claims between gateways

Consider the following situation which has been found in a test setup: Gateway B has claimed client C and gateway A has the same backbone network as B. C sends a broad- or multicast to B and directly after this packet decides to send another packet to A due to a better TQ value. B will forward the

[B.A.T.M.A.N.] [PATCH v4 5/6] batman-adv: changed debug messages for easier bla debugging

Some of the bla debug messages are extended and additional messages are added for easier bla debugging. Some debug messages introduced with the dat changes in prior patches of this patch series have been changed to be more compliant to other existing debug messages. Acked-by: Simon Wunderlich

[B.A.T.M.A.N.] [PATCH v4 4/6] batman-adv: drop unicast packets from other backbone gw

Additional dropping of unicast packets received from another backbone gw of the same backbone network before being forwarded to the same backbone again is necessary. It was observed in a test setup that in rare cases these frames lead to looping unicast traffic backbone->mesh->backbone.

[B.A.T.M.A.N.] [PATCH v4 1/6] batman-adv: prevent multiple ARP replies sent by gateways if dat enbled

If dat is enabled it must be made sure that only the backbone gw which has claimed the remote destination for the ARP request answers the ARP request directly if the MAC address is known due to the local dat table. This prevents multiple ARP replies in a common backbone if more than one gateway

[B.A.T.M.A.N.] [PATCH v4 3/6] batman-adv: prevent duplication of ARP replies when DAT is used

If none of the backbone gateways in a bla setup has already knowledge of the mac address searched for in an incoming ARP request from the backbone an address resolution via the DHT of DAT is started. The gateway can send several ARP requests to different DHT nodes and therefore can get several

[B.A.T.M.A.N.] [PATCH v4 2/6] batman-adv: speed up dat by snooping received ip traffic

Speeding up dat address lookup is achieved by snooping all incoming ip traffic. This especially increases the propability in bla setups that a gateway into a common backbone network already has a fitting dat entry to answer incoming ARP requests directly coming from the backbone network thus

[B.A.T.M.A.N.] [PATCH v4 0/6] batman-adv: Optimizations for setups running dat and bla

This patchset introduces optimizations for batman-adv in setups having several gateways into a common (switched) Ethernet backbone network especially if dat is additionally enabled. Using the current implementation with bla and dat enabled, several problems can be observed in a real setup: 1.