[PATCH alternative] ifplugd: fix netlink recv
wharms at bfs.de
Tue Jul 9 13:53:59 UTC 2013
Am 09.07.2013 15:08, schrieb Johannes Stezenbach:
> On Tue, Jul 09, 2013 at 01:47:30PM +0200, Tito wrote:
>> On Tuesday 09 July 2013 10:18:31 Harald Becker wrote:
>>> On 09-07-2013 09:15 walter harms <wharms at bfs.de> wrote:
>>>> just for my curiosity could you please explain why this works ?
>>> NLMSG_SPACE(len) is a Macro to return the required buffer space
>>> to carry a netlink message payload of given length. With the
>>> maximum payload length you get the maximum required buffer space.
>>> This is 1024 byte (as before) plus netlink message header size
>>> plus header padding space ... usually less than 4096 byte ...
>>> that is you do not waste unnecessary buffer space.
>> yes this is the theory I came up with after digging through
>> the linux/netlin.h header and looking at a few random examples of netlink
>> code on the net.
> It does not really work. The buffer size is then 1040 and the
> actual message received is 1036 bytes (from strace) for
> a normal eth0 interface. But running "ifplugd -nsfFaMIpq -i br0"
> and then "brctl addbr br0" breaks it, the netlink message
> becomes larger.
> So, where does the MAX_PAYLOAD == 1024 come from?
> Without doing research on it, my assumption is that
> in older kernels the message was smaller, and now it is
> larger, and in future kernels the size might increase even more.
> and it varies with the type of the interface.
> And the point of using the netlink protocol is that messages
> can be extended with additional attributes without breaking
> backwards compatibility.
> Or is there some max size guaranteed for NETLINK_ROUTE messages
> in group RTMGRP_LINK? If not, then the code needs to
> be able to handle the max size of a netlink message.
according to RFC the buffer size is 1024 bytes.
> busybox mailing list
> busybox at busybox.net
More information about the busybox