-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Services not being deleted. Still advertised on the mesh. #29
Comments
Did you try to reboot the neighbor's mesh? |
No.
~ Emery Wooten ~
From: denis133 <notifications@github.com>
Sent: Tuesday, February 26, 2019 3:18 PM
To: aredn/aredn_ar71xx <aredn_ar71xx@noreply.github.com>
Cc: mre33 <mre@mresoftware.com>; Author <author@noreply.github.com>
Subject: Re: [aredn/aredn_ar71xx] Services not being deleted. Still advertised on the mesh. (#373)
Did you try to reboot the neighbor's mesh?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-467617570> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AgPDCXGiXxhCpsEo3KMWymDU7QC8sMKLks5vRaSYgaJpZM4bStGi> . <https://github.com/notifications/beacon/AgPDCVvV_5GQ3uJqUf4cqs5hL6lii67zks5vRaSYgaJpZM4bStGi.gif>
|
What we do to "clear the list" for the entire network (so to speak), is to just shut your node down for about 20-30 min (or temporarily change to a different channel/bandwidth/ssid), after that time it seems that OLSR (and the rest of the network) will "forget" about your node and remove it from the list. Rebooting your immediate network neighbors (if you can), should work too. |
Eric,
I can understand the need for a cache. I am sure it helps when stations are momentarily unreachable. But when a station is being heard, and actively sends updated status information, that should propagate. In the case of what happened to me, even after 24 hours the remote nodes had not removed links to my deleted services. I could add a service and see it appear on remote links immediately but if I deleted it then it never went away. The mesh was propagating the additions but not the deletions. That needs to be fixed.
~ Emery Wooten ~
From: Eric <notifications@github.com>
Sent: Tuesday, February 26, 2019 10:57 PM
To: aredn/aredn_ar71xx <aredn_ar71xx@noreply.github.com>
Cc: mre33 <mre@mresoftware.com>; Author <author@noreply.github.com>
Subject: Re: [aredn/aredn_ar71xx] Services not being deleted. Still advertised on the mesh. (#373)
What we do to "clear the list" for the entire network (so to speak), is to just shut your node down for about 20-30 min (or temporarily change to a different channel/bandwidth/ssid), after that time it seems that OLSR (and the rest of the network) will "forget" about your node and remove it from the list.
Boot your node back up (or change back to the correct settings) and you should see the newer info.
Rebooting your immediate network neighbors (if you can), should work too.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-467724345> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AgPDCc3SXULBgc8-eVBMY_dlOlGyLM16ks5vRhAdgaJpZM4bStGi> .
|
It should clear itself in 24 hours or so if you don't reboot all. |
I know sometimes emails can appear brazen so don’t take this that I am trying to be an Ahole. But to have an “active” status system that requires over 24 hours to reflect a change is somewhat ridiculous. Surely that can be improved! When a node fails to receive an update from another node let it’s data sit in the cache for 10 minutes before removal. When it does receive an update, both additions or removals of a service for example, it should change its own data for that node immediately then propagate the change on the regular interval. A direct neighbor node, such as in my case the tunnel server node I am on, should show the changes on its mesh status page within 10 minutes. If it can show a new service added quickly then it should also be able to show that a service has been removed quickly. It certainly should not require 24 hours.
It appears that data can be added to this “database” then the only way it gets deleted is to wipe the file once a day. That has the potential to leave a heck of a lot of bogus trash in the system for long periods of time. That mechanism needs work!
~ Emery Wooten ~
From: denis133 <notifications@github.com>
Sent: Wednesday, February 27, 2019 4:27 PM
To: aredn/aredn_ar71xx <aredn_ar71xx@noreply.github.com>
Cc: mre33 <mre@mresoftware.com>; Author <author@noreply.github.com>
Subject: Re: [aredn/aredn_ar71xx] Services not being deleted. Still advertised on the mesh. (#373)
It should clear itself in 24 hours or so if you don't reboot all.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-468055965> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AgPDCaBBW-rrYyAuGHZHWcpFxnbUy0wIks5vRwYmgaJpZM4bStGi> .
|
This is a bug, just not recorded here yet. The workarounds exist, and don't diminish this bug. This may already be reported upstream to the OSLR project, if not, we'll need to report it. Also, need to check and possibly bump to a current OLSR version to get fixes into an AREDN release, which means it would be a good idea to review this now. |
Thanks Joe. I look forward to doing more with AREDN and want to see it work as well as possible.
~ Emery Wooten ~
From: Joe AE6XE <notifications@github.com>
Sent: Wednesday, February 27, 2019 7:14 PM
To: aredn/aredn_ar71xx <aredn_ar71xx@noreply.github.com>
Cc: mre33 <mre@mresoftware.com>; Author <author@noreply.github.com>
Subject: Re: [aredn/aredn_ar71xx] Services not being deleted. Still advertised on the mesh. (#373)
This is a bug, just not recorded here yet. The workarounds exist, and don't diminish this bug. This may already be reported upstream to the OSLR project, if not, we'll need to report it. Also, need to check and possibly bump to a current OLSR version to get fixes into an AREDN release, which means it would be a good idea to review this now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-468095995> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AgPDCY3Cz8lCOHevFmxqRjsp0WPQzPseks5vRy0-gaJpZM4bStGi> . <https://github.com/notifications/beacon/AgPDCWdZkSy3PSGDDDaQ7UmF5LVZ5FnWks5vRy0-gaJpZM4bStGi.gif>
|
https://www.arednmesh.org/content/after-editing-nodeservice-name |
Does 7m do the trick? Any testing to know if this is minimally sufficient? |
On 3/5/19 11:29 AM, Joe AE6XE wrote:
Does 7m do the trick? Any testing to know if this is minimally sufficient?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-469746982>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQJ-grKNZZW0GoSChpQuopqHnmZVY4XPks5vTptogaJpZM4bStGi>.
Hi, Joe:
Yes, 7 minutes does the trick. That plus another minute or two due to
the reboot.
I've done it several times on my nodes here at home.
I left the last command a reboot instead of '/etc/init.d/olsrd start' as
a safety feature.
I did not want to leave olsrd stopped and require a physical visit to a
remote site.
:-|
Chuck
|
On 3/5/19 11:29 AM, Joe AE6XE wrote:
Does 7m do the trick? Any testing to know if this is minimally sufficient?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-469746982>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQJ-grKNZZW0GoSChpQuopqHnmZVY4XPks5vTptogaJpZM4bStGi>.
Hi, Joe:
I just tested this by changing the name of a dtd'ed node here at home
while watching the /cgi-bin/mesh results on a node ETX 6.1 away.
I waited for a screen refresh (every 12-13 seconds) then issued the command;
upon the next screen refresh my edited node name disappeared.
At sleep 1m and 2m, my node name eventually reappeared with the double name.
At sleep 3m, my node name appeared singly with the new node name.
So,
/etc/init.d/olsrd stop;sleep 3m;reboot
seems sufficient.
Chuck nc8q
|
On 3/5/19 11:29 AM, Joe AE6XE wrote:
Does 7m do the trick? Any testing to know if this is minimally sufficient?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/aredn/aredn_ar71xx/issues/373#issuecomment-469746982>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQJ-grKNZZW0GoSChpQuopqHnmZVY4XPks5vTptogaJpZM4bStGi>.
Hi, Joe:
Another odd thing I noticed.
Shortening the node name did not seem to affect the neighbor nodes.
The neighbor nodes still displayed the longer name and when I
ssh'ed into the changed node, I had to use the old none name instead
of the new node name. :-|
Anyhow, sleeping 4 minutes was sufficient to correct the node name
will all neighbor nodes.
Chuck
|
This may still be a thing. I was like the services were not propagating or being removed at all... (sorry, I am re-reading a lot of the old issues :) ) |
Killing this one finally - aredn/aredn_packages#11 |
Running 3.18.9.0 on a NSM2 XM
I set up a service and didn't like the name of it so I renamed it and saved the changes a few times. On my local mesh status page everything looked fine and it showed the service with the last name I used. I then went to a neighbor's mesh status page and discovered that every name I used was listed under my advertised services. I then completely deleted all services and saved the changes but when I refreshed and examined the neighbor's (tun) mesh status page they were still displayed. Apparently what was showing up correctly on my local mesh status page was fine but what was being sent out over the mesh was not being deleted internally. After several attempts to reset the services page and clear the internal memory by rebooting the node I finally gave up, pressed and held the reset button to bring the node back to ground zero. I rebuilt it all from the ground up, this time carefully entering my services. Now my local mesh status and my neighbor's mesh status agree and only list my active services.
Now I am new to AREDN so I very well could be overlooking something but this appears to be a bug. It appears that when you delete a service it is not being deleted from the internal memory that is sent out over the mesh. The local node will look fine but remote nodes will still see the deleted services.
I posted this on the arednmesh.org forum and was advised to re-post it here. This bug should be easy to verify with two connected nodes. Rename or delete services from one node and see if they get deleted from the mesh status screen of the neighbor node.
The text was updated successfully, but these errors were encountered: