Disable VoIP in VoIP enabled models

[frater]

I have a mix of about 50 Fritzboxes in maintenance and they are all running Freetz and are monitored using a Zabbix-agent on the device.

Sometimes I use a VoIP-enabled Fritzbox where a 3CX-PBX is running in its network.
I then have to forward port 5060 and the ports for RTP (the actual voice streams) to 3CX.

The AVM firmware blocks you from making such an entry as it already has made a port forward to itself for these ports.
You can reconfigure Fritzbox to change its default behaviour by editing the 2 files /var/flash/voip.cfg and /var/flash/ar7.cfg
There's an example given here: http://www.pe2mbs.nl/?page_id=223

This works fine.

I do have 1 problem with it.
There's no way to see this in the settings using the WebIF.
It would be nice if an addition is made to Freetz so these setting can be changed.
Making a VoIP-section where it merely can be viewed is also an improvement.

 

[frater]

I still have this need to disable the VoIP in VoIP enabled routers (7390, 7490, 7460).
I'm quite capable of doing this on the CLI, but this is not what this is about. I need the comfort and feedback of the GUI so I can login to the router and see that VoIP is disabled/enabled.

I just looked up this 2-year old post of mine and was amazed it didn't have a response. I can remember some back and forth with Freetz developers, but I don't know why nothing came out of it.

Could it be addressed in some way?
If nothing will be done it's fine too (but of course not preferred), then I know I should let it go.
It's just a shame if it's not implemented due to some misunderstanding.

Cheers

 

[PeterPawn]

Can't you see the current state of VoIP related forwarding in the security summary page? Why?

If you think, it's too elaborate to perform all the actions/checks done there every time you'd like to know this single setting only, look into the Lua source of the security page and add the needed code to detect the target of a forwarding on UDP port 5060 and add an additional line (optional with "LED signaling design" - it's only your decision) regarding this state on the main page.

It's easy to realize and your objective is rather seldom ... personally I wouldn't expect, this will be build (or even needed) by someone else.

So why don't you implement it yourself?

 

[frater]

This is the kind of misunderstanding I mean.
Both Freetz and AVM Fritz try to control the box using a webIF.
Turning VoIP off is not possible using the WebIF. It's only possible using the CLI

Forwarding the SIP-ports to a device on a LAN is only possible if these ports are free.

It's easy to realize and your objective is rather seldom ... personally I wouldn't expect, this will be build (or even needed) by someone else.

So why don't you implement it yourself?

I have not focused enough on the Freetz framework to add new entries to it.
I did contribute in other ways

 

[PeterPawn]

I need the comfort and feedback of the GUI so I can login to the router and see that VoIP is disabled/enabled.

This was your (explicitly expressed) objective, was it?

My suggestion was/is completely unrelated to the Freetz framework - I meant, you can modify the Lua pages and (afaik) Freetz doesn't use Lua for its interface (not yet at least).

And your finding, that you have to change anything in the ar7.cfg file to make SIP forwardings possible, does not match my own experiences. I've double-checked it just again ... a 7390 device with (previous, not current) beta firmware, configured as router over LAN1, did not prevent me from setting a port forwarding for UDP/5060 to a host in its LAN segment.

As long as the telephone functions stay "unconfigured" (if this isn't possible in your environment, you've missed an important fact in your description), the "telefon" and "voipd" daemons will be started, but no ports are forwarded to the own (LAN) address of the device.

If I've used the wrong device and/or firmware version for my own verifications ... what would you think, could be the reason?

 

[frater]

This was your (explicitly expressed) objective, was it?

My suggestion was/is completely unrelated to the Freetz framework - I meant, you can modify the Lua pages and (afaik) Freetz doesn't use Lua for its interface (not yet at least).

No, I just want it in Freetz

And your finding, that you have to change anything in the ar7.cfg file to make SIP forwardings possible, does not match my own experiences. I've double-checked it just again ... a 7390 device with (previous, not current) beta firmware, configured as router over LAN1, did not prevent me from setting a port forwarding for UDP/5060 to a host in its LAN segment.

We always use virgin Fritzboxes and in the past I've always had to do this.
That's also the reason why tutorials exist like the one I referred to.
Why wouldn't they suggest to just turn the device into factory default?

These entries exist in 7390's by default (I'm testing it as a DSL-router)

