batman-adv: fix visualization output without neighbors on the primary interface
Commit Message
The primary entry and the corresponding secondary entries are missing when there
are no neighbors on the primary interface. This also causes the TT entries to
miss and makes nodes with multiply secondary interface fall apart since there
is no way to see they are related without a primary entry.
Fix this by always emitting a primary entry.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
vis.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
Comments
WARNING: line over 80 characters
#102: FILE: vis.c:236:
+ if (compare_eth(entries[j].src, packet->vis_orig))
WARNING: line over 80 characters
#123: FILE: vis.c:287:
+ if (compare_eth(entries[j].src, packet->vis_orig))
total: 0 errors, 2 warnings, 0 checks, 47 lines checked
http://www.open-mesh.org/wiki/open-mesh/Contribute#Submitting-patches
Thanks,
Sven
Oops, sorry about that. I'll send a fixed version.
Matthias
On 05/05/2012 05:29 PM, Sven Eckelmann wrote:
> WARNING: line over 80 characters
> #102: FILE: vis.c:236:
> + if (compare_eth(entries[j].src, packet->vis_orig))
>
> WARNING: line over 80 characters
> #123: FILE: vis.c:287:
> + if (compare_eth(entries[j].src, packet->vis_orig))
>
> total: 0 errors, 2 warnings, 0 checks, 47 lines checked
>
> http://www.open-mesh.org/wiki/open-mesh/Contribute#Submitting-patches
>
> Thanks,
> Sven
On Wednesday, May 09, 2012 04:52:18 Guido Iribarren wrote:
> > I see your point, but then one could also ask why the visualization has
> > to be in the kernel at all...
That is a valid question and has been debated several times already. The vis
server is a borderline case - the consensus is/was that it's more convenient
to have it in the kernel together with the routing protocol, so that it could
easily tap into the routing data and make good use of it.
Obviously, that also could be done in user space while all relevant data is be
exported but it also creates enough burden to outweigh the "kernel bloat".
> visualization just means collecting information batman is already handling.
> neighbour information is essential to normal working, and generating a
> "vd dot" just exports that info.
> hostnames, (ip addresses, etc) on the other hand, are not of interest
> to current code
Correct.
> That said, I would also love to find a solution to this, since
> maintaining the /etc/bat-hosts in the nodes simply doesn't escalate in
> my opinion,
> and Marek' suggestion about "several ways to implement this feature in
> user space today" is not entirely clear to me:
> mDNS solutions like avahi translate between hostnames and ips, while
> batman visualization deals with MACs, and those cannot necessarily be
> obtained from IPs (in some cases, ARP will help, but won't work in
> interfaces without IPs)
I don't want to endorse a specific solution. Batman-adv creates a single
ethernet broadcast domain. Every simple broadcasting tool will work across the
entire mesh network. You could even write your own simple script that just
broadcasts the hostname / ip address / $whatever. On the other end you have a
script that listens to the broadcasts to populate your bat-hosts file /
database / etc.
Regards,
Marek
On 05/10/2012 10:19 PM, Marek Lindner wrote:
> On Friday, May 11, 2012 03:47:30 Matthias Schiffer wrote:
>> 2nd, I think without batman-adv specific extensions LLDP isn't very
>> useful, as the LLDP daemon only cares about the bat0/bridge MAC
>> addresses, and not the hardif MAC addresses which are visible in the
>> vis. The softif MAC addresses are shown in the vis as TT records, of
>> course, but as one can't really discern between the adresses of the node
>> itself and those of other clients on the bridge, it's rather useless in
>> my opinion.
>
> I understand all reason except for the last one. What are you trying to
> achieve that you need to auto-discover all batman-adv interfaces ? Are you
> trying to replace vis ?
> As far as I understood Martin was trying to point you to a protocol which
> broadcasts arbitrary data on layer2 (similar to mDNS on layer3).
I'm trying to merge vis data with other data, so I can create a map
which contains node information as well as link qualify information et
cetera. To archive this, I need a reliable way to relate batman-adv vis
nodes with LLDP nodes.
Matthias
@@ -207,7 +207,6 @@ int vis_seq_print_text(struct seq_file *seq, void *offset)
int vis_server = atomic_read(&bat_priv->vis_mode);
size_t buff_pos, buf_size;
char *buff;
- int compare;
primary_if = primary_if_get_selected(bat_priv);
if (!primary_if)
@@ -228,14 +227,17 @@ int vis_seq_print_text(struct seq_file *seq, void *offset)
entries = (struct vis_info_entry *)
((char *)packet + sizeof(*packet));
+ vis_data_insert_interface(packet->vis_orig,
+ &vis_if_list, true);
+
for (j = 0; j < packet->entries; j++) {
if (entries[j].quality == 0)
continue;
- compare =
- compare_eth(entries[j].src, packet->vis_orig);
+ if (compare_eth(entries[j].src, packet->vis_orig))
+ continue;
vis_data_insert_interface(entries[j].src,
&vis_if_list,
- compare);
+ false);
}
hlist_for_each_entry(entry, pos, &vis_if_list, list) {
@@ -276,14 +278,17 @@ int vis_seq_print_text(struct seq_file *seq, void *offset)
entries = (struct vis_info_entry *)
((char *)packet + sizeof(*packet));
+ vis_data_insert_interface(packet->vis_orig,
+ &vis_if_list, true);
+
for (j = 0; j < packet->entries; j++) {
if (entries[j].quality == 0)
continue;
- compare =
- compare_eth(entries[j].src, packet->vis_orig);
+ if (compare_eth(entries[j].src, packet->vis_orig))
+ continue;
vis_data_insert_interface(entries[j].src,
&vis_if_list,
- compare);
+ false);
}
hlist_for_each_entry(entry, pos, &vis_if_list, list) {