[PATCH alternative] ifplugd: fix netlink recv

Tito farmatito at tiscali.it
Tue Jul 9 14:30:40 UTC 2013

On Tuesday 09 July 2013 15:08:50 Johannes Stezenbach wrote:
> Hi,
> 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?

I just thought that the original developers were right 
in their assumption of 1024 payload size and that the
problem was the missing space for padding and headers.

> 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.

Looking at the __kernel__  of part netlink.h it seems to me
that the max size for a netlink message is 8k

  *      skb should fit one page. This choice is good for headerless malloc.
  *      But we should limit to 8K so that userspace does not have to
  *      use enormous buffer sizes on recvmsg() calls just to avoid
  *      MSG_TRUNC when PAGE_SIZE is very large.
  #if PAGE_SIZE < 8192UL

also looking at the ifplugd man page

"ifplugd [options]
ifplugd is a daemon which will automatically configure your ethernet device when
a cable is plugged in and automatically unconfigure it if the cable is pulled.
This is useful on laptops with on-board network adapters, since it will only
configure the interface when a cable is really connected.  "

it seems to me that ifplugd is to be used only with ethernet devices
so maybe a 1024 buffer is enough for them but not for br* devices?

Also while reading about this netlink stuff I noticed the existence of
multipart messages, is this our case?

Did you check the size of the offending netlink message just for reference?

Also checking the kernel source for the module of br devices could be an option.

I'm wondering If it would be possible to malloc the buffer on demand like:

while (1) {
	s = nlmsg_len - size_of_header
	buf = malloc(s)
	(concatenate messges if needed?)
	do something 
	free it

> Thanks,
> Johannes


More information about the busybox mailing list