alternatives to screenscraping iw?

alternatives to screenscraping iw?

[Paul Cercueil]

Hi Johannes,

We're trying to move away from ifconfig/iwconfig and switch to use 
ip/iw on our embedded systems. It works good, but we can't really adapt 
our current tools (mostly Python wrappers). iw -h specially says not to 
screenscrape, but we don't really have an alternative, do we?

Would it be possible to split iw into a shared library + binary? Then 
it'd be at least possible to create wrappers. Another idea would be to 
have a mode for iw to output json, like 'ip' does.

Cheers,
-Paul

Re: alternatives to screenscraping iw?

[Johannes Berg]

Hi,

> We're trying to move away from ifconfig/iwconfig and switch to use 
> ip/iw on our embedded systems. It works good, but we can't really adapt 
> our current tools (mostly Python wrappers). iw -h specially says not to 
> screenscrape, but we don't really have an alternative, do we?

Yeah, we _have_ changed the output format sometimes ... I suppose the
only reason iwconfig hasn't is that it's not been changed in 15 years or
so ;-)

There is a pynl80211 library, but it's not complete and maintained. If
you only need some bits though it might be worthwhile to just do that
internally. Python has supported netlink sockets for some time, IIRC.

> Would it be possible to split iw into a shared library + binary? Then 
> it'd be at least possible to create wrappers. Another idea would be to 
> have a mode for iw to output json, like 'ip' does.

I actually played with this at some point, but then wanted to sort of
use json internally so it's not maintained separately and we go through
that ... but the message structure and our intermediate printing makes
that actually quite difficult.

johannes

Re: alternatives to screenscraping iw?

[Krishna Chaitanya]

On Mon, Sep 7, 2020 at 6:29 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi,
>
> > We're trying to move away from ifconfig/iwconfig and switch to use
> > ip/iw on our embedded systems. It works good, but we can't really adapt
> > our current tools (mostly Python wrappers). iw -h specially says not to
> > screenscrape, but we don't really have an alternative, do we?
>
> Yeah, we _have_ changed the output format sometimes ... I suppose the
> only reason iwconfig hasn't is that it's not been changed in 15 years or
> so ;-)
>
> There is a pynl80211 library, but it's not complete and maintained. If
> you only need some bits though it might be worthwhile to just do that
> internally. Python has supported netlink sockets for some time, IIRC.

FYI, We have open-sourced our internal library which takes care of abstracting
Netlink attributes, just need to define commands and event messages in JSON,
https://github.com/bluwireless/py-genl. The initial port of all
messages might be an
effort but extending it would be easy.
>
> > Would it be possible to split iw into a shared library + binary? Then
> > it'd be at least possible to create wrappers. Another idea would be to
> > have a mode for iw to output json, like 'ip' does.
>
> I actually played with this at some point, but then wanted to sort of
> use json internally so it's not maintained separately and we go through
> that ... but the message structure and our intermediate printing makes
> that actually quite difficult.
>
> johannes

Re: alternatives to screenscraping iw?

[Johannes Berg]

On Mon, 2020-09-07 at 21:52 +0530, Krishna Chaitanya wrote:
> 
> FYI, We have open-sourced our internal library which takes care of abstracting
> Netlink attributes, just need to define commands and event messages in JSON,
> https://github.com/bluwireless/py-genl. The initial port of all
> messages might be an effort but extending it would be easy.

Nice.

I wonder if the netlink policy export I wrote for the kernel could be
used to generate attribute descriptions? Even if it means just running a
tool in a latest kernel VM to do it.

johannes

Re: alternatives to screenscraping iw?

[Krishna Chaitanya]

On Mon, Sep 7, 2020 at 10:22 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Mon, 2020-09-07 at 21:52 +0530, Krishna Chaitanya wrote:
> >
> > FYI, We have open-sourced our internal library which takes care of abstracting
> > Netlink attributes, just need to define commands and event messages in JSON,
> > https://github.com/bluwireless/py-genl. The initial port of all
> > messages might be an effort but extending it would be easy.
>
> Nice.
>
> I wonder if the netlink policy export I wrote for the kernel could be
> used to generate attribute descriptions? Even if it means just running a
> tool in a latest kernel VM to do it.
Can you please point me to it? But yes, auto-generating those should be handy.
Probably can pick up the header file from sources in kernel.org
instead of booting
into a VM (depending on how your tools work)?

Re: alternatives to screenscraping iw?

[Johannes Berg]

On Mon, 2020-09-07 at 22:55 +0530, Krishna Chaitanya wrote:
> 
> > I wonder if the netlink policy export I wrote for the kernel could be
> > used to generate attribute descriptions? Even if it means just running a
> > tool in a latest kernel VM to do it.
> Can you please point me to it? But yes, auto-generating those should be handy.
> Probably can pick up the header file from sources in kernel.org
> instead of booting
> into a VM (depending on how your tools work)?

No no, I meant at runtime from the *policy* export, not the header file.

See net/netlink/policy.c and this patch in the userland code:

https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=cc889b82412450dec762551ac867bd2896656ddc

johannes

Re: alternatives to screenscraping iw?

[Krishna Chaitanya]

On Tue, Sep 8, 2020 at 2:58 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Mon, 2020-09-07 at 22:55 +0530, Krishna Chaitanya wrote:
> >
> > > I wonder if the netlink policy export I wrote for the kernel could be
> > > used to generate attribute descriptions? Even if it means just running a
> > > tool in a latest kernel VM to do it.
> > Can you please point me to it? But yes, auto-generating those should be handy.
> > Probably can pick up the header file from sources in kernel.org
> > instead of booting
> > into a VM (depending on how your tools work)?
>
> No no, I meant at runtime from the *policy* export, not the header file.
>
> See net/netlink/policy.c and this patch in the userland code:
>
> https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=cc889b82412450dec762551ac867bd2896656ddc
Ah okay, got it, thanks.