[Sammlung] Änderungen in der Labor-Version 06.35/06.36 der 7490

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,275
Punkte für Reaktionen
1,751
Punkte
113
Changes:

02.07.15 04:08
Die Aussage zum "losetup" stimmt nicht ... die originale Firmware enthält /sbin/losetup, mit dem das demonstrierte Mounten mit Offset möglich ist.

Original starts here ...

Ich mache hier mal ein Thema zur o.a. Version auf, da die Änderungen "unter der Haube" die meisten sicherlich eher nicht interessieren. Daher will ich hier die festgestellten Unterschiede der neuen Version (das GUI ignoriere ich, das gehört ja eher zur "Lackierung" als "unter die Haube") zusammenfassen, soweit sie für die Modifikation wichtig sein könnten ... daher sind hier auch Punkte aus dem Firmware-Thread noch einmal aufgeführt.

1. Die Datei "filesystem.image" ist - trotz passender Signatur in den ersten vier Byte - kein SquashFS-Image. Es handelt sich um ein ext2-Image mit einem zusätzlichen Dummy-Header von 256 Byte Länge, der eigentlich nur die SquashFS-Signatur simuliert. Um an die Daten zu kommen, ist also dieses Image mit einer Verschiebung von 256 Byte zu mounten (z.B. mit der offset-Option beim losetup, wenn man die "unaligned"-Warnung ignoriert), AVM kopiert das Image mit "dd" und einer Blocksize von 256 unter Auslassen des ersten Blocks, das braucht aber eben - zumindest temporär - praktisch den doppelten Platz. Will man nur an den Inhalt des ext2-FS gelangen und hat eine Busybox mit "losetup" ein Image mit "losetup", funktioniert z.B. dieses:
Code:
root@FB7490:/var/media/ftp/images $ losetup -o 256 -r -v /dev/loop1 filesystem.image
losetup: filesystem.image: warning: file does not fit into a 512-byte sector the end of the file will be ignored.
root@FB7490:/var/media/ftp/images $ mount /dev/loop1 /var/0635
root@FB7490:/var/media/ftp/images $ mount | grep loop
/dev/loop0 on / type squashfs (ro,relatime)
/dev/loop1 on /var/0635 type ext2 (ro,relatime)
root@FB7490:/var/media/ftp/images $ ls -l /var/0635/
drwx------    2 root     root          1024 Jul  1 14:13 bin
drwx------    2 root     root          1024 Jul  1 14:13 core
drwx------    3 root     root          2048 Jul  1 14:13 dev
drwx------    2 root     root          1024 Jul  1 14:13 etc
-rw-------    1 root     root      19771392 Jul  1 14:13 filesystem_core.squashfs
drwx------    2 root     root          1024 Jul  1 14:13 lib
drwx------    2 root     root          1024 Jul  1 14:13 proc
drwx------    2 root     root          1024 Jul  1 14:13 sbin
drwx------    2 root     root          1024 Jul  1 14:13 tmp
drwx------    2 root     root          1024 Jul  1 14:13 var
Der Inhalt des Wrappers ist dann folgender:
Code:
root@FB7490:/var/0635 $ cd /var/0635
root@FB7490:/var/0635 $ find -exec ls -ld '{}' \;
drwxr-xr-x   11 root     root          1024 Jul  1 14:13 .
drwx------    2 root     root          1024 Jul  1 14:13 ./var
drwx------    2 root     root          1024 Jul  1 14:13 ./lib
-rwx------    1 root     root        701296 Jul  1 14:12 ./lib/libuClibc-0.9.33.2.so
-rwx------    1 root     root         31680 Jul  1 14:12 ./lib/ld-uClibc-0.9.33.2.so
lrwxrwxrwx    1 root     root            21 Jul  1 14:12 ./lib/libc.so.0 -> libuClibc-0.9.33.2.so
lrwxrwxrwx    1 root     root            21 Jul  1 14:12 ./lib/ld-uClibc.so.0 -> ld-uClibc-0.9.33.2.so
drwx------    2 root     root          1024 Jul  1 14:13 ./etc
-rw-------    1 root     root           412 Jul  1 14:13 ./etc/inittab
lrwxrwxrwx    1 root     root             9 Jul  1 14:13 ./etc/mtab -> /tmp/mtab
drwx------    2 root     root          1024 Jul  1 14:13 ./core
-rw-------    1 root     root      19771392 Jul  1 14:13 ./filesystem_core.squashfs
drwx------    3 root     root          2048 Jul  1 14:13 ./dev
drwx------    2 root     root          1024 Jul  1 14:13 ./dev/pts
crw-rw-rw-    1 root     root      136,   3 Jul  1 14:13 ./dev/pts/3
crw-rw-rw-    1 root     root      136,   5 Jul  1 14:13 ./dev/pts/5
crw-rw-rw-    1 root     root      136,   4 Jul  1 14:13 ./dev/pts/4
crw-rw-rw-    1 root     root      136,   7 Jul  1 14:13 ./dev/pts/7
crw-rw-rw-    1 root     root      136,   1 Jul  1 14:13 ./dev/pts/1
crw-rw-rw-    1 root     root      136,   6 Jul  1 14:13 ./dev/pts/6
crw-rw-rw-    1 root     root      136,   0 Jul  1 14:13 ./dev/pts/0
crw-rw-rw-    1 root     root      136,   2 Jul  1 14:13 ./dev/pts/2
lrwxrwxrwx    1 root     root            19 Jul  1 14:12 ./dev/kdsld_misc -> /var/dev/kdsld_misc
lrwxrwxrwx    1 root     root             9 Jul  1 14:12 ./dev/new_led -> /dev/null
lrwxrwxrwx    1 root     root            10 Jul  1 14:12 ./dev/log -> ../tmp/log
crw-rw-rw-    1 root     root       90,  26 Jul  1 14:13 ./dev/mtd13
crw-rw-rw-    1 root     root       90,  18 Jul  1 14:13 ./dev/mtd9
crw-rw-rw-    1 root     root        1,  11 Jul  1 14:13 ./dev/kmsg
crw-rw-rw-    1 root     root       90,   8 Jul  1 14:13 ./dev/mtd4
crw-rw-rw-    1 root     root        1,   2 Jul  1 14:13 ./dev/kmem
crw-rw-rw-    1 root     root      255, 163 Jul  1 14:13 ./dev/avm_net_trace163
crw-rw-rw-    1 root     root       90,  16 Jul  1 14:13 ./dev/mtd8
crw-rw-rw-    1 root     root       90,  12 Jul  1 14:13 ./dev/mtd6
crw-rw-rw-    1 root     root      255, 141 Jul  1 14:13 ./dev/avm_net_trace141
crw-rw-rw-    1 root     root      255, 140 Jul  1 14:13 ./dev/avm_net_trace140
crw-rw-rw-    1 root     root        1,   3 Jul  1 14:13 ./dev/null
crw-rw-rw-    1 root     root       90,  20 Jul  1 14:13 ./dev/mtd10
crw-rw-rw-    1 root     root        3,   2 Jul  1 14:13 ./dev/ttyp2
crw-rw-rw-    1 root     root        1,   1 Jul  1 14:13 ./dev/mem
crw-rw-rw-    1 root     root       90,  30 Jul  1 14:13 ./dev/mtd15
crw-rw-rw-    1 root     root        1,   8 Jul  1 14:13 ./dev/random
crw-rw-rw-    1 root     root      255, 161 Jul  1 14:13 ./dev/avm_net_trace161
crw-rw-rw-    1 root     root       90,  10 Jul  1 14:13 ./dev/mtd5
crw-rw-rw-    1 root     root      255, 142 Jul  1 14:13 ./dev/avm_net_trace142
crw-rw-rw-    1 root     root        4,  64 Jul  1 14:13 ./dev/ttyS0
crw-rw-rw-    1 root     root      255, 132 Jul  1 14:13 ./dev/avm_net_trace132
crw-rw-rw-    1 root     root        3,   0 Jul  1 14:13 ./dev/ttyp0
crw-rw-rw-    1 root     root      255, 162 Jul  1 14:13 ./dev/avm_net_trace162
crw-rw-rw-    1 root     root      255, 160 Jul  1 14:13 ./dev/avm_net_trace160
crw-rw-rw-    1 root     root      255, 139 Jul  1 14:13 ./dev/avm_net_trace139
crw-rw-rw-    1 root     root       90,   6 Jul  1 14:13 ./dev/mtd3
crw-rw-rw-    1 root     root       90,  24 Jul  1 14:13 ./dev/mtd12
crw-rw-rw-    1 root     root       90,  14 Jul  1 14:13 ./dev/mtd7
crw-rw-rw-    1 root     root      255, 131 Jul  1 14:13 ./dev/avm_net_trace131
crw-rw-rw-    1 root     root        5,   0 Jul  1 14:13 ./dev/tty
crw-rw-rw-    1 root     root        5,   1 Jul  1 14:13 ./dev/console
crw-rw-rw-    1 root     root        5,   2 Jul  1 14:13 ./dev/ptmx
crw-rw-rw-    1 root     root      255,   0 Jul  1 14:13 ./dev/avm_net_trace0
crw-rw-rw-    1 root     root       90,   4 Jul  1 14:13 ./dev/mtd2
crw-rw-rw-    1 root     root      247,   0 Jul  1 14:13 ./dev/led
crw-rw-rw-    1 root     root      255, 129 Jul  1 14:13 ./dev/avm_net_trace129
crw-rw-rw-    1 root     root        1,   5 Jul  1 14:13 ./dev/zero
crw-rw-rw-    1 root     root      255, 130 Jul  1 14:13 ./dev/avm_net_trace130
crw-rw-rw-    1 root     root       90,   0 Jul  1 14:13 ./dev/mtd0
crw-rw-rw-    1 root     root      255, 134 Jul  1 14:13 ./dev/avm_net_trace134
cr--r--r--    1 root     root      230,   0 Jul  1 14:13 ./dev/tiatm
crw-rw-rw-    1 root     root        1,   9 Jul  1 14:13 ./dev/urandom
crw-rw-rw-    1 root     root      255, 137 Jul  1 14:13 ./dev/avm_net_trace137
crw-rw-rw-    1 root     root      255, 128 Jul  1 14:13 ./dev/avm_net_trace128
crw-rw-rw-    1 root     root        3,   1 Jul  1 14:13 ./dev/ttyp1
crw-rw-rw-    1 root     root      255, 135 Jul  1 14:13 ./dev/avm_net_trace135
crw-rw-rw-    1 root     root       90,  28 Jul  1 14:13 ./dev/mtd14
crw-rw-rw-    1 root     root      255, 136 Jul  1 14:13 ./dev/avm_net_trace136
crw-rw-rw-    1 root     root      255, 143 Jul  1 14:13 ./dev/avm_net_trace143
crw-rw-rw-    1 root     root       90,   2 Jul  1 14:13 ./dev/mtd1
crw-rw-rw-    1 root     root      255, 138 Jul  1 14:13 ./dev/avm_net_trace138
crw-rw-rw-    1 root     root      255, 133 Jul  1 14:13 ./dev/avm_net_trace133
crw-rw-rw-    1 root     root        4,   0 Jul  1 14:13 ./dev/tty0
crw-rw-rw-    1 root     root       90,  22 Jul  1 14:13 ./dev/mtd11
crw-rw-rw-    1 root     root        4,  65 Jul  1 14:13 ./dev/ttyS1
brw-rw-rw-    1 root     root       31,  14 Jul  1 14:13 ./dev/mtdblock14
brw-rw-rw-    1 root     root        7,   6 Jul  1 14:13 ./dev/loop6
brw-rw-rw-    1 root     root       31,   5 Jul  1 14:13 ./dev/mtdblock5
brw-rw-rw-    1 root     root       31,   2 Jul  1 14:13 ./dev/mtdblock2
brw-rw-rw-    1 root     root       31,   7 Jul  1 14:13 ./dev/mtdblock7
brw-rw-rw-    1 root     root        7,   2 Jul  1 14:13 ./dev/loop2
brw-rw-rw-    1 root     root       31,  15 Jul  1 14:13 ./dev/mtdblock15
brw-rw-rw-    1 root     root       31,   8 Jul  1 14:13 ./dev/mtdblock8
brw-rw-rw-    1 root     root        7,   7 Jul  1 14:13 ./dev/loop7
brw-rw-rw-    1 root     root        7,   5 Jul  1 14:13 ./dev/loop5
brw-rw-rw-    1 root     root       31,  13 Jul  1 14:13 ./dev/mtdblock13
brw-rw-rw-    1 root     root       31,   4 Jul  1 14:13 ./dev/mtdblock4
brw-rw-rw-    1 root     root        7,   0 Jul  1 14:13 ./dev/loop0
brw-rw-rw-    1 root     root       31,   9 Jul  1 14:13 ./dev/mtdblock9
brw-rw-rw-    1 root     root       31,  10 Jul  1 14:13 ./dev/mtdblock10
brw-rw-rw-    1 root     root       31,   0 Jul  1 14:13 ./dev/mtdblock0
brw-rw-rw-    1 root     root        7,   4 Jul  1 14:13 ./dev/loop4
brw-rw-rw-    1 root     root       31,   6 Jul  1 14:13 ./dev/mtdblock6
brw-rw-rw-    1 root     root       31,   3 Jul  1 14:13 ./dev/mtdblock3
brw-rw-rw-    1 root     root       31,  11 Jul  1 14:13 ./dev/mtdblock11
brw-rw-rw-    1 root     root        7,   3 Jul  1 14:13 ./dev/loop3
brw-rw-rw-    1 root     root       31,  12 Jul  1 14:13 ./dev/mtdblock12
brw-rw-rw-    1 root     root       31,   1 Jul  1 14:13 ./dev/mtdblock1
brw-rw-rw-    1 root     root        7,   1 Jul  1 14:13 ./dev/loop1
drwx------    2 root     root          1024 Jul  1 14:13 ./proc
drwx------    2 root     root          1024 Jul  1 14:13 ./sbin
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/ip -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/swapoff -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/pivot_root -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/modprobe -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/init -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/localize -> /sbin/eventadd
lrwxrwxrwx    1 root     root             8 Jul  1 14:13 ./sbin/ar7login_frominternet -> ar7login
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/iptunnel -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/switch_root -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/route -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/setconsole -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/ifconfig -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/swapon -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/insmod -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/iplink -> ../bin/busybox
lrwxrwxrwx    1 root     root            17 Jul  1 14:13 ./sbin/blkid -> ../usr/sbin/blkid
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/arp -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/rmmod -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/sysctl -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/vconfig -> ../bin/busybox
lrwxrwxrwx    1 root     root             4 Jul  1 14:13 ./sbin/dsltest -> dsld
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/ipaddr -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/halt -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/ifdown -> ../bin/busybox
-r-x------    1 root     root          6703 Jul  1 14:13 ./sbin/flash_update
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/iprule -> ../bin/busybox
lrwxrwxrwx    1 root     root            18 Jul  1 14:13 ./sbin/showaddrs -> /./sbin/showroutes
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/mkswap -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/lsmod -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/poweroff -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/ifup -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/reboot -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Jul  1 14:13 ./sbin/iproute -> ../bin/busybox
drwx------    2 root     root          1024 Jul  1 14:13 ./bin
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/false -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/ping6 -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/mv -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/ping -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/iostat -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/dd -> busybox
lrwxrwxrwx    1 root     root             9 Jul  1 14:13 ./bin/usermand -> usermand2
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/hostname -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/true -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/netstat -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/uname -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/nice -> busybox
-rwx------    1 root     root        452396 Jul  1 14:13 ./bin/busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/echo -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/sleep -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/mknod -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/mkdir -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/chown -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/printenv -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/mpstat -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/tar -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/mount -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/chgrp -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/pidof -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/gunzip -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/stty -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/zcat -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/egrep -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/umount -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/stat -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/login -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/getopt -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/ps -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/cat -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/dnsdomainname -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/cp -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/sed -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/date -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/pwd -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/touch -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/ash -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/sync -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/vi -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/chmod -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/setserial -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/df -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/gzip -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/ls -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/rmdir -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/rm -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/sh -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/kill -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/more -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/ln -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/grep -> busybox
lrwxrwxrwx    1 root     root             7 Jul  1 14:13 ./bin/fgrep -> busybox
drwx------    2 root     root          1024 Jul  1 14:13 ./tmp
-rw-------    1 root     root             0 Jul  1 14:13 ./tmp/mtab
Das ist - bis auf die fünf "orphaned links" - auch nichts Überraschendes, mit
Code:
root@FB7490:/var/0635 $ cp /var/0635/filesystem_core.squashfs /var/tmp/
root@FB7490:/var/0635 $ ls -l /var/tmp/filesystem_core.squashfs
-rw-------    1 root     root      19771392 Jul  1 19:46 /var/tmp/filesystem_core.squashfs
root@FB7490:/var/0635 $ cd /var/media/ftp/images
root@FB7490:/var/media/ftp/images $ umount /var/0635
root@FB7490:/var/media/ftp/images $ losetup -a
/dev/loop0: [7939]:513 (/filesystem_core.squashfs)
haben wir jetzt das Wurzeldateisystems für den Wirkbetrieb nach /var/tmp/filesystem_core.squashfs kopiert, auch ohne mit "dd" zu jonglieren.

