with low memory conditions, typically on 32Mb RAM, the
device would become unresponsive in hours to days. The
symptoms only occured when no RF links. iw processes
would hang in Zombie state. Updates to use iwinfo where
possible and avoid using both iw and iwinfo. crontab
script is implemented to detect Zombie processes and free
up resources in the reduced chance the symptoms are still
occuring.
* config change to make uhttpd listen on port 80 and 8080
* add port 80 to tunnel firewall rules
* add port 80 to tunnel firewall rules in config, update help
* firewall rules for wan + dtdlink
Once the PR for this is accepted by Openwrt we will need to remove the file
001-add_support_for_TP-Link_CPE510_v2.patch
Removed 001-add_support_for_TP-Link_CPE210_v2.patch as PR #937 has been committed
Updated 99_setup_aredn_include to remove unused Rssi Led configuration
olsrd-watchdog can trigger when the olsrd service is restarted
Such as when a tunnel comes up, or when a config change is
made to olsrd.
procd already monitors olsrd and makes sure it remains running.
With procd we no longer need olsrd-watchdog and can remove it.
fixes AREDN->ticket:215
Change-Id: I5067d380a22bd0ab5e597746478ef3e1ba05d72d
It is possible for the system to run out of memory when dealing
with large file uploads and installs.
As part of the upgrade procedure shutdown services that are not
essential for node operations to allow more memory for install
to take place.
Includes changes to linkled to indicate this new state as it will
be shutdown as part of the cleanup process.
Memory gain (approximate)
dropbear 100kb
linkled 200kb
logd 200kb
odhcp 100kb
snmpd 500kb
xinetd 100kb
Total(approximate): 1200kb (around %4 on 32mb devices)
This is somewhat similar to files/usr/local/bin/upgrade_kill_prep
except that it kills only a select group of services
so that the system can handle the file upload while
upgrade_kill_prep does the final system cleanup to run the full
upgrade.
ref AREDN->ticket:204
Change-Id: Ic6d3aa028725064a97c4723f6d9b36e1e51d87a7
Inside the source files the word "contained" was mispelled
as "conained"
The website currently lists this correctly as "contained"
This was an error in the intial stamping of the source files in
changeset:5c3ee1d0686c6e6f2907fe4fc393d86d6c5a69b5/aredn_ar71xx
Line is part of "Additional Conditions" permitted by GPLv3.
Line does not impact coders prior to the AREDN setup date
as it was added by the AREDN team.
Change-Id: I3bc09aea548100f35c08aebe8686b8d4808d56d8
Signed-off-by: Conrad Lara - KG6JEI <KG6JEI@amsat.org>
Signed-off-by: Joe Ayers <ae6xe@arrl.net>
Signed-off-by: Darryl Quinn <k5dlq@arrl.net>
Signed-off-by: Trevor Paskett - K7FPV <snoopytjp@gmail.com>
Remove banner from the files set as it will override the build
version of the banner.
Patch 2 will be in arednbase repo.
Change-Id: Iefb8288985b39b8942419f43925d00aaab53d610
After OTA upgrade the timezone was kept in the system file
but not in the UI so when a user would save the timezone
would be overwritten.
fixes AREDN->ticket:186
Change-Id: I593afab0c3f67ba9d300228e9cbb47d7e3d894d1
Move httpd.conf to not store password and instead depend on the shadow password file.
Also tag the 40_aredn_migrate-httpdconf script to be +x. Not strictly necessary but wish to have this standard
Change-Id: I018d9a3294e45af2316b3c3947ef2a7d8081268b
RFC requires that the DHCP server include the default gateway (0.0.0.0/0) route as part the Classless network list.
Moved to node-setup so it can be set dynamically at setup run time.
fixes AREDN->ticket:155
Due to a firewall chain name changes in BB when a node was in NAT mode (instead of recommended direct mode) connections that went out over DTDLink as the first hop would not be masqed and as such would not work.
This changes the beacon rate from once every 100tu's to once every 500tu's
1tu=1024 microseconds
This will decrease the amount of RF time being used by beacon packets.
This is especially important on 900MHz and 2.4GHz using 5MHz wide channels where 10 nodes beaconing 10x a second at ~256kbit/s can use up around 45% of the RF channel in beacons alone.
Other bands and channels and widths are not expected to see as significant an advantage due to the faster data rates.
Joe AE6XE