netdev - Re: bridge: HSR support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Dec 2011 19:30:21 +0100
From:	Arvid Brodin <arvid.brodin@...a.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: bridge: HSR support

Stephen Hemminger wrote:
> On Wed, 7 Dec 2011 00:23:21 +0100
> Arvid Brodin <arvid.brodin@...a.com> wrote:
> 
>> Stephen Hemminger wrote:
>>> On Fri, 28 Oct 2011 17:34:18 +0200
>>> Arvid Brodin <arvid.brodin@...a.com> wrote:
>>>
>>>> Ok, so after a lot of reading and looking through code I have this idea of a
>>>> standalone solution:
>>>>
>>>> 1) Add ioctls to create (and remove) "hsr" netdevs which encapsulates two
>>>>    physical Ethernet interfaces each (somewhat like the bridge code does, but
>>>>    with precisely 2 interfaces slaved).
>>> Please use the newer netlink interface and the master attribute for this
>>> rather than inventing yet another ioctl.
>>
>> Is the rtnl interface documented anywhere (the usage of the different IFLA_
>> flags etc.)? Specifically: how do I use the IFLA_MASTER flag (what's the
>> meaning of the 32-bit data it wants, and how is it used by the kernel)? I 
>> haven't been very successful figuring this out by looking at the kernel code.
> 
> 
> Look at bridging or bonding.

Believe me, I have! :) Turns out IFLA_MASTER is actually handled in net/core/rtnetlink.c.
Although the message is sent to the slave device, the functions called are the
master device's ndo_{add,del}_slave(). Looking at the bridging and bonding
implementations br_add_slave() and bond_enslave() and the functions they call,
it all boils down mostly to 

* netdev_set_master() which assigns slave_dev->master = master_dev.
* bonding also set IFF_SLAVE on the slave.
* netdev_rx_handler_register(slave_dev, ). "This handler will then be called
  from __netif_receive_skb."

So far so good, but:

* I don't know the meaning of the IFF_SLAVE flag. It's referenced all over the place
  (core, vlan, bonding, ipv6, eql). Do I need to/want to set this?

* I don't know the effects of setting dev->master. Do I need/want this?

* I don't want to forward all ingress frames on the slave devices to my master
  device; I only want the ones with protocol 0x88FB to be forwarded (other
  frames should be received by the slaves as normal). I think I already have this
  covered by registering a protocol handler (using dev_add_pack(packet_type)).
  So perhaps calling netdev_rx_handler_register() is not necessary in my case?

* As far as I can see, neither bridging nor bonding is handled by the ip program
  (iproute2 suite)? I.e. no examples of binding more than one interface to a
  virtual interface when it comes to which messages to send, etc. VLAN uses
  IFLA_IFNAME (name of the vlan link), IFLA_LINK (physical link behind the vlan
  link), and some IFLA_VLAN-specific messages.

  What I want to do is to atomically (from a user space perspective) create the
  HSR bonding, i.e.:

  	# ip link add name hsr0 type hsr slave1 slave2

  I have written a hsr "plugin" to iproute2 that accepts these parameters, I'm
  just not sure how to tell the kernel about them. Perhaps then I should define
  my own IFLA_HSR_UNSPEC, IFLA_HSR_SLAVE1, IFLA_HSR_SLAVE2 messages?

>> Also, how do I best tell the kernel which my slave devices are when creating
>> the hsr device? Should I create my own IFLA_HSR_UNSPEC, etc, or can I use some
>> of the generic flags?
> 
> Look at macvlan, vlan, or bridging. There this is done by processing a newlink
> message.

macvlan and vlan both use IFLA_LINK to tell the kernel about their single
underlying "real" device. None of these use more than one underlying device.
Bridging does not implement newlink at all (uses ioctls, I think).

>> Oh, and the kernel (struct rtnl_link_ops).newlink method has two (struct
>> nlattr *[]) params: tb and data. What are their roles?
>>

Heh, I just realised that the difference is that "tb" contains generic (IFLA_)
message data and "data" contains specific (e.g. IFLA_VLAN_) message data. 

-- 
Arvid Brodin
Enea Services Stockholm AB
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html