7412 neueste FW bzw. Labor gesucht...

[inf64]

I have used both.
Interesting thing is that

echo "kernel_args annex=A" > /proc/sys/urlader/environment

sticks after all the reboots.

However the :
echo "annex A" > /proc/sys/urlader/environment

does not stick and needs to be entered through telnet in case modem does reboot for some reason.

I have achieved not only sync (after the Annex A is typed in as a command, pictures below), but I have also now achieved PPPOE connection! Internet works, hooray!
I on purpose put the stability for downstream to maximum stability while for upstream I left it at maximum performance. Sync on ZTE and Huawei were 16Mb/1.2Mb while with these settings on FB 7412 I have now much more stable 13Mb/1.17Mb and CRC error count is very low.



I didn't mention that both ZTE and Huaweie were working "OK" meaning no sync drops UNTIL 12 in the night, when some RFI/EMI noise impusles start in my neighbourhood and this causes to SNR to drop and I lose sync. This was very bad for VOIP sessions or online games which made me look into routers who can control SNR margins (hence fritzbox). My exchange lowered my plan from 20Mb to 16Mb on my recquest in order to stabilize the line but drops still happened only after midnight.

Now I will monitor the line after midnight and see how Fritzbox does. If it does well I will stick with FB. I am still looking for a way to make Annex A change stick. I might create a script that launches cmd and telnets into the router every time I start my PC or call the script manually.

 

[inf64]

Could you please provide a screenshot of the spectrum, too?
What happens if you would enter the changes for the annex per ftp in adam?

quote SETENV annex A
quote SETENV kernel_args annex=A

Haven't tried that yet, I will wait till midnight first to see how router behaves in increased RFI conditions. If it all goes well I will try to reboot it and try the commands via ftp and see how it goes.


I have backed up the config file and there I saw you can enter Annex A option as well (dunno if it makes any difference) and override SNR margin offset to be more than 4dB.

Below is screenshot of spectrum tab:


Looks like typical US0 and DS1 spectrum for 8b standard.

 

[PeterPawn]

Changing the "kernel_args" environment settings value after the kernel was loaded, shouldn't change anything.

Any unknown kernel argument is passed to the "init" command line (for PID 1).

The "annex" parameter specified this way will be detected in /etc/init.d/S01-head, but it's never used there or exported to the global environment.

