AVM's DHCP-server gibt alte WiFi-clients nicht frei

[frater]

I'm writing in English because it's too hard for me to describe my problem in German.
I have no problem reading it, so it's possible to reply in German.

I have a lot of AVM devices (>80) in the field and some of them (>6) are used to give free WiFi-access.
After a few months the list of clients that have been connected becomes quite large.
The Fritzbox also becomes slow in response. I think it is related.
I'm having this problem with all devices that have this large list.

What IS related for sure that at a certain stage no new devices are able to connect.
Deleting some of these clients in that list will give immediate access to these new devices.
Merely restarting the router doesn't solve that problem.

I'm now looking for a way to empty that list each week or month.
For this I need to know where that list is kept and by which program so I can remove these entries and restart that daemon.

Anyone examined this phenomena before and maybe has a cure?
I couldn't find anything when searching for it.

 

[informerex]

Change IP http://en.avm.de/nc/service/fritzbo.../show/19_Changing-the-FRITZ-Box-s-IP-address/

 

[frater]

Did you misinterpret my question or do you mean I should change the IP of the box and then change it back?

I am not interested in changing the IP.
I want to get rid of all the clients that once connected to the box.

 

[sf3978]

For this I need to know where that list is kept and by which program so I can remove these entries ...

Schau mal nach der Datei "multid.leases". Evtl. kannst Du diese Datei, mit dem gleichen Editor, wie er für die "ar7.cfg" benutzt wird, ändern/bearbeiten.

 

[frater]

No, informerex didn't misinterpret your question. His advice is exactly meant as you understood it.

OK...

@sf3978
Yes I can edit the file with "nvi /var/flash/multid.leases"
I believe vi is a programmable editor. I've never used it.

I will see what I can do...
Having to use nvi will make it more difficult.

I was planning to output all the MAC-address of 'arp' and then deleting all the lines that don't exist in that file and restart the multidaemon.
Having to use nvi means I have to do a bit of homework first.

I can probably create the file I want then let nvi delete all the lines and import the file I made....

Maybe just emptying is enough.
I guess it will be rebuilt automatically....

 

[sf3978]

Having to use nvi means I have to do a bit of homework first.

I can probably create the file I want then let nvi delete all the lines and import the file I made....

Im Freetz-Wiki gibt es ein Beispiel (... ich glaube bei OpenVPN), wie man z. B. die ar7.cfg-Datei mit dem nvi ändert.

 

[frater]

I need to stop it, edit it and then start it....

This will give me an empty multid.leases, but all the clients are still listed in "home network" and in WLAN

I do know how to work with vi (use it daily) but I never used it from a script.
nvi is merely a bash-wrapper....
but this is of later concern. I still need to find out which records to remove from which file...
I will check that folder...


mmmm
It's ar7.cfg

Just edited that file and restarted the router...
Hope it comes back or I'll have to go there tomorrow.

 

[PeterPawn]

You can even use 'sed' to modify the /var/flash/multid.leases file ... there's no need to use nvi from a script.

But you have to copy the file first ... do not try to use the inline option (-i); copying TFFS "files" (this are character devices in reality) has to be done with 'cat' and redirection.

 

[frater]

I think I can safely empty multid.leases, but I also need to manipulate ar7.cfg (from a script)
That one is quite hard I think...
I need to only remove the sections that are not in the arplist or has no forwarding nor reserved IP's

Tomorrow or next week...
Thanks for thinking with me


reminder for myself:

# cat /tmp/new_ar7

#!/bin/sh

# A script to get rid of unused leases that clog your AVM Fritzbox when used as a semi-public WiFi
# It is intended to run as a weekly cronjob.
# Something like this
#
# 47 4    * * 7   root    /sbin/tidy_ar7 && reboot
#

[ -e /var/flash/ar7.cfg ] || exit 1

# Use the arp table to get the currently connected clients
arp | egrep -o '([[:xdigit:]]{2}[:-]){5}[[:xdigit:]]{2}' >/tmp/arplist

LEASES=`grep -c ':' /var/flash/multid.leases`
LAME_LEASES=$(( ${LEASES} - `grep -c ':' /tmp/arplist` ))

if ! egrep -q '^ +landevices \{' /var/flash/ar7.cfg ; then
  echo "/var/flash/ar7.cfg has been changed by AVM and this script is now unable to work properly" >&2
  exit 1
fi

if [ ${LAME_LEASES} -lt 10 ] ; then
  echo "There are only ${LAME_LEASES} lame leases, I will make no change" >&2
  exit 1
fi

# use /var/flash/ar7.cfg to create 3 pieces
egrep -B9999 '^ +landevices \{' /var/flash/ar7.cfg                          >/tmp/ar7.first
egrep -A9999 '^ +landevices \{' /var/flash/ar7.cfg | egrep -B9999 -m1 '^}'  >/tmp/ar7.cfg.leases
egrep -A9999 '^ +landevices \{' /var/flash/ar7.cfg | egrep -A9999     '^}'  >/tmp/ar7.last