Leider packt AVM selbst "losetup" nicht in die Busybox und so klappt das eben nur mit einer eigenen Busybox. Es ist eine Version von losetup unter dem Pfad /sbin/losetup auch in einem originalen AVM-Image vorhanden, sogar schon mindestens seit 06.20 - man sollte eben öfter mal in ein "pures AVM-Image" schauen. Zu meiner Entschuldigung kann ich nur anführen, daß AVM das util-linux-ng-Paket, aus dem das "losetup" stammt, eher etwas verschämt in einem File mit schon recht alten Busybox-Quellen (Name ist GPL-busybox.tar.gz, wo ich nun nicht auf Anhieb danach suchen würde) versteckt und die Busybox selbst ja eine eigene Version von "losetup" enthält. Diese kennt dann übrigens die oben verwendete Option "-v" gar nicht.

Wer im tmpfs noch ~22 MB für das Umkopieren des ext2-Images erübrigen kann, nimmt dann eben wie AVM "dd". Der Umweg über den NAND-Flash ist natürlich entsprechend lahm.

2. In der Datei "filesystem_core.squashfs" befindet sich jetzt kein SquashFS3-Image mehr ... wie bei der 6490 hat AVM auch hier den Übergang auf das SquashFS4-Format vollzogen, dabei jedoch eine eigene Spielart dieses Formats kreiert. Eigentlich gibt es bei SquashFS4 nur noch das LE-Format, AVM erfindet aber ein BE-Format neu. Mit dem bereits früher fertiggestellten Patch für SquashFS4 (Freetz-Ticket 2691) kann man das aber wenigstens untersuchen und auch entpacken:
Code:
:~/FritzBox/FB7490/0635 # ../../FB6490/tools/unsquashfs4_avm -s filesystem_core.squashfs
Reading a big endian SQUASHFS 4 filesystem on filesystem_core.squashfs
Found a valid SQUASHFS 4:0 superblock on filesystem_core.squashfs.
Creation or last append time Mon Aug 17 20:55:11 1970
Filesystem size 19307.53 Kbytes (18.86 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 254
Number of inodes 4098
Number of ids 1
:~/FritzBox/FB7490/0635 # ../../FB6490/tools/unsquashfs4_avm -d fs_0635 filesystem_core.squashfs
Reading a big endian SQUASHFS 4 filesystem on filesystem_core.squashfs
Parallel unsquashfs: Using 2 processors
3873 inodes (4425 blocks) to write

[=========================================================\] 4425/4425 100%

created 3257 files
created 225 directories
created 529 symlinks
created 87 devices
created 0 fifos
Die bitgenaue Übereinstimmung habe ich noch nicht geprüft, da ich das noch nicht installiert habe ... aber daß es sich ohne Fehlermeldung auspacken ließ (bei LZMA-Kompression), ist für mich schon mal ein gutes Zeichen.

3. Kernel-Version ist jetzt die 3.10.173.10.73 (so ein Unsinn, das kommt davon, wenn man auf mehreren Hochzeiten tanzt beim Schreiben) - das dürfte an einigen Stellen zusätzliche Möglichkeiten eröffnen (endlich), aber auch - zumindest am Anfang - einiges an Problemen bereiten, gerade für Freetz-"Kunden".

4. Es gibt einen neuen Symlink /lib32, der aber auf /lib verweist. Ob das jetzt die Schlußfolgerung zuläßt, daß es demnächst bei AVM auch Boxen mit 64-Bit-Architektur geben wird (und lib32 dann für Kompatibilitätslayer benötigt wird) ... da will ich mich noch nicht einmal im Rahmen einer Spekulation festlegen.

5. Die zwei Programme, die bisher die libudev benutzt haben (der udevd selbst und udevadm), sind gegen diese jetzt entweder statisch gelinkt (da die "stripped" sind, sieht man das nicht richtig) oder sie benötigen die libudev nicht mehr. Daher hat AVM diese konsequenterweise auch nicht ins Image aufgenommen, aber die (abstrakten) Links unter /lib existieren weiterhin und zeigen nur ins Leere. Wenn man also zusätzliche Software installieren will, die die libudev.so benötigt, muß man selbst für deren Anwesenheit sorgen.

Das war's erst einmal, ich ergänze das hier Stück für Stück, wenn ich etwas feststelle. Sollte jemand anderes etwas beitragen wollen ... tut Euch bitte keinen Zwang an.

EDIT: 15.07.2015
6. Der SquashFS-Treiber im Kernel kann mit älteren Images nichts mehr anfangen, das Mounten von anderen Formaten (SQFS3 mit GZIP oder auch SQFS3 mit LZMA - was die 7490 auch lesen konnte, selbst wenn sie ihrerseits "nur" GZIP verwendete bei AVM) ist - zumindest nach meinen bisherigen Tests - nicht möglich. Was ich noch nicht probiert habe, ist das Mounten von LE-Images auf der Box.
 
Zuletzt bearbeitet:
@eisbaerin:
Das ist noch weit jenseits meines aktuellen Horizontes ... diese Frage kann man ausschließlich theoretisch nicht (oder nur ungenau) beantworten und bis ich diese Version tatsächlich installiere, nehme ich sie erst einmal ausführlich unter die Lupe. Das dauert schon noch etwas ... mind. bis zum WE.
 
Ja, nur keine Hektik! Ich wollte nur schon mal gefragt haben ;)
 
