ROBIN -  Open Source Mesh Network Forum Index ROBIN - Open Source Mesh Network
users community forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

(ignore)2690

 
Post new topic   Reply to topic    ROBIN - Open Source Mesh Network Forum Index -> beta-1.5 Release Candidates
View previous topic :: View next topic  
Author Message
Ads






Posted: Sat Sep 23, 2017 11:40 am    Post subject: Ads

Back to top
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 2:02 pm    Post subject: (ignore)2690 Reply with quote

I could be wrong, but some patches that appear on dev.open-mesh.com for olsr in trunk do not appear to actually be applied. Looking quickly at the makefile shows no mention of the patches, could be something i've missed. I found this while recently looking at /etc/olsrd.conf.robin. Should the changes not be reflected in that file?

Could be something i'm overlooking. Would be nice to confirm that people are actually running test firmware with these changes in OLSR, otherwise the only thing that's changed is the olsr version correct?

Only registered users can see links on this forum!
Register or Login on forum!



Last edited by foxtroop11 on Thu Feb 25, 2010 7:37 pm; edited 3 times in total
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Tue Feb 23, 2010 4:05 pm    Post subject: Reply with quote

correct!
you may change olsrd.conf buildin images with new Robin Mesh SVN.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 4:15 pm    Post subject: Reply with quote

Ok, i thought it was the default nature to adapt the new settings across the board.

Just noticed something else that might need to be fixed. Trying out 2690 and having it to where it can check for upgrades seems to continue filling up the /tmp direcory with random numbered files that contain the online version number.

version.19096
version.19730
version.20349
version.20987

etc, etc.

Is this normal behavior? Could it overtime lead to an out of memory reboot, probably would take awhile?
Back to top
View user's profile Send private message
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 4:29 pm    Post subject: Reply with quote

I think the upgrade file might need to be tweaked alittle. Looking at it seems to show that each time upgrade is ran it goes out and grabs the current_version file and then saves it local in the /tmp folder as a random number file. It doesn't seem it's designed to get rid of the old file before the next run so it just continues to build in the /tmp folder. I figure if this went on for days/weeks that the /tmp folder would just be full of random number files.
Back to top
View user's profile Send private message
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 5:35 pm    Post subject: Reply with quote

A simple little line appears to do the trick. This way the most that will be in the /tmp section is one file at a time. Not the most elegant fix, but appears to work just fine.

[ -e /tmp/current_version ] && rm -f /tmp/current_version
[ -e /tmp/upgrade.sh ] && rm -f /tmp/upgrade.sh
[ -e /tmp/version.* ] && rm -f /tmp/version.*
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Tue Feb 23, 2010 6:07 pm    Post subject: Reply with quote

the files that you see are generated by sysupdate.sh and sysupdate.sh is called only once that the firmware have to be updated. Then, the file version.$$ resides in /tmp so will be auto-removed at first boot after the upgrade.

In normal operations you wont see those files in /tmp but if you play with the upgrade process you might force unwanted and un-needed runs of sysupdate.sh
Back to top
View user's profile Send private message Send e-mail Visit poster's website
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 7:38 pm    Post subject: Reply with quote

Thanks for the clarifiication, more then likely something I've messed with then.
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Tue Feb 23, 2010 7:55 pm    Post subject: Reply with quote

...it happens Smile
Back to top
View user's profile Send private message Send e-mail Visit poster's website
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 10:23 pm    Post subject: Reply with quote

Ok, i'm bound and determined to find something wrong, j/k, but seriously i may have found something.

I thought something was wrong with block alien nodes for some time and I think i finally figured it out. Say for example you have two nodes that check into the dash as gateway's. You then unplug one and prior to it checking in your turn on block alien nodes. I've been sitting looking at /usr/sbin/update-node(s) can't remember which one, along with /lib/robin/strict-mesh.sh.

Looking at those files seems to indicate it pulls down files from the dash and creates either a allowed.gateway or allowed.repeater file, maybe both. Well in my testing so far doing the above combo leads to only an allowed.gateway file being made and not an allowed repeater. I had to delete the node from the dash and readd it before it created an allowed.repeater file on the gateway.