I need to do a recover to test this again. The last time was some time ago...

Maybe this has something to do with the German/International mess that was created by AVM
In the Netherlands we can't buy these German Fritzboxes and it seems "we" will always have anomalies with Freetz that have their source in this mismatch.

Freetz gets only tested on German firmwares. I'm now only sticking to 7490's and I can't upgrade any of the more rare models anymore because I can't build a properly working Freetz for those anymore.

 

[PeterPawn]

These entries exist in 7390's by default (I'm testing it as a DSL-router)

Please describe exactly, which model (7390 or 7490, as later mentioned) and which firmware version you're using - I gave you the facts about my environment and test conditions and for this case I can assure, that (even if statements to handle UDP/5060 as "special" may exist in ar7.cfg from scratch) there's no active port-forwarding to the device itself and that I could add a port-forwarding to a LAN host without any changes to the ar7.cfg file or via CLI. Period.

Regarding to your original text

Turning VoIP off is not possible using the WebIF.

I would say: Correct. - but it's not turned on (in the tested configuration and I would bet, it's the same behavior regardless of the question, if the builtin modem is used (DSL) or not (LAN1) ... but that's really an assumption only) until you set up any telephone related parts (external or internal). As long as you do not touch these settings, (in my environment ... and without the exact pre-conditions and a description in detail, nobody can verify your findings) the forwarding is possible.

I'm now only sticking to 7490's and I can't upgrade any of the more rare models anymore because I can't build a properly working Freetz for those anymore.

How should anybody be able to understand such a vague statement?

"[...] the more rare models [...]" (which models, which firmware base) and "anymore" (which would imply, it was possible in the past) are unlikely to be a base to understand your situation ... and even if it's always present to yourself, there are many other users in this forum with many other problems and you should take the time to specify your "mix of 50 devices in maintenance" more exactly and add all relevant facts in the first question instead to add it in dribs and drabs.

It saves time, if a reply isn't necessary/useful, because the pre-conditions for the answer were wrong from beginning - but you've to know these conditions to see this (uselessness).

 

[frater]

It just happens that I needed to configure a new 7490
I tested it and indeed it is possible to do a port forward of 5060 to a LAN-address.

Given my experience in the past and the existence of that site as a workaround this must have been changed in more recent 6.x versions or maybe even before.
It probably was addressed by AVM at some point. It's not something I test each time when I configure a router.


It is no longer necessary then....
If I'm in the position to test it some other time with an older version


The "rare models" I'm refering to are the 3270 and the 7360
All these routers are with customers now and I can't afford to experiment on them.
They are now running a Freetz version which I created about 2 years ago.
I can't access them anymore with chrome because it chrome doesn't accept the AVM's SSL. With Firefox and some tweaking it is possible.
I made the mistake of creating a new firmware with my current environment for 1 router half a year ago.
The next morning I had to go to that customer and flash it.

I just checked it again and it turns out I decided to put an AVM firmware on it (a 7270v3 with FRITZ!OS 05.53)
Most 7270 have a freetz-devel-11903M version I created on 29.03.2014 00:24:05
I prefer to leave these alone now.

A 3370 with a version I created on 04.06.2014 15:07:01 (freetz-devel-12091M ) is running fine.
Except that it suddenly wasn't accepted anymore by most browsers due to weak SSL-protocol.
An upgrade is not something I want to do anymore....


That environment works fine for 7390 and 7490, but I can't create any versions for these modems (7360, 3270 and some others).
That same environment was also fine for these models.

In the past I've had more of these bootloops. It then turned out that some special handling was needed for the International version. Because you're all only testing German versions this is found later (no pun intended at all).

- - - Aktualisiert - - -

I'm extracting the Freetz-version with Zabbix, so I could make this inventory.
I thought I had less unique versions