Within /etc/init.d/rc.conf (called from S08-tffs and S09-config) the default annex value can be found (CONFIG_ANNEX - it's set twice in most models), together with a hint, if more than one annex is supported (CONFIG_DSL_MULTI_ANNEX).

The value of CONFIG_DSL_MULTI_ANNEX is usually changed one more time later, while the branding of the box is considered.

Near the end of rc.conf, the "real" annex value will be determined:

##########################################################################################
## Annex
##########################################################################################
if [ -z "$annex_param" ] ; then
if [ "${CONFIG_DSL_MULTI_ANNEX}" = "y" ] ; then
LOADANNEX=`echo ar7cfg.dslglobalconfig.Annex | ar7cfgctl -s 2>/dev/null | sed s/\\"//g` ; # annex aus userselection?
if [ -z "${LOADANNEX}" ] ; then
export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` ; # annex aus /proc nehmen, nicht von Config!
else
export ANNEX=${LOADANNEX} ; # annex aus userselection
fi
else
export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` # annex aus /proc nehmen, nicht von Config!
fi
if [ -z "${ANNEX}" ] ; then export ANNEX=${CONFIG_ANNEX} ; fi # nur wenn vom /proc nix kommt, default setzen.
else # annex_param
export ANNEX=$annex_param
fi

If the "kernel_args" value for "annex" was set (remember ... it's copied to "annex_param" in S01-head), it takes precedence. If the box (with the current branding) supports more than one annex, the correct value is taken from the configuration files, the "urlader environment" or the default value CONFIG_ANNEX (in this order, until a value is found).

After all of these preparations and efforts to get a valid (linux) environment variable named "ANNEX" ... it sounds funny, that changing the urlader environment value after the init process was completed (and it's already done, if you log-in to a telnet session) leads to an immediate synchronization. Are you really sure, that's the complete story?

Newer firmware is able to detect the really used annex itself (you can join some dots reading the shell script /etc/init.d/E40-dsl and other related files) and as far as i know, the CONFIG_DSL_MULTI_ANNEX value is used to enable this feature. Because the usually existing brandings in a 7412 box (avm and 1und1) are intended to be used in Germany only, the multi-annex value is (on most firmwares I've seen so far) set to "n" in rc.conf - checking annex A would only waste time here.

If you want to change this value, you could try to use the featovl.cfg file for a first check ... and if the results are as expected, you can change the rc.conf file later (which needs more knowledge, because it's read-only and has to be changed another way). But each change should lead to the expected result only after a reboot ... that's the main point confusing me. If there's some binary code changing the annex setting in the urlader environment or even reading it from this source (so a change takes places immediately), it would be very surprising and I'd think, it's rather an undiscovered bug in the firmware.

 

[inf64]

Interesting, thanks for the reply PeterPawn!

I am 100% sure the sync happens the second I try and change Annex to A via echo command in telnet.

By cfg file you mean parts of the config file that can be exported from FritzOS? I can post up the whole expiorted config file if you like.

 

[PeterPawn]

No, that's not, what I meant ... you can try to enter the command

echo -e "CONFIG_DSL_MULTI_ANNEX=y\nCONFIG_ANNEX=A" >/var/flash/featovl.cfg

after you made sure, the file (it's a character device) exists. If it's missing, you've to create it using

mkconfigfile /var/flash/featovl.cfg 215

prior to writing anything into it.

With this setting the code shown above (EDIT: in #23) would try to set the used annex value from the the mentioned sources. If you continue to use the kernel_args parameter and there's a closed-source component which reads the value from urlader environment (or changes this value in any way, as your issue with the volatile change to annex A would suggest), the rc.conf code continues to ignore other sources and if only using the kernel_args value is insufficient to change to annex A, you should reset the kernel_args parameter and try overwriting the firmware variables. If the box should start with the correct annex after these changes, you could persist them using another way - but for a first test this should be sufficient.

And please do me a favor and remove the full quote from #24 ... nobody needs to read the same text twice, it's all immediately above your posting. If everyone would quote this way, each new posting would grow more and more. Try "Bearbeiten" to change your text in #24 ... thx.

 

[inf64]

Sorry for the quote, my fail.

I will try what you suggest tonight. FB is basically the only vendor that has so many things one can tweak, it is crazy. Hopefully I can make the changes stick, will let you know what happens.

 

[inf64]

Small update from me. Router managed to hold sync for 16 straight hours (still going strong) and haven't dropped the connection in the night hours! This is an awesome thing. I will let it be as it is and see for how long can it hold sync with my exchange before I try anything else with the Annex A commands. Will keep you posted, FB 7412 is a mighty little box!

UPDATE:
Ok guys I have some really good news.

I tried the command that PeterPawn suggested:

echo -e "CONFIG_DSL_MULTI_ANNEX=y\nCONFIG_ANNEX=A" >/var/flash/featovl.cfg

I verified 1st that there is featovl.cfg file in that directory. Interesting thing is that when I do:
cat /proc/sys/urlader/environment

The Annex is still listed as B (kernel_args is A though, as it was sticking to that setting after reboot even before). BUT now router syncs without me needed to enter the echo Annex A command as before .
I suppose the router now picks up Annex A from the change made in featovl.cfg and uses it now.

Awesome, now I don't need to fiddle with telnet any more , router will sync automatically even if reboot happens.
And FB7412 survived the harsh RFI/EMI burst durring the night! I was sleeping so router was only maybe used sporadically by my android phone if it tried to contact google play.
Error count was going up right at those hours when it would usually drop sync with other (ZTE and Huawei) routers, but sync was maintaned by FB7412

I will monitor how router behaves next few days (and nights) and will update you. This could be useful to some other users from other countries who might buy FB 7412 1und1
edition .

Update #2:

I can verify that the command listed above is being displayed 1st (like overule) when I start telnet.

Now my FritzBox is displaying a new option in " Störsicherheit " which was not there before that command was executed! Annex A or Annex B selection


Thank you guys for your help , I almost gave up on this router !

 

[inf64]

My connection has been super stable since I last updated this thread, , FB7412 has not dropped sync yet

 

[MuP]

6.50 (rel. +rec.) + 6.30 (rec)

Firmware
ftp://ftp.avm.de/fritz.box/fritzbox.7412/firmware/deutsch/

Recovery
ftp://ftp.avm.de/fritz.box/fritzbox.7412/x_misc/deutsch/

 

[eisbaerin]

Hier das Thema dazu:
http://www.ip-phone-forum.de/showthread.php?t=284514

 

[michaelsantos]

Hi community,

first of all I would like to thank everyone here that give us so much information for the Fritz!Box.
Now to my problem for the experts: I have a Fritz!Box 7412 from 1&1 that I bought on eBay that will be sent and used in Portugal as a ADSL2 Router (Annex A). I already downgraded the firmware to 6.30 and performed the change that PeterPawn (Thanks!) mentioned:

echo -e "CONFIG_DSL_MULTI_ANNEX=y\nCONFIG_ANNEX=A" >/var/flash/featovl.cfg

I then accessed the webinterface of the Router and I could find the new option for choosing the DSL Annex (A or B). Then I upgraded the firmware to the 6.50 and the option is still there. Also, it is looking good! Now the only problem is: when I do a factory default, I loose this option. :heul:
It happens with the 6.30 and 6.50. By the 6.30 I could access the router using Telnet und create this entry again, but on 6.50 I loose Telnet access (is there already a workaround for Telnet access on 6.50?).
My question: is it possible to add this option to the factory default scripts or something, so it does not clear this from the featovl.cfg file? Can we change this file to read only or it still will be overwritten? I can see that the configuration backup file has the option for the Annex, but when I restore it, it does not activate the Annex option on the webinterface.
Any suggestion?

Thanks!

P.S.: Sorry if I have some writting errors, english and german are not my mother language.

 

[PeterPawn]

Too many options to describe each one in full length ... they also need different tools/platforms and skills.

The options are (unordered and incomplete listing):

- change the original firmware to contain these values from the beginning - eliminates the need to use featovl.cfg

- change the firmware to provide access to a command shell again (SSH or telnet or "shell in a box") - you may create the featovl.cfg then again

- try to prepare your own "provider additive" configuration archive and write this file (together with the "provider" value in the urlader environment) to TFFS (minor 29) - the firmware will set the needed files/values for you, but recovery can't be used anymore (I'm unsure, if featovl.cfg will be set this way, but it's worth a test)

- do a "factory reset" in another way (like the "recovery program" from the vendor does it) ... prepare your own TFFS image (from environment settings), add your own featovl.cfg content to it (as a zlib-compressed (deflated) stream) and write this file to "mtdnand" (that's the name of the right partition on the 7412) using bootloader's FTP server - everything is done "outside" of FRITZ!OS and the system may remain unchanged, the option above also could use this way

Due to the different skills needed, you've to provide much more information about your abilities and the available environment (devices, systems, tools). If you select the best option from above, you can search for additional sources, how to take the needed steps.

 

[michaelsantos]

Hi PeterPawn,

thanks for your reply. I was looking for a solution where I could still update the firmware without loosing the Annex option. So if I choose to change the firmware, I will have the same problem on a new firmware update. I don't know if I understood correctly the TTFS part (I'm relative new with Fritz!Box mods), but I would like to keep the router "free" for a ISP change. I know that the featovl.cfg file is not changed during upgrade, so I was thinking on "lock" the file, so it can't be changed by doing a "factory reset".

About my skills: I compiled in the past some OpenWRT firmware with some changes made by me for a Hotspot. I have some Linux knowledgement and some Programming/Scripting skills.

 

[PeterPawn]

The featovl.cfg file is (by intention, I'd bet) cleared on each factory reset, together with most other settings. The "provider additive" mechanism is just to circumvent these complete erasure, but the files will only be restored on next boot this way.

Writing an own TFFS image instead of "factory reset" is only another way to execute the same actions taken by such a reset ... it will clear all TFFS nodes with minor IDs above 100 (the "provider additive" parts (29) are below this point and the featovl.cfg is above (215)) and (optional) set a flag to clear the NAND data partition on next boot. The recovery program writes a complete new TFFS content (which destroys any earlier data, including minor 29) and the idea behind my suggestion is, you have to write your own image, which contains a new featovl.cfg from the beginning. Such an image can be constructed from the bootloader output (the recovery program uses the same info) and some additional data for the new featovl.cfg. Some shell scripts to support this idea were published in my GitHub repo under the "eva_tools" path, but there's no explanation, how to use them and you have to look into them first to understand their purposes.

The easiest way reenables an access to the command shell - this can be done without modifying the SquashFS image, but you need some Linux knowledge to create your own "firmware" to be loaded from the bootloader FTP prompt into the memory, where it will be executed once and may modify the yaffs2 partition to contain some additions to provide a command shell again (in a more secure way than telnet would do).

 

[michaelsantos]

Hi PeterPawn,

thanks for the suggestions, I will take a look at your scripts and read more info about the TFFS image.

Happy Easter!