# Initialize
echo -n '' >/tmp/ar7.middle1
echo -n '' >/tmp/lease
KEEP=
IFS=''

# Parse the leases
while read line ; do
  # We reached the end... exit the loop
  echo "${line}" | egrep -q '^}$' && break

  # Determine if we keep the entry
  echo "${line}" | grep -qif /tmp/arplist  && KEEP=1
  echo "${line}" | grep -qi 'yes'          && KEEP=1
  echo "${line}" | grep -qi 'forwardrules' && KEEP=1
  echo "${line}" | grep -qi ' name ='      && KEEP=1

  # write one line of that section
  echo "${line}" >>/tmp/lease

  if echo "${line}" | egrep -q '}' ; then
    [ ${KEEP} ] && cat /tmp/lease >>/tmp/ar7.middle1
    KEEP=
    echo -n '' >/tmp/lease
  fi

done </tmp/ar7.cfg.leases

# sanity check: last line needs to contain a closing bracket....  otherwise abort
tail -n1 /tmp/ar7.middle1 | egrep -q '^ +}' || exit 1

# last line has either a closing and opening bracket or only a closing bracket
# replace last line with a line with only a closing bracket
head -n-2 /tmp/ar7.middle1  >/tmp/ar7.middle2
echo -e '        }'        >>/tmp/ar7.middle2

# create the new ar7.cfg by sticking the 2 ends to it
cat /tmp/ar7.first    >/tmp/ar7.cfg.new
cat /tmp/ar7.middle2 >>/tmp/ar7.cfg.new
cat /tmp/ar7.last    >>/tmp/ar7.cfg.new

# reminder we really eeed some more sanity checks here....
#
#

# let's do it
# stop the multi-daemon, empty its list and overwrite /var/flash/ar7.cfg
# Then exit with errorlevel 0

# Stop the 2 services involved
# /usr/bin/ctlmgr -s
/etc/init.d/rc.multid stop

# replace ar7.cfg with the modified one
cat /tmp/ar7.cfg.new >/var/flash/ar7.cfg
# replace multid.leases
grep  -if /tmp/arplist /var/flash/multid.leases >/tmp/multid.leases
cat /tmp/multid.leases >/var/flash/multid.leases

# Start the 2 services involved
# /usr/bin/ctlmgr
# /etc/init.d/rc.multid start

# clean the room after playing
rm /tmp/multid.leases
rm /tmp/ar7.first
rm /tmp/ar7.middle1
rm /tmp/ar7.middle2
rm /tmp/ar7.last
rm /tmp/lease
rm /tmp/arplist

exit 0

 

[frater]

I just now finished my script and it is working.
I wonder why no-one else has run into this problem.
Maybe because most of you are using a Fritzbox for themselves and don't even want a public WiFi..

I would really appreciate some feedback or comments.

 

[PeterPawn]

1. What's your reason to reboot the box afterwards ?

It should be sufficient to stop multid and ctlmgr (issue the command: ctlmgr -s), store/modify the files and restart the services. To start ctlmgr first, simply call 'ctlmgr' or even better '/usr/bin/ctlmgr' (it's a wrapper script, if you're using Freetz) and use the rc.multid script for multid start as above.
You have to take care, that the ctlmgr service is stopped as short as possible. If it's recognized as 'missing' from other services, they could consider a restart of the box ...

2. It's one possible solution, what you did above. But do you know, how to use 'sed' to edit files ?

Your solution is a little bit error-prone ... using head/tail and skipping lines relies on the existing file structure. Each change (done by AVM) here could render your script useless or - in worst case - could result in an invalid settings file.

Imho the better solution would use 'sed' (after copying the original file to a temporary location) to locate the first and last line of the 'landevices' section. After the first line is known (every editing is done relative to that line), analyze the contained entries and create a delete command for each unwanted entry. As last step, execute the delete command list with 'sed' and the resulting file is your new ar7.cfg.

 

[informerex]

@PeterPawn
ist es nicht einfacher wie oe. einfach die IP zu ändern und danach zurück auf Standard-IP - evtl. über ein script?

 

[frater]

I'm rebooting the box because in the past I've had several Fritzboxes back to factory default after executing ar7changed.
The changes I then made were done very carefully with nvi and I'm sure there were no errors in the file. For sure not in all these cases. since I opt for rebooting this never happened again..

I don't think this way is more error-prone than using sed. Nothing can be messed up outside the scope of my focus. Only the structure with brackets can't be changed by AVM. They can add lines or remove lines...

It's of course also a matter of preference.
I hardly ever get bitten.

 

[frater]

@PeterPawn
ist es nicht einfacher wie oe. einfach die IP zu ändern und danach zurück auf Standard-IP - evtl. über ein script?

I'm not 100% sure but I think I will lose too many settings. All my port forwards will probably become invalid and deleted. Also the static leases.