Das Image wird zumindest akzeptiert...

Screenshot - 01.07.2015 , 22_28_03_ver001.jpg

Es scheinen also auch weiterhin unsignierte Dateien zu gehen.
 
Abend

Soweit es um die Rebrandingpseudoimages geht, bleibt es bis jetzt wie es ist.
Die Kunst bei temporären telnetd oder dropbear wird sein die Box in einen laufähigen Zustand zu bekommen.
So wie freetz das macht: Ohne Dienstebeendigung und ohne Neustart
 
So wie freetz das macht: Ohne Dienstebeendigung und ohne Neustart
Freetz lädt halt das Image selbst und entpackt es auch ... sowie da firmwarecfg ins Spiel kommt und "prepare_fwupgrade" aufgerufen wird, ist mit dem originalen Inhalt dieser Datei (fast) nichts zu machen. Ich packe in aller Regel dort noch eine Abfrage einer Semaphore hinein, die dann dieses teilweise Herunterfahren einfach durch Rücksprung abbricht - das ist ja ein Shell-Skript und somit gut zu modifizieren. Es muß eben schon in das System eingebaut werden, was bis zur 06.25 mit entsprechend präpariertem Filesystem sogar über EVA funktioniert(e). Wie sich das mit dem 3er-Kernel entwickelt (insb. wann man eine Konfiguration von AVM dafür erhält), muß man eben abwarten ...