Now I'm not sure if that would block a node that was in the allowed.gateway list but is now actually a repeater, but that seems to be the case. I will find out shortly now that there is an allowed.repeater file on the gateway if the repeater will actually mesh in.

I've probably not only confused myself, but surely others. I'll continue to monitor and see what happens.
Back to top
View user's profile Send private message
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 10:36 pm    Post subject: Reply with quote

Adding further to the confusion is the fact that the /etc/config/allowed.repeater file located on the gateway has a mac address that ends in "6a" when on my dash the mac actually ends in "69".

I suspect it will never be allowed to mesh in and I cannot figure out why the contents of the file is incorrect.
Back to top
View user's profile Send private message
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 10:39 pm    Post subject: Reply with quote

Bingo!!! The old Open-Mesh dash swap around on the engenious mac is coming into play. So I reenter my mac on the dash with "68" and then update the gateway which results in "69" on the allowed.repeater list!

The last part of this problem is probably specific only what i'm working with and should be fixed soon, but the first part of how the firmware processed what's on the dash might need to be tweaked.
Back to top
View user's profile Send private message
mtlowes
Moderator
Moderator


Joined: 28 Oct 2009
Posts: 577
Location: Lakeshore Ontario Canada

PostPosted: Tue Feb 23, 2010 11:20 pm    Post subject: Reply with quote

foxtroop11 wrote:
Bingo!!! The old Open-Mesh dash swap around on the engenious mac is coming into play. So I reenter my mac on the dash with "68" and then update the gateway which results in "69" on the allowed.repeater list!

The last part of this problem is probably specific only what i'm working with and should be fixed soon, but the first part of how the firmware processed what's on the dash might need to be tweaked.

Certainly clarifies why one of my repeaters doesn't like 2690 at all.. had to kick it back a couple revs just to get it to work...
Back to top
View user's profile Send private message
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Tue Feb 23, 2010 11:53 pm    Post subject: Reply with quote

Do you have block alien nodes turned on? It's very strange what I'm having to do, but then again I'm not using standard equipment. On the repeater I had only a /etc/config/allowed.gateways file, yet my repeater wouldn't connect still. I had already corrected things on the gateway, so on the repeater i did "cp allowed.gateways allowed.repeaters" and then manaully ran ./strict-mesh.sh. This then generated a file in /tmp called allowed, which didn't exist at all. This file had duplicate ip's/mac's since it just combined everything. After doing all this the repeater meshed back up. However, before i continue do go on and on I need to test all this on some OM1P's. It very well this could be specific to the Anaptyx gear and might need some alteration on the dash for proper output to the nodes.

I've seen this problem for a long time, just thought it was something specific to the dual radio equipment I was using, which the mac address thing is, but digging further seems to indicate a potential problem for all equipment. Turning off block alien nodes clears everything up for the time being.
Back to top
View user's profile Send private message
Antonio (isleman)
Site Admin
Site Admin


Joined: 10 Feb 2008
Posts: 2323
Location: Toscana, Italy

PostPosted: Wed Feb 24, 2010 2:01 pm    Post subject: Reply with quote

Quote:
It very well this could be specific to the Anaptyx gear and might need some alteration on the dash for proper output to the nodes.

I do not know what Anaptyx software expects or sends.

FYI, the basic and shared concept of strict-mesh in Robin is that the trusted nodes are the ones which belong (as "registered") to a same network, it doesn't matter if they checkin or not, it doesn't matter their role (gateway or repeater).
In other words; a node is treated as reliable as long as it is in the list sent by the dashboard, regardless its current status (the list is available as /etc/update/nodes).

Quote:
Well in my testing so far doing the above combo leads to only an allowed.gateway file being made and not an allowed repeat. I had to delete the node from the dash and readd it before it created an allowed.repeater file on the gateway.

May be that not-cheking nodes are removed from the list?
Since the expected format, the removal of not-cheking nodes from the list of the nodes should be a wrong behavior of the dashboard.

