ifplugd

[Denys Vlasenko]

On Thursday 23 April 2009 07:43, Vladimir Dronnikov wrote:
> >
> > I propose to do it differently. Let all network applets
> > be able to use address of the format "netlink:XXXX".
> > That way, you can simply use nc to dump netlink data.
> >
> 
> Good idea.
> 
> However, netlink messages require slightly different approach to be
> dumped, not just n=read(buffer) + full_write(buffer, n).
> The data recv'ed from netlink socket is considered a set of packed strings:
> str1\0str2\0...strN\0\0
> This fact will break netcat read-write cycle consistency IMHO.

But it still is retrieved by read syscall, right?
I'd be much surprised if it does not.

> Moreover, netlink socket connection depends on the type of messages
> "protocol" and is bound to a "group", or "channel". E.g. to listen to
> netlink messages that the kernel sends to userspace upon hotplug
> events we have to set protocol to 15 and bind to the group 1
> (milticast messages).

Strings are quite flexible. Invent whatever "netlink:XXXX:YYY:ZZZ"
format you need to specify all these parameters.

> How do we map the two parameters to existing 
> netcat options? This would require either additional options to
> specify that parameters or option overloading (which is bad IMHO).

Absolutely the same as it is done now:

nc -l -s <hostname>

Examples:

nc -l -s 0.0.0.0:80 - listen on IPv4

nc -l -s [::]:80 - listen on IPv6

Sure, usually people do this with "nc -l -p 80", but this is stupid:
who said that all types of socket addresses have concept of "port"
AT ALL? "port" concept is just an artifact of IP[v6] sockaddrs!

Example:

nc -l -s 1.2.3.4 -p 80  -- why poor sockaddr got split like this?
nc -l -s 1.2.3.4:80     -- this makes much more sense

String representation can be made (and must be made) to work
for any sockaddr type - this is a must for embedding addresses in URLs -
wget, browsers need that.
--
vda