Freetz für AVM DVB-C Repeater verfügbar?

[PeterPawn]

@baribal:
I've found a mistake I've made while writing the guide for the telnet daemon. The service file has to start /usr/sbin/telnetd indeed - it's the symlink created a few lines above.

 

[baribal]

@PeterPawn

Yep, just figured out this also recently. Thx.

 

[baribal]

@PeterPawn

Please find the dmesg of the 1750E original attached.

 

[PeterPawn]

Sorry, but it was extracted too late. It doesn't contain the first 0.5 seconds ... and that's the important(!) time, when kernel setup occurs. If you start your session earlier (if it's possible -> try it, when the WLAN LED starts to blink the first time), you should be able to catch even the earliest messages - if this will not work, you may/should add a line to some initialization script (e.g. /etc/init.d/rc.net), which runs early and saves the first part of kernel messages to a file under /var/tmp (dmesg > /var/tmp/kernel.messages.part1).

 

[baribal]

@PeterPawn

DVB-C 7.01 and 7.08 firmware doesn't have the systemd so I used a different approach https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-2x.307385/post-2378473:

echo "/usr/sbin/telnetd -l /sbin/ar7login" >>./etc/init.d/S85-apps

All works but I can't get the telnet connection and log earlier than 17sec.

As for nmi the below command didn't work for me (it produced the image of the same size), so I cut this into the multiple commands and the result looks ok from my pov:

freetz@freetz:~/freetz-ng$ ( dd if=alien_without_nmi_vector.image bs=$(( 0x10000 )) count=$(( 0xBE )); > cat nmi_vector; dd if=alien_without_nmi_vector.image bs=$(( 0x10000 )) skip=$(( 0xBE )) ) > alien_with_nmi_vector.image
190+0 records in
190+0 records out
12451840 bytes (12 MB, 12 MiB) copied, 0,0153458 s, 811 MB/s
nmi_vector: command not found
31+1 records in
31+1 records out
2082304 bytes (2,1 MB, 2,0 MiB) copied, 0,00255386 s, 815 MB/s

-rw-r--r--   1 freetz freetz 14534144 Aug 13 17:48 alien_with_nmi_vector.image
-rw-r--r--   1 freetz freetz 14534144 Aug 13 17:48 alien_without_nmi_vector.image

freetz@freetz:~/freetz-ng$ dd if=alien_without_nmi_vector.image bs=$(( 0x10000 )) count=$(( 0xBE )) >before_vector
190+0 records in
190+0 records out
12451840 bytes (12 MB, 12 MiB) copied, 0,016482 s, 755 MB/s
-rw-r--r--   1 freetz freetz 12451840 Aug 13 17:52 before_vector
freetz@freetz:~/freetz-ng$ hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 before_vector
00bdffc0  8c f8 06 01 b3 eb a2 c7  ed e5 a3 fb d4 09 2b be  |..............+.|
00bdffd0  a0 04 f7 4a e9 35 02 6e  43 57 db ff f6 4e 28 ac  |...J.5.nCW...N(.|
00bdffe0  58 cd 9b f7 08 46 8d 42  58 d5 d1 eb e2 2e 33 21  |X....F.BX.....3!|
00bdfff0  44 f3 2e e5 91 55 b2 d2  3d 35 30 19 37 fa 0e 4e  |D....U..=50.7..N|
00be0000
freetz@freetz:~/freetz-ng$ hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 alien_without_nmi_vector.image
00bdffc0  8c f8 06 01 b3 eb a2 c7  ed e5 a3 fb d4 09 2b be  |..............+.|
00bdffd0  a0 04 f7 4a e9 35 02 6e  43 57 db ff f6 4e 28 ac  |...J.5.nCW...N(.|
00bdffe0  58 cd 9b f7 08 46 8d 42  58 d5 d1 eb e2 2e 33 21  |X....F.BX.....3!|
00bdfff0  44 f3 2e e5 91 55 b2 d2  3d 35 30 19 37 fa 0e 4e  |D....U..=50.7..N|
00be0000  42 30 83 ed fc f9 06 1e  0c e6 05 3c e9 8e f3 1a  |B0.........<....|
00be0010  8b ca 42 b3 44 7e c6 35  1a 75 ae ee 19 e5 c8 b7  |..B.D~.5.u......|
00be0020  c2 ba 07 2e ed e9 b3 cd  e5 b8 28 b6 55 6d c7 dc  |..........(.Um..|
00be0030  7a d6 8e e1 84 2f 16 5a  03 13 f6 65 6c 7e 2a 2d  |z..../.Z...el~*-|
00be0040
freetz@freetz:~/freetz-ng$ cat before_vector nmi_vector >with_vector
freetz@freetz:~/freetz-ng$ hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 with_vector
00bdffc0  8c f8 06 01 b3 eb a2 c7  ed e5 a3 fb d4 09 2b be  |..............+.|
00bdffd0  a0 04 f7 4a e9 35 02 6e  43 57 db ff f6 4e 28 ac  |...J.5.nCW...N(.|
00bdffe0  58 cd 9b f7 08 46 8d 42  58 d5 d1 eb e2 2e 33 21  |X....F.BX.....3!|
00bdfff0  44 f3 2e e5 91 55 b2 d2  3d 35 30 19 37 fa 0e 4e  |D....U..=50.7..N|
00be0000  40 9a e8 05 40 9b e0 04  3c 1a 80 00 37 5a 03 80  |@...@...<...7Z..|
00be0010  8f 5b 00 0c 3b 7b de ad  14 1b 00 19 00 00 00 00  |.[..;{..........|
00be0020  40 1b e0 04 03 40 00 08  00 00 00 00 00 00 00 00  |@....@..........|
00be0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00be0040
freetz@freetz:~/freetz-ng$ dd if=alien_without_nmi_vector.image bs=$(( 0x10000 )) skip=$(( 0xBE )) >after_vector
31+1 records in
31+1 records out
2082304 bytes (2,1 MB, 2,0 MiB) copied, 0,00280718 s, 742 MB/s
freetz@freetz:~/freetz-ng$ hexdump -C -n64 after_vector
00000000  42 30 83 ed fc f9 06 1e  0c e6 05 3c e9 8e f3 1a  |B0.........<....|
00000010  8b ca 42 b3 44 7e c6 35  1a 75 ae ee 19 e5 c8 b7  |..B.D~.5.u......|
00000020  c2 ba 07 2e ed e9 b3 cd  e5 b8 28 b6 55 6d c7 dc  |..........(.Um..|
00000030  7a d6 8e e1 84 2f 16 5a  03 13 f6 65 6c 7e 2a 2d  |z..../.Z...el~*-|
00000040
freetz@freetz:~/freetz-ng$ cat with_vector after_vector > alien_with_nmi_vector.image
freetz@freetz:~/freetz-ng$ hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 alien_without_nmi_vector.image
00bdffc0  8c f8 06 01 b3 eb a2 c7  ed e5 a3 fb d4 09 2b be  |..............+.|
00bdffd0  a0 04 f7 4a e9 35 02 6e  43 57 db ff f6 4e 28 ac  |...J.5.nCW...N(.|
00bdffe0  58 cd 9b f7 08 46 8d 42  58 d5 d1 eb e2 2e 33 21  |X....F.BX.....3!|
00bdfff0  44 f3 2e e5 91 55 b2 d2  3d 35 30 19 37 fa 0e 4e  |D....U..=50.7..N|
00be0000  42 30 83 ed fc f9 06 1e  0c e6 05 3c e9 8e f3 1a  |B0.........<....|
00be0010  8b ca 42 b3 44 7e c6 35  1a 75 ae ee 19 e5 c8 b7  |..B.D~.5.u......|
00be0020  c2 ba 07 2e ed e9 b3 cd  e5 b8 28 b6 55 6d c7 dc  |..........(.Um..|
00be0030  7a d6 8e e1 84 2f 16 5a  03 13 f6 65 6c 7e 2a 2d  |z..../.Z...el~*-|
00be0040
freetz@freetz:~/freetz-ng$ hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 alien_with_nmi_vector.image
00bdffc0  8c f8 06 01 b3 eb a2 c7  ed e5 a3 fb d4 09 2b be  |..............+.|
00bdffd0  a0 04 f7 4a e9 35 02 6e  43 57 db ff f6 4e 28 ac  |...J.5.nCW...N(.|
00bdffe0  58 cd 9b f7 08 46 8d 42  58 d5 d1 eb e2 2e 33 21  |X....F.BX.....3!|
00bdfff0  44 f3 2e e5 91 55 b2 d2  3d 35 30 19 37 fa 0e 4e  |D....U..=50.7..N|
00be0000  40 9a e8 05 40 9b e0 04  3c 1a 80 00 37 5a 03 80  |@...@...<...7Z..|
00be0010  8f 5b 00 0c 3b 7b de ad  14 1b 00 19 00 00 00 00  |.[..;{..........|
00be0020  40 1b e0 04 03 40 00 08  00 00 00 00 00 00 00 00  |@....@..........|
00be0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00be0040
freetz@freetz:~/freetz-ng$ hexdump -C -s $(( 0xBE1000 - 64 )) -n 128 alien_with_nmi_vector.image
00be0fc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be1000  42 30 83 ed fc f9 06 1e  0c e6 05 3c e9 8e f3 1a  |B0.........<....|
00be1010  8b ca 42 b3 44 7e c6 35  1a 75 ae ee 19 e5 c8 b7  |..B.D~.5.u......|
00be1020  c2 ba 07 2e ed e9 b3 cd  e5 b8 28 b6 55 6d c7 dc  |..........(.Um..|
00be1030  7a d6 8e e1 84 2f 16 5a  03 13 f6 65 6c 7e 2a 2d  |z..../.Z...el~*-|
00be1040

The same kernel panic.

 

[baribal]

Sorry, but it was extracted too late. It doesn't contain the first 0.5 seconds ... and that's the important(!) time, when kernel setup occurs. If you start your session earlier (if it's possible -> try it, when the WLAN LED starts to blink the first time), you should be able to catch even the earliest messages - if this will not work, you may/should add a line to some initialization script (e.g. /etc/init.d/rc.net), which runs early and saves the first part of kernel messages to a file under /var/tmp (dmesg > /var/tmp/kernel.messages.part1).

Ok, thx for the hint. Please find the data attached.

 

[PeterPawn]

I didn't expect any other outcome really - at least not yet. There were two high-priority tasks - to get with the own image as near as possible to the original one (now with NMI vector) and to provide a telnet shell access ... no matter, which init approach (rc.S vs. systemd) is used. Are they solved or not? I can't say this for sure - it's your turn.

And I would suggest, that you create some scripts yourself (and for your own usage), which automate the steps needed.

I would see the following tasks able to be automated:

• extracting the ./var/tmp/kernel.image from AVM's firmware archive
• splitting the kernel into the three pieces (kernel, filesystem, NMI vector table)
• unpacking the filesystem, applying the patches needed for telnet daemon
• packing the filesystem again
• combining the three parts to an "alien image"
• unpacking the kernel
• packing the kernel

All of those are tasks, you've to run over and over again - I think, we have passed at most a half of the way yet. If you may reproduce results by simply calling a script, it's much easier to break up from earlier (intermediate) results - this can highly reduce the possibility to mix-up results.

And such a mess is rising at the horizon - at least that's my impression. To grasp, which attachment from your posts carries which version, isn't as easy. And if you got the support data from any version, AFTER a previous kernel crash, it contains further info, which may confuse a reader additionally. To explain this based on an example ... if you download this file:https://www.ip-phone-forum.de/attac...er-dvb-c-133-07-01_01-01-70_0101-txt.112837// it's - according to the head lines of the file - a support data file from FRITZ!OS version 07.01 for the DVB-C repeater.

Nevertheless we may find the line:

[    0.000000] [fw-info] Version 07.27

(at line 9606)
- but it's from the panic log of the last attempt with a 07.27 image. That's confusing - at least for me. And it's an "information overload" ... the only info needed yet, are the boot protocols for three (or four) firmware versions.

OK, I'll finish this post here - without further editing to remove any claim, which was superseded by #86. I'll wait for further new files now - but not without to repeat my questions regarding the persistent changes to HWRevision. I don't know yet, whether one of the new files covers the answer already.

---

At the end I want to get the boot log files (from second 0 to at least the point, where the USB initialization was finished - because the DVB-C repeater has some hardware attached (internally) by USB) for the following combinations:

• DVB-C repeater with firmware version 07.08 - to know, how the hardware has to be initialized
• optionally(!) the same as above, but for version 07.01 - but that's not really necessary, only as an encore for further comparisons
• DVB-C repeater with original 07.27 firmware for 1750E devices - to know, how the hardware is initialized with a wrong or not fully suitable configuration
• DVB-C repeater with original 07.27 firmware for 1750E devices, but with a patched avm_kernel_config area - to see the differences with a better suitable (hopefully at least) configuration
• the latter two logs one more time, but with a HWRevision set to 205 (if it's possible to set this with effects to the booting system) - to see, whether changes to this value (and/or filesystem content) have any gain

I know, that the version with the patched avm_kernel_config area keeps crashing, before the USB initialization was completed - here the approach with installing another system and extracting the boot log from previous panic log has to be used. But here isn't the whole support data file needed, too - only the content of the mentioned panic log is usable, because all further info isn't from the former crash, but from the running system (and this may produce further confusion).

I'll stay back now, until the requested files are collected (I didn't look, if there was any right one yet in #86) - and please attach them (with proper and simply recognizable names) to one single post - so it's not necessary to scroll up and down to find them all and at the same time this assures, that only the latest versions are published and read.

And please don't grasp this as an offense/attack ... but it's not expedient, if we both are working/reading/writing in parallel. Quite the contrary - you got my respect, that you didn't surrender and keep trying. That's the reason, too, why I would keep going - up to a (positive) result or to a (still possible) complete failing.

 

[PeterPawn]

@baribal:
Please provide to me (again? I'm not sure.) a version of the avm_kernel_config area extracted from DVB-C's firmware version 07.01 - I think it's necessary (soon) to de-compile the contained FDT to be able to compare it with others. A 07.08 firmware I've got myself - and 1750E's version 07.27 is still downloadable (and I got it already, too).

 

[baribal]

the latter two logs one more time, but with a HWRevision set to 205 (if it's possible to set this with effects to the booting system) - to see, whether changes to this value (and/or filesystem content) have any gain

It's a bit overwhelming for me all the above requirements but could you please explain how can I do it? I mean set the HW revision:

filesystem//etc/init.d/rc.conf | grep 206
export CONFIG_PRODUKT="Fritz_Box_HW206"

Is it the above? But if the FS is not initialized yet then we don't need it?

 

[baribal]

Please provide to me (again? I'm not sure.) a version of the avm_kernel_config area extracted from DVB-C's firmware version 07.01

Please find it attached.

 

[PeterPawn]

It's a bit overwhelming for me all the above requirements

OK, doesn't matter. I may explain it further.

The urlader environment value HWRevision may be changed by two manners - either from the running system using a shell session or from a FTP client connected to EVA. Using EVA you may run a command QUOTE SETENV HWRevision 206 (the needs to use a QUOTE depend on the used command to connect) - this changes the values at least up to the next reboot. But it may happen, that any changes to this value get abandoned at the next EVA start - then the former value will revived again. That was covered by the question, whether made changes are persistent or not.

From the running system, this urlader environment is exposed by a procfs implementation - the path name used is /proc/sys/urlader/environment. You may read the whole file (and extract any names and values) - e.g. using sed or cat (to show the whole (virtual) file). To change any value, you have to write a line with name and value (delimited by space or tab) to this file: printf "HWRevision %s\n" "205" > /proc/sys/urlader/environment - don't hesitate to verify your changes reading the file again. If the changes are permanent, the value remains changed after next reboot - otherwise if will be reset on each new start.

Other options to change this value permanently aren't of any interest yet - or better: I don't know any other option to change the value for kernel already, only to patch the boot-loader data area - that's nothing we should consider as long as any "native" firmware has to be run on the device.

EDIT: And I'm too tired now ... I'll continue tomorrow (or today, 'cause it's 12:10 AM again).

 

[PeterPawn]

As for nmi the below command didn't work for me

Reading backwards, I've found this claim assertion - and looked further.

My example shows a continuation of the first line (the backslash at end of line) and the "greater than" sign came from the "continuation prompt". You've copied it together with the other text and therefore something weird occured (with a redirection of "nothing"? It should show at least an error message.) instead of writing the content of nmi_vector to STDOUT pipe:

[...] ; > cat nmi_vector; [...]

Remove the "greater than" sign and it should work as expected.

 

[baribal]

@PeterPawn

I created the two new dmesg logs as you requested. However I am not sure how to boot the device with the HWRevision set via EVA. I used the following process:

telnet 192.168.178.1 21
USER adam2
331 Password required for adam2
PASS adam2
SETENV HWRevision 205

So I got the success 200 code. But what should I do now? Afaiu I need to exit FTP mode now so the device can continue the boot process. When I enter QUIT command I am out of the telnet session but device stays inside the FTP mode.

EDIT: I insert the output of the dmesg command also inside the 7.01 firmware rc.net file like with other firmware but results are not stable. I couldn't not get the 0sec dmesg logs while testing on ~10 reboots. Each time "/var/tmp/kernel.messages.part1" has the offset higher than 0sec. I attached the best result I could find in "/var/tmp/kernel.messages.part1". Please find also the latest kernel panic log from the alien firmware which has the nmi vector patched. The same kernel panic while accessing some memory address and some issues with ar8033 LAN adapter.

 

[PeterPawn]

Issue a REBOOT command to EVA from your FTP connection. But be sure, a runnable firmware is installed, so you may extract support data some times later. In the urlader environment (it's the first section from support data) you may verify, which value for HWRevision was used. If this isn't your changed one, permanent changes aren't possible and we have to reject the idea, to make kernel assume it's running on a 206 hardware.

And by the way - you may verify the value of a variable (from a FTP session, but a telnet session to port 21 is perfect, too, in some aspects even better) using a GETENV name command.

 

[baribal]

@PeterPawn

I've checked the original (non-patched) 1750E firmware and it shows HWRevision 205 out of the box:

# cat /proc/sys/urlader/environment
HWRevision      205
HWSubRevision   2
ProductID       Fritz_Box_HW205
SerialNumber    0000000000000000
annex   Ohne
autoload        yes
bootloaderVersion       1.2349
bootserport     tty0
cpufrequency    720000000
crash   [0]3fd3877f,5d,6[1]0,0,0[2]58259de,6114fd97,3[3]0,0,0
firstfreeaddress        0x821403CC
firmware_info   134.07.27
firmware_version        avm
flashsize       nor_size=0 sflash_size=16MB nand_size=0MB
maca    5C:49:79:4F:A8:8E
macb    5C:49:79:4F:A8:8F
macwlan 5C:49:79:4F:A8:90
macwlan2        5C:49:79:4F:A8:91
macdsl  5C:49:79:4F:A8:92
memsize 0x04000000
modetty0        38400,n,8,1,hw
modetty1        38400,n,8,1,hw
mtd0    0x9F000000,0x9F000000
mtd1    0x9F020000,0x9FF00000
mtd2    0x9F000000,0x9F020000
mtd3    0x9FF00000,0x9FF80000
mtd4    0x9FF80000,0xA0000000
my_ipaddress    192.168.178.1
prompt  Eva_AVM
req_fullrate_freq       200000000
sysfrequency    200000000
urlader-version 3349
usb_board_mac   5C:49:79:4F:A8:93
usb_device_id   0x0000
usb_device_name USB DSL Device
usb_manufacturer_name   AVM
usb_revision_id 0x0000
usb_rndis_mac   5C:49:79:4F:A8:94
wlan_key        25423571508073222877

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
GETENV HWRevision
HWRevision            205

200 GETENV command successful

 

[PeterPawn]

it shows HWRevision 205 out of the box

Another misunderstanding?

This value doesn't COME FROM the installed firmware, it's stored in the device (somewhere in the bootloader configuration area). No matter, which firmware you install, it doesn't CHANGE - at least not due to a different firmware.

The DVB-C repeater has a HWRevision value of 205, the 1750E repeater uses 206. Too fool the kernel(!) already, that it's running on a device with HWRevision 206 (for which the 07.27 version of 1750E's firmware was built), the HWRevision value of your device has to be set to 206 ... and cross your fingers, that this setting can be changed persistently. That's the question to answer - and only if the answer is: "Yes, my changes are permanent, even after a Power-Off reboot.", the aforementioned boot logs (the two from the last point of my list) make any sense.

 

[baribal]

@PeterPawn

1750E-original-non-patched:

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
GETENV HWRevision
HWRevision            205

200 GETENV command successful
SETENV HWRevision 206
200 SETENV command successful
GETENV HWRevision
HWRevision            206

200 GETENV command successful
REBOOT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

After reboot:

# cat /proc/sys/urlader/environment
HWRevision      205
HWSubRevision   2
ProductID       Fritz_Box_HW205

EDIT: I also tried to change the value via "/proc/sys/urlader/environment". This also doesn't survive the reboot.

 

[PeterPawn]

OK, permanent changes aren't possible obviously. So the option, to change HWRevision of device to 206 to circumvent any problems with HWRev 205 not found, isn't one any longer.

Time for further ideas ... the next problem to solve will be the failure while attempting to activate the LAN interface. But to compare the boot logs and to find the differences, we still need at least three boot logs - the 1st, 3rd and 4th from my list above ... and please all together as attachments to one SINGLE post (you may remove them from others, I you want to save space and to reduce (possible) confusions) to make it easier to find them.

I'll look for an opportunity to "decompile" the binary format of a DTS meanwhile - as one approach to compare the contents of (F)DTs.

If you want to check something (beside collecting possibly missing boot logs), you may extract the content of /sys/firmware from DVB-C repeater with all (or any) of the usable firmware variants (07.01, 07.08, 07.27 unmodified). Version 07.01 should contain it already - it uses a kernel version 4, too. Here the content of the device tree will be exposed in a structured form (and with a copy of the FDT), which is better suitable for comparisons of the content. I've added an example from my 7580, containing a list of the (virtual) files, as attachment to this post (it's too large otherwise).

If you pack this structure (using your shell access) with tar (include the FDT copy as well), you may export this archive (try to use the ftpput applet from BusyBox - your repeater does not support other NAS functions/servers) and extract data on any other system, beside the same data from other firmware versions, to use a recursive diff for finding differences.

Using the standard tools (like cat or sed) to handle this data takes some additional measures - data is stored here mostly as NUL-terminated string, even for (rather rare) lists. It's more or less the same, as with the process data exposed from /proc/self, where most data uses this format, too, e.g. the environ pseudo-file.

Comparisons of those data may help to see, why there're differences in FDT data between 07.01 and 07.08 - if this is only to a different order of source data in the DTS file (and a different order of "sections" in the FDT), we haven't to think about this anymore.

 

[baribal]

@PeterPawn

I updated the #93 with the all logs I could get.

Thx, I will try to extract this /sys/firmware content. But I want emphasize that I tried to use 7.01 FTD as well see #79 if you have missed, just in case.

 

[baribal]

If you want to check something (beside collecting possibly missing boot logs), you may extract the content of /sys/firmware from DVB-C repeater with all (or any) of the usable firmware variants (07.01, 07.08, 07.27 unmodified)

Please find attached.