Open-Mesh » batman-adv

For example, I use this line to count neigboring nodes:

batctl o | grep '^[:lower:' | cut -b 37-53 | sort | uniq | wc -l

The output of "batctl o" might be this:

[B.A.T.M.A.N. adv 2012.3.0, MainIF/MAC: dummy_bat/76:ea:3a:fc:8b:ec (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
8e:21:1a:d8:54:a7 24.610s (255) 8e:21:1a:d8:54:a8 [ wlan0-1]: 8e:21:1a:d8:54:a8 (255)
8e:21:1a:d8:54:a8 24.320s (255) 8e:21:1a:d8:54:a8 [ wlan0-1]: 8e:21:1a:d8:54:a8 (255)

The result will be 1 (neighbor) instead of 4.
While the bash command works, it would be nicer if every entry is prefixed by " * " as the output of "batctl tg" is.

You still don't explain why a '*' would help. The '*' has a meaning in tg because it can not only be '*' but also '+' for non-"optimal" gateways to the same client. And I personally would not want to change the output of originators in case anyone parses this file.

If you only want the entries and not the header: Please skip the header. Maybe you saw the -H patches for batctl on the mailinglist

Ok, I thought the '*' at the beginning of the line of the "batctl tg" output was decorative.

I need the output to be more parsing friendly to be able to access different fields.
These are the current issues that make parsing a nightmare:

- the output header, e.g.: "[B.A.T.M.A.N. adv 2012.3.0, Ma[...]"
- the output footer, e.g. "No batman nodes in range ..."
- varying amount of data fields if I use white spaces as field separators, e.g. "(255)" vs. "( 0)"
- different column length; I haven't see that kind of trouble yet, but I will mention it here just in case ;-)

The -H would solve my problem (and this ticket) if it also omits the footer.

The main reason for this ticket is to make parsing of originators table easier.
My specific concern is to make parsing also faster (the dir-300 is slow as hell).
For that purpose it makes sense to patch batman-adv
to expose the required statistics information directly.

Therefore, this ticket may be closed.
Though it would be nice to see the footer
("No batman nodes in range...") removed from the originators table output.

Just because you chose to use a cpu wasting programming language does not make your removal request a convincing argument. It is easy to reverse that: Use something faster and your problem will go away.

However, the better solution is to have an easily parse-able debugfs directory structure like mac80211 already provides.