Es versteht sich zwar von selbst und man sollte es nicht erwähnen müssen ... aber Freetz kann ein originales Labor-06.35-Update auch nicht selbst flashen. Im besten Fall gibt es eine Fehlermeldung ... ob ein schlechtester Fall möglich ist (bei einer NAND-Box), weiß ich gar nicht - ich würde es trotzdem nicht darauf anlegen.
 
So, nachdem nun die 06.35 auch mal live bei mir ihren ersten Auftritt hat (30804), noch ein paar zusätzliche "Eindrücke" beim Spazieren durch die "Innereien":

- es gibt unter /proc/avm/nandstat ein neues procfs-Interface, mit dem man den aktuellen Zustand des eigenen NAND-Speichers zumindest in etwas beurteilen kann:
Code:
root@FB7490:~ $ cat /proc/avm/nandstat
Measuring time: 25 min 29 s
write-pages (raw)          786
write-pages (ecc)          786 - from that corrected            0 uncorrectable            0
read-pages  (ecc)        11994 - from that corrected            0 uncorrectable            0
Solange da noch keine Schreib- und/oder Lesefehler auftauchen (auch keine korrigierbaren), kann man die Funktionsfähigkeit der Zellen unterstellen, ich gehe mal davon aus (ohne den Treiber gesehen zu haben), daß da auch Fehler in den OOB-Daten ersichtlich wären. Wie sich das mit den Fehlermeldungen bzgl. mtdblock5 verträgt:
Code:
<3>[   24.170000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x3f390)
<3>[   24.490000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x3e085)
<3>[   26.290000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x2521d)
<3>[   26.860000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x23c5a)
<3>[   28.080000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x13cfc)
<3>[   28.640000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x12719)
<3>[   29.030000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x11029)
<3>[   29.640000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0xd61d)
<3>[   31.860000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x174f0)
<3>[   33.880000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x18c97)
<3>[   35.800000][0][ifx_hsnand_command] read block is critical (column: 0x800 page: 0x117e2)
verrät wohl nur ein Blick in den Treiber-Quellcode, wenn die OSS-Quellen mal verfügbar sein werden.