Or it may be that a "malformed" row in the reply (section: #@#config nodes) causes a node to be not added to one of "/etc/config/allowed.<role>" files.

As well as I can't definitely exclude the possibility that there are bugs in my code!

For the above reasons, the ability to look at the list of the nodes sent in that scenario could be very interesting.

Quote:

Adding further to the confusion is the fact that the /etc/config/allowed.repeater file located on the gateway has a mac address that ends in "6a" when on my dash the mac actually ends in "69". I suspect it will never be allowed to mesh in

About MAC addresses... well, they do not play roles in "strict-mesh" because nodes are allowed on the IP address basis (have a look at the code).

Quote:
...and I cannot figure out why the contents of the file is incorrect.

Those files have the right contents:
- usually the dashboard screen reports the MAC address of the physical WAN port (used when registering the node)
- the lists of the nodes report the MAC address of their wifi0 device (they can see each other via this address)

FYI, in a single-radio device Robin creates its VAPs using a different MAC address from the phisical underlying device.
Please, run ifconfig |grep HW or wlanconfig ath0 list for confirmation.

Quote:
Adding further to the confusion...

...yes, just confused
Back to top
View user's profile Send private message Send e-mail Visit poster's website
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Wed Feb 24, 2010 4:37 pm    Post subject: Reply with quote

I want to sit down and do testing with the OM1P and see if I can duplicate some of this. The problem is I can't seem to get my serial cable working on them. I want to see everything happening real time regardless if I can get ssh to it or not.
Back to top
View user's profile Send private message
ispyisail
Site Admin
Site Admin


Joined: 12 Sep 2008
Posts: 4604
Location: New Zealand

PostPosted: Wed Feb 24, 2010 7:15 pm    Post subject: Reply with quote

Quote:
The problem is I can't seem to get my serial cable working on them


Based on the MR3201a with a 3 wire serial cable (GND, Tx Rx e.g. USB and others) you need to plug the serial cable in 1 or 2 seconds after boot or the router will not boot.

This is not the case with a 4 wire serial cable (3.3v, GND, Rx, Tx).

_________________
ROBIN-Mesh Wiki:

Only registered users can see links on this forum!
Register or Login on forum!

Test Network:
Only registered users can see links on this forum!
Register or Login on forum!



Please donate to ROBIN by paypal:

Only registered users can see links on this forum!
Register or Login on forum!

!
Back to top
View user's profile Send private message
foxtroop11
Service Provider
Service Provider


Joined: 22 Mar 2009
Posts: 1168
Location: Ansbach, Germany and sometimes the States

PostPosted: Thu Feb 25, 2010 6:41 pm    Post subject: Reply with quote

If it's ok would probably be best to delete this thread. After testing OM1P's it looks like block alien node's functions correct.
Back to top
View user's profile Send private message
ispyisail
Site Admin
Site Admin


Joined: 12 Sep 2008
Posts: 4604
Location: New Zealand

PostPosted: Thu Feb 25, 2010 7:01 pm    Post subject: Reply with quote

Its best to leave it

Just edit your first post in capital letters

FIXED - IGNORE THIS POST or something

_________________
ROBIN-Mesh Wiki:

Only registered users can see links on this forum!
Register or Login on forum!

Test Network:
Only registered users can see links on this forum!
Register or Login on forum!



Please donate to ROBIN by paypal:

Only registered users can see links on this forum!
Register or Login on forum!

!
Back to top
View user's profile Send private message
bmoffitt
Intermediate User
Intermediate User


Joined: 22 Aug 2008
Posts: 108

PostPosted: Sat Mar 06, 2010 3:14 am    Post subject: Agreed! Reply with quote

It's useful to be able to see these discussions even if they are resolved with no change to the code. We learn from each others' mistakes... Very Happy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ROBIN - Open Source Mesh Network Forum Index -> beta-1.5 Release Candidates All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
c d
e



Powered by phpBB © 2001, 2005 phpBB Group

Abuse - Report Abuse - TOS & Privacy.
Powered by forumup.it free forum, create your free forum! Created by Hyarbor & Qooqoa
Confirmed

Page generation time: 1.266