I am doing this on only a few production routers and can't afford to lose these settings. I do have automatic backup of all these routers.

I Would still be interested if this would work without losing these settings.

 

[frater]

You have to take care, that the ctlmgr service is stopped as short as possible. If it's recognized as 'missing' from other services, they could consider a restart of the box ...

Thanks...
Maybe I should shorten that sleep which is probably superfluous already


I do know sed, but it quickly becomes cryptic

 

[PeterPawn]

I'm rebooting the box because in the past I've had several Fritzboxes back to factory default after executing ar7changed.

It's your decision ... but it's even unneeded and I wrote (with caution) nothing about 'ar7cfgchanged', if you look inside this script, you'd see: It's only another wrapper für 'rc.net reload'. I use a wrapper script (even more sophisticated) to edit configuration files for years now and if a file is changed, which is cached by ctlmgr, the service will be stopped, the file will be stored and the service will be restarted afterwards. It simply works ... if you know, what you're doing.

It was your wish to get comments ... and if someone else is finding this thread, he should know, that there's another choice without the overhead of a complete restart.

@informerex:
Ich habe ehrlich gesagt noch nicht probiert, was dabei noch alles zusätzlich mit "abgeschossen" wird (neben ctlmgr und multid). Ich tippe aber mal auf ähnliche Effekte wie bei 'rc.net reload' mit all den Nebenwirkungen, die in diesem Falle (wenn man wirklich nur lokale Leases löschen will) unnötig sind (das geht - wenn dabei der dsld mit beendet wird - bis zur neuen IP-Adresse beim PPPoE-Login und DynDNS-Änderung, usw.). Aber wie gesagt, ich habe das noch nie getestet ... käme auch nicht auf die Idee, da bei mir selbst die IP-Subnets alle noch einmal in einer recht umfangreichen iptables-Konfiguration verwendet und auch von einem IPS/IDS überwacht werden und da kann ich mir ein Umbennenen (nicht mal temporär, solange dabei das Kabel steckt) nicht erlauben, sonst ist die MAC-Adresse ruckzuck in der Blacklist.

 

[frater]

It's your decision ... but it's even unneeded and I wrote (with caution) nothing about 'ar7cfgchanged',

It was a direct answer on your question why I chose for a reboot.

I will for sure investigate it and will probably do that as I of course prefer to have no downtime.

I very much appreciate your comments.

 

[frater]

I have modified the script and will now implement it on at least 5 boxes and run it weekly using cron.
Thanks PeterPawn for your input

I still think it's strange no-one has ever bumped into this problem.

 

[frater]

I will go back to rebooting the box.
I just lost 2 connections on doing that. The ones that did the reboot work fine.
I presume you'll say that my modifications of the file made them corrupt, but I'm sure they were not...
As said.. had this before with ar7changed.
I will not do this again on a remote box.

Tomorrow morning I have to go to these sites and I expect that they both went to factory default.
Will let you know what happened.

The safe approach (IMHO) is rebooting.
It's being done on Monday morning at 5:15 AM
So I will just stop multid, change the 2 configs and then reboot.

 

[PeterPawn]

I'm sorry to hear that ... but would you publish your current script please ? I don't understand, why you compare the results of ar7cfgchanged and my suggestion ... how did you realize the current solution ?

I will not say, your changes at all are the reason ... but why do you assume the boxes are set back to factory settings without knowing it for sure yet ? Prejudice ? There's no chance, you did stop/restart the service(s) wrong, e.g. out of the right order ?

To play fair, you should determine the issue first and then blame any parts of the firmware and/or any suggestions, shouldn't you ?

That a box, which is restarted day by day, is more responsive than another one, which is running a longer time, is not so surprising, isn't it ?

If you can accept the downtime while restarting, accept it ... but please do not blame the idea/suggestion to stop and restart only the needed services, as long as you've no evidences, that you did it right and the idea is bad at all and malfunctioning from core. Thanks.

EDIT: As far as I've understood your changes to #9 (it's a bad behaviour to change an earlier posting without any notice and remarks, because the participants can't recognize the pre and post state of it and do not get an automatic notification - do you read the whole thread again, before you answer ?), you've stopped the ctlmgr service prior to multid. This can lead to an error condition, 'cause the multid service tries to unsubscribe from various IPC mechanisms while stopping and one of them is - as far as I know - a communication socket to the ctlmgr. My suggestion in #11 to stop the services contains the right order ... first stop multid, then stop ctlmgr.

And by the way ... why should "ar7cfgchanged" (the final (and only) command executed is "rc.net reload", if you track the flow of execution) reset a valid configuration file to factory settings ? The same start commands for the daemons are issued during every start of the box ... if you agree, that the firmware works deterministic, they should be reset during a "normal" restart from time to time too, shouldn't they ? If you want to show, that your changes are valid, save a copy of the new ar7.cfg file to a nonvolatile storage ... so you can examine it later, if the firmware did a factory reset again and you suspect this to be a mistake.