- es gibt ein weiteres neues Interface unter "/proc/avm/log_(sd,cr)", wobei dort offenbar jeweils zwei "files" pro Typ (panic, crash) abgelegt werden, was ich bisher nur bei der 6490 mit den beiden unterschiedlichen Systemen und jeweils einem eigenen crash- und panic-Log gesehen habe
- ein Lesezugriff dort scheint auch das Löschen (irgendwie aber offenbar verzögert, denn zweimal konnte ich dort auslesen) des alten Protokolls zu bewirken, also vorsichtshalber immer speichern, wenn man es analysieren will

- ob es das Interface /proc/avm/performance_index bereits in einer vorhergehenden 2.6.32 basierten Version gab, weiß ich nicht genau, hier liefert es auf einer 7490:
Code:
root@FB7490:~ $ cat /proc/avm/performance_index
Performance-Index: 6441
CPU-Clock: 500 MHz
RAM-Clock: 500 MHz

- AES ist jetzt als Kernelmodule in den Kernel einkompiliert, keine Ahnung, seit wann das so ist

- neue procfs-Interfaces beim kdsld, u.a. für die Anzeige offener Ports und auch eines unter dem Namen "pcp44", ob da wirklich das "port control protocol" involviert ist, weiß ich noch nicht
- dafür sind die bisherigen Angaben unter /proc/kdsld/dsliface/internet/ipmasq/forwards nicht mehr (in vollem Umfang) vorhanden, nur die RTP-Ports des voidp tauchen da noch auf
- zwei neue "files" (dpfilter4/dpfilter6) sind noch ziemlich unklar:
Code:
root@FB7490:~ $ cat /proc/kdsld/dsliface/internet/dpfilter*/filterinfo
SIP: off, 0 pkts filtered
SMTP: off, 0 pkts filtered
SIP: off, 0 pkts filtered
SMTP: off, 0 pkts filtered
wenn das wirklich in die Richtung "deep packet analyzing" geht, dürfen wir sicherlich gespannt sein ... das wäre ja ein neuer Firewall-Ansatz

- ein Lese-Zugriff auf eines der procfs-Interfaces /proc/http_filter* ist nach wie vor ein sehr zuverlässiger Weg, einen prompten Neustart herbeizuführen ... u.a. deshalb sollte man sich auch "grep -r" u.ä. über das procfs verkneifen.
- für das neue(?) Interface /proc/pmcu (power management?) gilt analoges ... ich vermute mal eine "kernel panic", jedenfalls ist die Box relativ schnell (aber langsamer als bei http_filter*) beim Neustart zu beobachten -> ja, sauberer Zugriff auf Adresse "-1" bei einem strnlen-Aufruf :)

- gibt es das Interface /proc/tffs_stat schon vor der 06.35? Ist mir noch nie aufgefallen, dort werden offenbar die Zugriffe auf den TFFS-Flash protokolliert, einige komische IDs sind da (auch modulo 256) zu sehen :gruebel:

... das war der erste Eindruck vom /proc-Verzeichnis; mal sehen, was die 30889 zu bieten hat. Einige meiner eigenen Sachen laufen schon mal nicht automatisch an, da gibt es noch einiges zu tun. Ich schalte jetzt erst einmal auf die 06.25 zurück ... da sind noch zu viele offene Baustellen bei der 06.35.
 
da firmwarecfg ins Spiel kommt und "prepare_fwupgrade" aufgerufen wird, ist mit dem originalen Inhalt dieser Datei (fast) nichts zu machen. Ich packe in aller Regel dort noch eine Abfrage einer Semaphore hinein, die dann dieses teilweise Herunterfahren einfach durch Rücksprung abbricht

Hallo PeterPawn,
das mit dem "prepare_fwupgrade" und dem Skript mit Semaphore-Query klingt gut,

Könntest Du uns dieses Skript zur Verfügung stellen ?

ich denke es wird mit /var/install und "mount -o bind /var/media/ftp/USB-Stick/prepare_fwupgrade /bin/prepare_fwupgrade" aktiviert.

Gruß
Splenditnet
 
Eine solche Änderung erst nachträglich von /var/install aus per bind-Mount zu machen, ist logischerweise nicht sinnvoll ... zu diesem Zeitpunkt ist prepare_fwupgrade ja schon durch.

Was ich damit meinte (und irgendwo auch schon mal gezeigt habe), ist eine schon vorher ausgeführte Änderung der im SquashFS-Image enthaltenen Datei prepare_fwupgrade und da wird - analog zum "Anhängen" eigener Befehle an die /etc/profile in dem betreffenden Beispiel beim modfs - nichts weiter gemacht als eine Prüfung, ob eine bestimmte Datei existiert und ausführbar ist (was eigentlich bei dieser Art des Aufrufs nicht zwingend ist). Ist das der Fall, wird diese Datei (die im beschreibbaren Teil des Dateisystems liegt) per "source"-Kommando der Shell ausgeführt im Rahmen von prepare_fwupgrade. Durch diese Art des "Aufrufs" bewirkt auch ein dort ausgeführtes "exit" einen Abbruch der Verarbeitung der prepare_fwupgrade.