It's 86 routers now

      2 05.24-freetz-devel-11903M
      2 05.52-freetz-devel-11898M
      2 05.52-freetz-devel-12122M
      2 05.53-freetz-devel-11898M
      2 06.04-freetz-devel-11898M
      2 06.04-freetz-devel-11903M
      2 06.04-freetz-devel-11923_1
      2 06.04-freetz-devel-12020M
      2 06.04-freetz-devel-12046M
      2 06.04-freetz-devel-12091M
      2 06.06-freetz-devel-12020M
      2 06.06-freetz-devel-12846M
      2 06.06-freetz-devel-13282M
      2 06.20-freetz-devel-13044M
      2 06.20-freetz-devel-13108M
      2 06.20-freetz-devel-13139M
      2 06.30-freetz-devel-13414M
      2 06.30-freetz-devel-13466M
      2 06.30-freetz-devel-13529M
      2 06.30-freetz-devel-13560M
      2 06.30-freetz-devel-13633M
      2 06.30-freetz-devel-13645M
      4 05.53-freetz-devel-11903M
      4 06.03-freetz-devel-11878M
      4 06.30-freetz-devel-13373M
      4 06.30-freetz-devel-13599M
      4 06.30-freetz-devel-13627M
      6 06.31-freetz-devel-13657M
      8 06.03-freetz-devel-11903M
      8 06.20-freetz-devel-12845M

 

[PeterPawn]

A comprehensive list ... but without the appropriate info, which vendor version is the base for each Freetz image (the box version number in this name (113 for 7490, which has HWRevision 185) will also reveal the model), it's more or less useless.

Even if we assume, you're using only international firmware, is there more than one model in question for a version 06.04, 06.06, 06.20 or 06.30.

Looking at the changeset number from Freetz trunk in your image names, you've made a 05.52 based version long time after some 06.04 versions (CS 12122) and on the other hand there's a very very old (and presumably threatened) version 05.24 on at least one device (as far as I understand your listing).

Nobody (beside the vendor itself) can try each AVM version on each possible model ... even if you find a bug and file a report, you've to take the time to check any attempt to fix it. That's a discrepance to the intention, to provide each of your customers with a "tested version" ("I can't afford to experiment on them.").

No-one beside yourself may/will take any efforts in this direction ... if you'd like to use only fully tested firmware, don't use Freetz or test it yourself. Who else should do this or - more important - why?

If you think, the support for international firmware versions in Freetz is too poor, go leading by example and invest your own spare time into such tests.

If the maintenance for the mentioned devices is a paid job for you, there should be the time to manage updates in a responsible manner and then (my personal opinion) a version like 05.24 should not be present anymore on any device.

At least I can't find any model, where this version (it's from late 2012 due to its number) was the last one (even for "international") before EOS was reached. If I'm wrong ... I await with interest the enlightenment, which model it is. I'm not aware of any device (with an endangered firmware version), that was not supplied with a fixed version after "webcm gate" in early 2014.

But that's only my personal position ... I'm sure, you know what you're doing - but your expectation (somethings sounds like this in your posts, but I could be wrong, it's not an insult), that someone else will provide you with fully-tested Freetz versions for your purposes (and your whole equipment), is acted a little bit naive.

Some of your statements sound as if you use a "fixed" configuration to build your Freetz images and this is simply impossible in most cases and especially considering your wide range of devices (and architectures) to support. At least you should use an own instance for each model and for each (major) version change. But may be, I've only misunderstood the statement "That same environment was also fine for these models.".

The problem regarding the weak TLS connections isn't Freetz related and so it cannot be solved with a newer Freetz image (based on an old vendor version) ... even with a newer OpenSSL version in the Freetz image the AVM GUI will not use a better TLS algorithm - and Freetz itself doesn't use any TLS connection for its interface, so your statement must be related to AVM's GUI.

If a newer Freetz version isn't running on your devices (I would assume, you have at least one own (spare) device for each model existing in your responsible area), you should investigate the reasons. You will get any possible help to do so ... but I would bet, you will not find somebody to do this for you (or you have to pay for it).

 

[frater]

Hi Peter,

We had this before, but my expectations of Freetz aren't at all as you descrive it.
Somehow you seem to think that I can't do anything myself and "expect" you to provide me with full working and tested versions for my AVM's which I manage in a commercial environment.

I\ve tried in the past to keep all the fritzboxes on the same version.
I can remember a night in which I flashed more than 50 fritzboxes.
Because I sometimes make some improvements on the extra software I add to monitor these I have upgraded some of these to newer versions.
In the end I now have too many different versions.

Now that the infratstructure is upgrading I'm also forced to upgrade routers to a 7490 because they become unstable on a 7390 after migrating to VDSL2

I don't have any of those 3270's or 3370 anymore because I don't want them.
If such a device would break down (only had some lightning issues thus far) I can easily replace them with another model as each night an automatic backup of the AVM config and Freetz config is fetched from a remote server, This backup can be placed on another model.

I believe it is possible to convert and international fritzbox to a german fritzbox, but I haven't found the time to investigate how to do this.
I'm convinced I will have less problems then

 

[PeterPawn]

No, I do not think (in any case) ... trust me. :mrgreen:

I have read the sentence

Freetz gets only tested on German firmwares. I'm now only sticking to 7490's and I can't upgrade any of the more rare models anymore because I can't build a properly working Freetz for those anymore.

and my response was only intended to show you, that nobody else will/would test newer versions, if no "user" of Freetz will do this test.

It's solely your own decision, if you invest the time and try to get newer Freetz images up and running on your devices ... but it's even useless to "complain" about a poor support for intl. versions and - beside my own impressions - that's the essence of "Freetz gets only tested on German firmwares." (it's the passive way only to determine it and the active one would be to test it yourself).

If you think, it should also be verified thoroughly on international versions, you have to/can/should do it and file your findings in case of errors. After a possible solution/fix was provided, the cycle starts over.

I'm not a Freetz developer, but I would think, most of "FRITZ!Box modding" is done by Germans and so it's only natural, that the German version will get more attention (even from the vendor himself/herself/itself) and is better supported.

Why should a German (with a DSL connection in Germany) change his own device to the other firmware version and run tests with it? Some/most tests aren't possible at all, if the wrong technology is present (POTS vs. ISDN, ADSL vs. VDSL, Annex and so on) and it doesn't really matter, if the international version "rejects to run", if nobody uses it or is really interested to get it running. Only to state "it's malfunctioning" isn't enough involvement ... if you've filed error reports in the past, please provide a link to them.

If there's anybody interested to use the intl. version, he/she should run the needed tests and report any findings and - after a fix was provided - take the time again (and over and over again, if needed) to finish the whole problem.

If it's only "reported" and the possible solution is never checked again, next time the developer will think twice, if he/she invest time again into the next try.

As mentioned above, I'm not a Freetz developer ... but I'm not aware of open problems "freetzing" an intl. 06.30 version for a 7390. May be, I'm wrong ... but there's a ticket system to track such issues and a (more quick than thorough) search didn't find one. Can you show me some open (elder) tickets?