Das sieht also in der fertigen prepare_fwupgrade einfach nur so aus:
Code:
#! /bin/sh
. /etc/term.sh
[COLOR="#FF0000"]custom=/var/media/ftp/custom/upgrade_hook
[ -x $custom ] && . $custom
[/COLOR]PATH=/bin:/usr/bin:/sbin:/usr/sbin
term_usb()
{
Diese Änderung - neben einigen weiteren "Hooks", um bei Bedarf eigenen Skript-Code in die Stock-Firmware einbauen zu können - wird an einem ausgepackten root-Filesystem der Firmware vorgenommen und dieses hinterher wieder zusammengepackt und in die richtige Partition übertragen.

Wie weiter vorne geschrieben, ist der "profile"-Hook als Beispielanwendung für modfs auch nur eine etwas abgewandelte Änderung, die statt im NAND-Flash (unter /var/media/ftp) nach den Anpassungen zu suchen, unter /var/custom nachschaut. Bei den von mir ausschließlich bei Kunden verwendeten Modellen 7390 und 7490 ist der NAND-Flash als persistenter Speicher immer vorhanden ist, bei anderen von modfs unterstützten Modellen (mit 128 MB Flash gesamt) war/bin ich da nicht so sicher, daher muß man dann eben dafür sorgen, daß irgendetwas sinnvolles unter /var/custom gemountet wird, wenn man diese Hooks verwenden will.

Bei NAND-Modellen ist das per modfs für jeden machbar (das müßte dann eben auf die Unterstützung fehlender Modelle nach entsprechendem Test erweitert werden), bei NOR-Modellen will ich die entsprechende modfs-Erweiterung noch nicht herausrücken, weil der Flash-Vorgang nicht mal eben so zum Spaß möglich ist (bei NAND-Modellen ist "undo" möglich, solange man nicht neu gestartet hat) und nach den jüngsten Änderungen in Freetz sollte auch jeder selbst sich das passende mksquashfs für Version 3 mit LZMA-Komprimierung übersetzen können (wenn ich das richtig gesehen habe im Journal).
 
wird an einem ausgepackten root-Filesystem der Firmware vorgenommen und dieses hinterher wieder zusammengepackt und in die richtige Partition übertragen.

Frage: Gibt es hier keine Probleme FW-Signatur-Verification beim Übertragen/Einspielen per GUI-Update dieser modifizierten Stock-Firmware Image-Datei ?

oder muß hier zusätzlich noch was unternommen werden ?

Gruß
Splenditnet
 
Frage: Gibt es hier keine Probleme FW-Signatur-Verification beim Übertragen/Einspielen per GUI-Update dieser modifizierten Stock-Firmware Image-Datei ?
oder muß hier zusätzlich noch was unternommen werden ?
Kommt ganz drauf an ... wenn man das extern zur FRITZ!Box macht und diese modifizierte Datei dann (wie ein Freetz-Image) über das AVM-GUI einspielen will, mault die AVM-Firmware die fehlende/falsche Signatur an, läßt aber die Installation (von lokal) trotzdem noch zu (nach Berichten anderer, habe ich selbst schon lange nicht mehr so gemacht).

Ich modifiziere ohnehin direkt auf der FRITZ!Box selbst, da spielt die Signaturprüfung keine Rolle mehr, weil die nur beim Flashen (genauer beim Auspacken der "image"-Datei durch firmwarecfg) und nicht bei jedem Start des Systems erfolgt.
 
Leider läuft das Freetz noch nicht mit dieser Firmware.
Kann man den Callmonitor in diesem Image einbinden ?
 
Ein paar neuere Punkte, die mir erst in letzter Zeit in der neuen Firmware aufgefallen sind, aber durchaus auch schon länger existieren können:

1. Es gibt ein neues internes Kommando "tcppeerlocation", mit dem man anhand der eigenen Adresse und des eigenen Ports in Kombination mit einer (FRITZ!Box-)externen IP-Adresse und einem Port ermitteln kann, ob die Box diese Verbindung als intern (exitcode 1) oder "internet" (exitcode 2) ansieht - etwas für die Bastler, mit dem man eben bestimmen kann, ob die Box z.B. eine Anmeldung mit Namen und Passwort oder nur mit dem Kennwort erlauben wird von der angegebenen Adresse.

2. "/bin/boxfeaturedisable" (keine Ahnung, ob das außerhalb der DOCSIS-Modelle überhaupt benutzt wird, in der 7490 offenbar nicht) kennt jetzt einen neuen Parameter "--tr069", der einen Neustart bei Differenzen zwischen dem alten Inhalt der "featovl.cfg" und dem gewünschten neuen Inhalt verhindert - irgendjemand hier hatte auch mit der featovl.cfg bei den DSL-Modellen mal experimentiert, um die CONFIG-Variablen zu verändern ohne die Firmware zu modifizieren.

3. Für die hier schon diskutierte rote LED, die dauerhaft leuchtet, gibt es neue Events für "led-ctrl" (früher gab es nur "filesystem_mount_failure" für hektisches rotes Blinken) ... die neuen heißen jetzt "message_warning_{high,medium,low}_priority" und können offenbar nicht wie üblich mit dem Zusatz "=0" wieder abgeschaltet werden, dafür gibt es zusätzlich "message_warning_off". Alle drei "on"-Events schalten im Moment auf der 7490 auch nur dasselbe Dauerleuchten der roten LED an ... unabhängig von der Priorität.

4. /bin/lsblk ist ersatzlos weggefallen ... für die meisten sicherlich bedeutungslos, aber ein weiteres "fehlendes Kommando", wenn man eigene Skripte laufen lassen will.

5. Den Wegfall der Abarbeitung von Skripts unter /var/tmp/onlinechanged hatte ich vermutlich vorher schon irgendwo mal erwähnt - ist aber auch eine zu beachtende Änderung ggü. der letzten Release-Version für die Bastler; ein weiterer Hook ist damit entfallen seit der 06.30.

6. Wer bisher auf irgendeinem Weg die APIPA-Adresse 169.254.1.1 nach einer gewissen Zeit oder gar von Beginn an ständig deaktiviert hat, könnte damit jetzt auf Probleme stoßen ... eine interne Komponente (boxnotifyd) benutzt diese Adresse für ein TCP-"listen". Mit dieser Komponente werden diese "Benachrichtigungen" auf der Start-Seite verwaltet, ob die auch irgendwo persistent gespeichert werden, ist aus der reinen Ansicht der Firmware noch nicht ersichtlich. Es gibt mehrere Kategorien für diese Benachrichtungen, offenbar wird dafür ein Bitfeld verwendet, die Kategorien gehen derzeit von 2 bis 128 in Zweierpotenzen, bisher werden auch keine Werte mit Kombinationen in der Kategorie verwendet (die Tests sind immer "category == nummer").

Innerhalb der Kategorien gibt es jeweils wieder "event_id"-Nummern, in der 31909 sind folgende Benachrichtigungen verfügbar:
KategorieEvent-IDMeldungPopup-Text
81Internetverbindung seit mehr als einer Stunde unterbrochenDie FRITZ!Box ist seit mehr als einer Stunde nicht mehr mit dem Internet verbunden.
321Telefonie seit mehr als einer Stunde nicht oder nur eingeschränkt nutzbarEine Rufnummer ist seit mehr als einer Stunde nicht verfügbar.
322Letzter ausgehender Anruf aufgrund eines Fehlers im Telefonnetz gescheitertDie Ursache für das Problem kann vorübergehend sein oder länger andauern. Wenden Sie sich bitte an Ihren Telefonanbieter, sofern das Problem über einen längeren Zeitraum und zu verschiedenen Rufnummern auftritt.
323Untypisch hohe Nutzung von Auslands- bzw. SonderrufnummernInnerhalb kürzerer Zeit wurden mehrfach Auslands- bzw. Sonderrufnummern angewählt. Dies kann erhöhte Kosten nach sich ziehen.
641Kein Empfang von Sprachnachrichten und Faxen möglichDer USB-Speicher an der FRITZ!Box ist voll. Die FRITZ!Box kann daher keine Sprachnachrichten und Faxe mehr annehmen.
128-Dringende Benachrichtigung zu Ihrer FRITZ!Box-
Dieser boxnotifyd ist also der bisher nur vermutete Mechanismus für Meldungen und die rote LED ... von einer Absicht, solche Infos auch per Mail zu versenden, ist bisher nichts zu finden bei AVM - es existiert auch noch keine Vorlage in /etc für eine solche Mail.

7. Es gibt zusätzlich zu den bisher verwendeten Ports 51111 und 51112, die m.E. zu einem Kernelprozess gehören (in der "netstat"-Ausgabe steht jedenfalls kein zugehöriger Prozess), jetzt einen weiteren Port (4711), auf dem man von innen eine TCP-Verbindung zur Box aufbauen kann (ein weiterer Punkt für ein "fingerprinting" einer FRITZ!Box mit dieser OS-Version). Was dort hinter den Kulissen passiert, wäre noch zu klären. Nach kurzer Zeit (wenige Sekunden) wird hier eine aufgebaute Verbindung ohne gesendete Daten vom Server getrennt. Auch auf irgendwelche zufälligen Eingabedaten reagiert der Server da nur mit einen "RST" oder sogar nur mit einem "FIN". Die Frage wäre halt, wozu dieser Port gut ist und ob dort nicht mit passenden Daten ein DoS-Angriff möglich ist, weil man einen Fehler provozieren kann - wie der sich auswirkt, hängt ja davon ab, wo die Daten dieser Verbindung dann wirklich landen im Kernel.

8. In der "Heimnetzübersicht" wird sowohl bei "Alle Geräte" als auch bei "Netzwerkverbindungen" für ein Gerät, was auf Port 80 gar keinen Service bereitstellt, ein entsprechender Link hinter den Gerätenamen gelegt. Zu allem Überfluß zeigt dieser Link - bei aktiviertem 6to4-Tunnel der FRITZ!Box, falls das eine Rolle spielt - auch noch auf eine IPv6-Adresse für dieses Gerät mit unbekannter Interface-ID.

9. Mit dem neuen Kommando "pcplisten" kann man zumindest schon mal ein Port-Forwarding dynamisch einrichten, das in der Ausgabe von "/proc/kdsld/dsliface/internet/ipmasq/{pcp44,openports}" identisch aussieht, wie jedes statische Mapping - (endlich?) auch wieder auf die Box selbst. Allerdings ist die "lifetime" auf max. 300 Sekunden begrenzt, ggf. müßte das also in diesen Intervallen erneuert werden. Damit kann man dann aber wieder interessante Sachen bauen (wenn der Service hinter diesem freigegebenen Port dann auch noch funktioniert, was ich noch nicht getestet habe). Ein Beispiel wäre ein externer SSH-Zugang zur Box, der erst nach einem eingehenden Anruf von einer bestimmten Rufnummer für die erwähnten 5 Minuten freigeschaltet wird, was in den letzten Release-Versionen m.W. immer eine Änderung der ar7.cfg und einen Neustart (zumindest des dsld) erforderte, wenn das Freigabeziel auf der Box selbst lag - dynamische Freigaben gingen nur für Clients im LAN.

10. Neues Kommando "showopenports" zur Anzeige der Portweiterleitungen, auch ohne daß man /proc/kdsld selbst durchflöhen muß. "showpcpinfo" macht prinzipiell dasselbe (allerdings weit ausführlicher) und ist wohl eher für die Anzeige im Rahmen der Support-Daten gedacht als für eine Weiterverarbeitung der Ergebnisse.

11. Die IPSec-Proposals für P2 enthalten mit dem Namen "esp-null-sha/ah-no/comp-no/no-pfs" einen Selektor, der eine unverschlüsselte VPN-Verbindung (lediglich mit einem HMAC als Sicherung der Authentizität) ermöglichen würde. Sicherlich per se noch kein Problem, solange es niemand für eine VPN-Verbindung verwendet und dann seinerseits entsprechende Vertraulichkeit von dieser Verbindung erwartet ... stellt sich die Frage, ob und wann der GUI-Editor das vielleicht auch mal verwendet. Hier würde ich wieder jede neue VPN-Verbindung dahingehend überprüfen - ich kann mir nur schwer vorstellen, daß eine solche unsichere Verbindung im aufgebauten Zustand im GUI irgendwie erkennbar oder von einer verschlüsselten Verbindung zu unterscheiden wäre. Solange beide EPs FRITZ!Boxen mit diesem Proposal sind, ist das recht gefährlich ... allerdings kann es natürlich auch dazu verwendet werden, unwichtige Daten (z.B. Filme) mit wesentlich höherem Durchsatz über eine VPN-Verbindung zu übertragen, weil die einzige notwendige Crypto-Operation das Bilden des HMAC ist. Diese "Entdeckung" sehe ich mit einem lachenden und einem weinenden Auge ... wenn sich jemand mit entsprechender Ahnung so ein Proposal selbst einbaut, ist das immer noch etwas anderes, als wenn es out-of-the-box vorhanden ist.

12. Einige TR-064-Interfaces sind hinzugekommen (bei AVM noch nicht dokumentiert):
  • x_appsetup - irgendwas im Zusammenhang mit den FRITZ!Apps, korrespondiert wohl mit der Apps-Anzeige unter "Anmeldung" - Funktionen "GetInfo", "GetConfig", "RegisterApp", "SetAppVPN", "SetAppMessageReceiver"
  • x_dect - ohne die passenden Geräte bei mir schlecht einzuschätzen ... ich würde auf Update-Verwaltung der DECT-Geräte tippen
  • x_filelink - Verwaltung der NAS-Links für den Zugriff auf freigegebene Dateien
  • x_homeauto - AHA, auch die Heizkörperregler finden sich hier für eine externe Abfrage - könnte für die FHEM-Integration eine interessante Schnittstelle sein, aber soweit man auch das ohne die Regler einschätzen kann, wohl nur eine Abfrageschnittstelle und nichts zum Setzen (außer einem "SetSwitch", das aber eher für die DECT!200/210-Geräte gedacht ist, denn es gibt nur die Werte "ON", "OFF", "TOGGLE" und "UNDEFINED")
  • x_homeplug - wohl das Äquivalent zu x_dect für PLC-Geräte
  • x_speedtest - Verwaltung der Speedtest-Einstellungen, keine Funktion für einen eigenen Test ... im Prinzip nur die Einstellungen aus der "FRITZ!Box Support"-Seite, komischerweise mit getrennten Setups beim WAN für TCP und UDP, das ging bisher im speedtest.ko m.W. gar nicht getrennt zu aktivieren, wenn ich mich nicht irre - in der Seite ist es immer noch zusammengefaßt zu einer Checkbox

13. Die hier auch aufgetauchte Frage nach dem Namen einer MSN in der Anrufliste anstelle der Nummer (wie in der Status-Mail auch) ist sogar noch leichter zu lösen, als ursprünglich angenommen. Folgender Patch probiert zuerst den Namen einer MSN anzuzeigen, bevor auf die Nummer zurückgegriffen wird, wenn die MSN keinen Namen hat:
Code:
--- usr/lua/foncalls.lua
+++ usr/lua/foncalls.lua
@@ -100,7 +100,10 @@
 return call.name==""or call.inBook==0
 end
 function foncalls.msn_display(call)
-local msn=call.msn or""
+local msn=call.msn_name or""
+if nil == msn or "" == msn then
+msn=call.msn
+end
 local msn_type=txt.msn_type[call.msn_type]
 if msn_type then
 return msn,msn.." ("..msn_type..")"
Das "diff" oben ist gegen die /usr/lua/foncalls.lua bei der 31909 für die 7490 und relativ zum Wurzelverzeichnis.

Das Ermitteln des MSN-Namens auf anderen Wegen ist also gar nicht unbedingt notwendig ... die Suche in der calllist.lua ist nur etwas ausführlicher und zeigt auch Anrufbeantworter und Fax richtig an, wenn die keine gesonderten Nummern haben.

14. Die ständig aktive Portweiterleitung für TCP/discard (Port 9) sieht auf den ersten Blick etwas merkwürdig aus (nennt sich IGDPROBE4 und wird wohl in der Sicherheitsseite auch nicht angezeigt) ... da ist von außen eine Weiterleitung dieses Ports auf die interne FRITZ!Box-IP aktiv, die aber nur Broadcast-Pakete auf dem externen Interface akzeptiert. Das dürfte bei einem normalen DSL-Anschluß eigentlich nie passieren, welcher DSLAM sendet denn seinerseits TCP-Pakete mit einer Broadcast-Adresse an Port 9? Habe ich da eine Entwicklung verpaßt oder ignoriert? Bei einer Box im LAN1-Modus sieht das dann vielleicht schon wieder anders aus ... ob am Ende irgendwann auch mal ein Service auf diesem TCP-Port an der internen IP-Adresse lauscht, muß man mal beobachten. Eigentlich sollte nach RFC 863 ja jeder dort ankommende Traffic innerhalb einer TCP-Connection einfach nur still verworfen werden, da macht so eine Weiterleitung von der externen auf die interne Adresse auf mich zunächst mal einen recht komischen Eindruck ... aber erst mal abwarten, was da wirklich passiert.

15. Bei "private"-Builds der Firmware (da, wo CONFIG_RELEASE=0 gesetzt ist) gibt es eine versteckte Option "allow_pcp_and_upnp" für einzelne Netzwerkgeräte in der Seite "edit_device.lua". Damit wird offenbar gezielt einem einzelnen Client das Recht eingeräumt, sich eine eingehende Verbindung durch die Firewall zu bohren (anstatt allen, wie es bei der alten Option der Fall war). Die dazu verwendete Einstellung findet sich dann im "landevices"-Abschnitt der ar7.cfg wieder. Die gute Nachricht angesichts dieser neuen Option ist, daß es die 06.30 absolut nicht juckt, wenn diese Option zusätzlich in der ar7.cfg vorhanden ist, weil man zwischen 06.36 und 06.30 wechselt, ohne die Konfiguration zurückzusetzen. Lediglich beim Wechsel auf die 06.30 werden dann einfach die Einträge für die Geräte neu geschrieben, bei mir hat sowohl die Portfreigabe als auch das "auto_wakeether" für einen solchen Eintrag den Wechsel auf 06.36 (und auch den Wechsel zurück) überlebt, ohne daß die Welt zusammengebrochen wäre. Also führt noch lange nicht jede unbekannte Einstellung in der ar7.cfg sofort zu Problemen beim Wechsel einer Version (auch nicht in Downgrade-Richtung).
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.