Some problems from the past (e.g. using a uClibc, which doesn't throw the needed exception parsing a string with scanf() and a "%m" mask, leading to watchdog initiated reboots after ctlmgr crashes) are solved since a long time (or should be solved at least) and so I cannot confirm your impression(?), that the intl. version "gets" handled poorer than the german.

If there are special problems, only the users may reveal and report them. Most of the changes (beside the modifications of vendor's GUI) made by Freetz do not distinguish between german and intl. - if they result in different behavior, it's unexpected and should be investigated ... but it's the user's task to report such things.

Remember, it's not an offense ... may be I'm too stupid to find your reports. If they do not exist, it's not a surprise if bugs will never be "hunted".

 

[frater]

If I can add a modern 7390 and 7360 to my list I'm fine.
I had some DSL-sync issues with a modern 7390 firmware, but I solved that by not replacing the kernel.
For the 7360 I would like to have one too, but last attempts (now some months away) resulted in a bootlooping device.

I have a 7360 at work, but it's acting as a PBX for several SIP-client. I prefer to leave it.

Was it you that told me I had to wait for 6.35 to get rid of these lame leases?
It seems still so far away.
If that's implemented I hope I can replace all firmwares....

One question more.....
AVM is obliged to post those sources and it seems they do that quite late.
Is there some place where we can "complain"?

 

[PeterPawn]

Yes, it was my hint ... the new firmware has a button to "forget" all unused clients ever seen before, which can be initiated by CLI also.

But I cannot push AVM to finish the intl. versions and to publish them in the foreseeable future ... I'm also awaiting the intl. version for 7490 to continue some projects. The time since the release of 06.50 (12-06-15) or 06.51 (02-03-16) and today seems endless ... in the past the intl. versions were coming 6-8 weeks later, but it looks like AVM will skip the 06.50 intl. for 7490 (imo).

The kernel sources are published now ... they should not differ from german to international version. IMO it's useless to complain about a "late release" of these sources ... as long as the firmware isn't released, it isn't "bundled" with the hardware and (some experts confirm to this idea) it's not necessary to publish the sources immediately with the first beta versions.

 

[frater]

For Zabbix I wrote a new function which exposes some more info as 1 string.
After modifying all modems I noticed that it still didn't provide all the info to exactly define the compiled version.
I think I'm going to add the compile time....

In the zabbix_agentd.conf it looks like this:

UserParameter=system.fingerprint, sed -e 's/<\/j:.*>//g;s/<.*>//g;s/ /./g;/^$/d' /var/jason_boxinfo.xml | awk '$1=$1' ORS=' '

For Zabbix someone developed a CLI system in python to extract metadata from the frontend of Zabbix (https://github.com/q1x/zabbix-gnomes).
So no mySQL-stuff and it can even be done on another machine.

I wrote a little wrapper in bash that will make nice groups of similar items

# cat /usr/local/sbin/zitem

#!/bin/sh


GROUP="$1"                              # Zabbix Group
ITEM="${2}"                             # Zabbix item
FIELDS=`echo "${3}" | tr -cd '0-9'`     # Amount of fields to group


HOSTS=`mktemp`
SCRATCH1=`mktemp`
SCRATCH2=`mktemp`


# Extract all hosts from Group $1
zghostfinder.py "$1" 2>/dev/null | tr ' ' '.' >${HOSTS}


# Collect the Host with item $2
while read HOST ; do
    echo "$HOST `zgethistory.py -C 1 $(zhitemfinder.py 2>/dev/null -k "${ITEM}" -n ${HOST}) 2>/dev/null`" >>${SCRATCH1}
done<${HOSTS}


# If fields are given then group similar fields and show them in blocks, last block has most lines
if [ -z "${FIELDS}" ] ; then
  cat ${SCRATCH1}
else
  let FIELDS+=1
  cut -d' ' -f2-${FIELDS} ${SCRATCH1} | sed '/^$/d' | sort | uniq -c | sort -n |  awk '{$1=""; print $0}' > ${SCRATCH2}


  while read CONFIG ; do
    echo ${CONFIG}
    grep "${CONFIG}" ${SCRATCH1} | sed -e 's/.*/   &/g'
    echo ''
  done<${SCRATCH2}
fi




rm ${HOSTS}
rm ${SCRATCH1}
rm ${SCRATCH2}

# zitem firewalls system.fingerprint 4

FRITZ!Box.3390 193 121.06.20-13044 29377
   freetz.henb FRITZ!Box.3390 193 121.06.20-13044 29377 0896D7D2FEF4 avme en A 031 2


FRITZ!Box.3390 193 121.06.20-13139 29377
   freetz.kapp FRITZ!Box.3390 193 121.06.20-13139 29377 0896D7BB0488 avme en A 031 2


FRITZ!Box.7490 185 113.06.04-12020 27507
   freetz.den******** FRITZ!Box.7490 185 113.06.04-12020 27507 0896D7732222 avme en A 031 crashreport


FRITZ!Box.7490 185 113.06.30-13414 31156
   freetz***** FRITZ!Box.7490 185 113.06.30-13414 31156 0896D77683B2 avme en A 031 crashreport 2


FRITZ!Box.7490 185 113.06.30-13560 31156
   freetz.zzp FRITZ!Box.7490 185 113.06.30-13560 31156 C80E14175B2B avme en A 031 crashreport 1


FRITZ!Box.Fon.WLAN.7270.v2 139 54.05.24-11903 27630
   fritz.de-wetering FRITZ!Box.Fon.WLAN.7270.v2 139 54.05.24-11903 27630 0024FE71B43F avme en B 031 crashreport


FRITZ!Box.Fon.WLAN.7270.v3 145 74.05.53-11898 27445
   freetz-solid FRITZ!Box.Fon.WLAN.7270.v3 145 74.05.53-11898 27445 BC0543641D9A avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7340 171 99.06.06-13282 27689
   freetz-opl**** FRITZ!Box.Fon.WLAN.7340 171 99.06.06-13282 27689 BC0543C68F09 avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7360 183 111.06.04-11898 27507
   freetz.hu**** FRITZ!Box.Fon.WLAN.7360 183 111.06.04-11898 27507 9CC7A648C511 avme en A 99 crashreport


FRITZ!Box.Fon.WLAN.7360 183 111.06.04-11903 27507
   Erwin FRITZ!Box.Fon.WLAN.7360 183 111.06.04-11903 27507 246511B3B8FC avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7360 183 111.06.04-11923 27507
   Freetz-Bure**** FRITZ!Box.Fon.WLAN.7360 183 111.06.04-11923 27507 C025065A7A66 avme en A 031


FRITZ!Box.Fon.WLAN.7360 183 111.06.20-13108 29377
   freetz.glas FRITZ!Box.Fon.WLAN.7360 183 111.06.20-13108 29377 246511BAFF3A avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.06-12020 27689
   freetz.d***** FRITZ!Box.Fon.WLAN.7390 156 84.06.06-12020 27689 246511FA5545 avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7390 156 84.06.06-12846 27689
   freetz.eigen***** FRITZ!Box.Fon.WLAN.7390 156 84.06.06-12846 27689 C02506984DDA avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7390 156 84.06.20-13108 29288
   Kin*** FRITZ!Box.Fon.WLAN.7390 156 84.06.20-13108 29288 9CC7A684AA0F avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13373 31156
   fritz.plu**** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13373 31156 C025062B30D8 avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13466 31156
   freetz-shir*** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13466 31156 0896D743728C avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13529 31156
   freetz-par**** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13529 31156 C02506CF76F6 avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13633 31156
   fritz.di**** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13633 31156 0896D743717D avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13645 31156
   fritz.now**** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13645 31156 BC05435AB91D avme en A 031 crashreport 2


FRITZ!Box.WLAN.3270.v3 168 96.05.52-11898 27362
   fritz.kik FRITZ!Box.WLAN.3270.v3 168 96.05.52-11898 27362 C02506701A3E avme en A 031 crashreport


FRITZ!Box.WLAN.3270.v3 168 96.05.52-12122 27362
   freetz-ar***** FRITZ!Box.WLAN.3270.v3 168 96.05.52-12122 27362 C025065DB3E7 avme en A 031 crashreport


FRITZ!Box.WLAN.3370 175 103.06.04-12046 27507
   freetz.tc*** FRITZ!Box.WLAN.3370 175 103.06.04-12046 27507 0896D7719D73 avme en A 031


FRITZ!Box.WLAN.3370 175 103.06.04-12091 27507
   pinto FRITZ!Box.WLAN.3370 175 103.06.04-12091 27507 0896D75BDABF avme en A 031


FRITZ!Box.7490 185 113.06.30-13599 31156
   freetz.zeg**** FRITZ!Box.7490 185 113.06.30-13599 31156 C80E14172BC1 avme en A 031 crashreport 2
   freetz-to***** FRITZ!Box.7490 185 113.06.30-13599 31156 0896D7792BD9 avme en A 031 2


FRITZ!Box.Fon.WLAN.7270.v2 139 54.05.53-11903 27445
   fritz.donth**** FRITZ!Box.Fon.WLAN.7270.v2 139 54.05.53-11903 27445 0024FECD8435 avme en A 031 crashreport
   fritz.kap**** FRITZ!Box.Fon.WLAN.7270.v2 139 54.05.53-11903 27445 0024FEC8D283 avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11878 27351
   Freetz-Dof**** FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11878 27351 C02506CFBE00 avme en A 031 crashreport
   freetz.keizer*** FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11878 27351 9CC7A60EAE38 avme en A 031 crashreport


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13627 31156
   Freetz.4**** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13627 31156 246511579B58 avme en A 031 crashreport 2
   freetz-zi***** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13627 31156 9CC7A6268F05 avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13659 31156
   freetz.overhe**** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13659 31156 9CC7A60EBAC0 avme en A 99 crashreport 2
   freetz.honin***** FRITZ!Box.Fon.WLAN.7390 156 84.06.30-13659 31156 9CC7A68494CF avme en A 031 crashreport 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11903 27351
   Freetz-ma**** FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11903 27351 C025062AC73D avme en A 031 crashreport
   fritz.kop**** FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11903 27351 BC0543435DA2 avme en A 031 crashreport
   thom*** FRITZ!Box.Fon.WLAN.7390 156 84.06.03-11903 27351 24651177B073 avme en A 031 crashreport


FRITZ!Box.7490 185 113.06.31-13657 32500
   freetz.kad*** FRITZ!Box.7490 185 113.06.31-13657 32500 5C4979313AFF avme en A 031 crashreport 2
   freetz-JP FRITZ!Box.7490 185 113.06.31-13657 32500 0896D776716F avme en A 031 2
   Charle**** FRITZ!Box.7490 185 113.06.31-13657 32500 5C497950A5F3 avme en A 031 crashreport 2
   freetz.alle****** FRITZ!Box.7490 185 113.06.31-13657 32500 3431C4810119 avme en A 031 2


FRITZ!Box.Fon.WLAN.7390 156 84.06.20-12845 29288
   heal***** FRITZ!Box.Fon.WLAN.7390 156 84.06.20-12845 29288 246511FA9177 avme en A 031 crashreport 2
   Atel**** FRITZ!Box.Fon.WLAN.7390 156 84.06.20-12845 29288 246511FA9FA4 avme en A 99 crashreport 2
   nd** FRITZ!Box.Fon.WLAN.7390 156 84.06.20-12845 29288 0896D7432844 avme en A 031 crashreport 2
   freetz-gree**** FRITZ!Box.Fon.WLAN.7390 156 84.06.20-12845 29288 0896D77DFC89 avme en B 031 crashreport 2

What a mess I made....
But as I'm writing this a lot already has been consolidated.
Last week I needed to troubleshoot a 7390 that became unstable after upgrading to VDSL.
I experimented with some versions and a new one without a kernel-replace made it rock solid.
This means I can upgrade all 7390's to that version.

- - - Aktualisiert - - -

The "system.fingerprint" item I created wasn't sufficient enough to determine exactly which build it was.
If I change some options in "make menuconfig" I will get the exact same output with that item, but it would have other software on it.
It's still a useful item as it also contains the serialnumber of the device

I therefore created the item "system.image"

UserParameter=system.image, grep FREETZ_INFO_IMAGE_NAME /etc/freetz_info.cfg | awk -F= '{print $2}' | awk -F\' '{print $2}'

In the meantime I have all my 7490's and 7390's on the same recent and tested version.
Next week I will continue with the other models

# zitem firewalls system.image 1

7490_06.31-freetz-devel-13657M.en_20160315-042640.image
   freetz-JP


7390_06.30-freetz-devel-13659M.en_20160323-170337.image
   freetz-p*****
   Freetz.4w****
   freetz.do*******
   freetz.ei******
   Ate******
   n*****
   freetz-sh****

My Windows machine at work is breaking apart. It suddenly became extremely slow and I had to power it off using a mains cut. Afterwards my Hyper-V machine stopped working in which I have the Freetz development. After a reboot my whole Hyper-V service stopped and can't be started again. I used syncthing to transfer these Hyper-V images to my home PC and luckily they could be imported there..... Later this evening my machine at work went off-line. I wonder what happened.
I think the OCZ 240 GB SSD is falling apart
Recently we had 4 customers that had their OCZ 120 GB SSD's broken down completely. It seems some fault in their firmware....
Maybe this 240 GB is affected too.....
Pffffffffff