Neue OpenSource-Pakete für 06.92

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,275
Punkte für Reaktionen
1,751
Punkte
113
Ich hatte AVM angeschrieben und nach den OpenSource-Paketen für folgende Modelle in der aktuellen Version gefragt:

7490
7412
7580
7590
6590

Für die DSL-Modelle stehen diese jetzt auf "osp.avm.de" zur Verfügung, jeweils in der Version 06.92 (bzw. 06.83 bei der 7412) - die 06.93 bei der 7490 sollte keine relevanten Unterschiede zur 06.92 aufweisen, welche die Verwendung dieser Quellen verhindern.

Für die 6590 erhalte ich die Zugangsdaten erst noch und für die 6490 steht das Paket ja schon seit einigen Tagen (u.a. auf yourfritz.de als Mirror) zur Verfügung (für die 06.87), daher hatte ich danach nicht noch einmal gefragt.
 
Darf ich fragen, was diese Dateien zu bedeuten haben? Wofür sind die gut, was bringen diese für einen Mehrwert etc.?
 
Dort sind (fast) alle Änderungen durch AVM an der Software enthalten, die unter Lizenzen steht, in denen die Weitergabe solcher Änderungen an jeden Interessenten gefordert wird. Dazu gehört auch das "Herz" einer jeden Firmware, der Linux-Kernel - für das Erzeugen eigener Programme braucht man unter Linux die Kenntnis (und die daraus entstehenden Dateien), welche Funktionen bei der Übersetzung in den Kernel eingebaut wurden und über die C-Laufzeitbibliothek (die auf diesen Funktionen aufbaut und damit auch dazu passen muß) dann von weiteren Programmen genutzt werden können.

Das braucht man u.a. dann, wenn man eigene Anpassungen der in der Box installierten Firmware vornehmen will (weil man z.B. die C-Library ersetzen/erweitern will oder neue LKM (loadable kernel module) hinzufügen will (z.B. neue Dateisystem-Formate wie "overlayfs" oder Treiber für "Funksender" zur Hausautomatisierung oder ähnliches) oder eigene Zusatzprogramme installieren will) oder auch nur zum Analysieren der Firmware des Herstellers, ob sich da nicht doch noch irgendwo ein Problem versteckt.

Eigentlich sagt aber der "Pfad" bis zu diesem Thema schon alles ... es geht eben um "FRITZ!Box-Modifikationen" (das "Fon" ist inzwischen einigermaßen überholt) und detaillierter sogar um "Freetz", was u.a. eine "toolchain" der fürs Erzeugen eigener Programme notwendigen Komponenten enthält.
 
Zuletzt bearbeitet:
Zwischenstand meiner Anfrage (vom 23.01.2018) bei AVM nach den in #1 genannten Source-Paketen:

- für alle Modelle außer der 6590 wurden die Dateien in der jeweils angefragten, aktuellsten (Release-)Version unter osp.avm.de/fritzbox bereitgestellt

- für die 6590 wurde in der Nachricht vom 29.01.2018 (auf der dieser Thread basiert) eine nachfolgende Nachricht mit den Zugangsdaten zum Download dieser Daten angekündigt, da AVM diese ja selbst nicht mehr ohne eine solche Zugangssicherung in Form von Benutzernamen und Kennwort bereitstellt, wie wir von der 6490 wissen

- diese Nachricht ist bis heute nicht bei mir eingegangen und auch auf meine erneute Nachfrage per E-Mail vom 14.02.2018 gab es keine Reaktion

Ich werde nachher noch einmal bei AVM nachfragen (und dabei auch auf diesen Beitrag hier verweisen) ... parallel hätte ich trotzdem eine Frage an alle:

Hat hier schon irgendjemand von AVM die Open-Source-Pakete für eine FRITZ!Box 6590 mit FRITZ!OS 06.85 erhalten? Die Frage, daß die 6490-Quellen für eigene Firmware auf einer 6590 ebenso verwendbar sind, interessiert mich hier ausdrücklich nicht, weil es nicht nur um die Suche nach einer passenden Lösung, sondern um die Einhaltung von Lizenzbedingungen geht.

Die fragliche binäre Datei mit dem Namen "FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.06.85.image" (direkt durch mich - ohne jedwede Zugangsbeschränkung - von AVM geladen, mithin von AVM auch "verbreitet"), trägt die folgende Signatur-Datei in sich:
Code:
vidar:/home/FritzBox/FB6590 # tar -x -f FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.06.85.image -O ./var/signature | hexdump -C
00000000  b9 49 70 2a 41 0c 16 e4  4b 0e 6d a6 e2 d6 8d 5d  |.Ip*A...K.m....]|
00000010  48 98 4b 60 56 81 f2 33  df bb 3a e5 aa 12 10 af  |H.K`V..3..:.....|
00000020  f3 56 8d 8b 8e f4 9e 5d  98 23 f6 cf 65 a9 e8 00  |.V.....].#..e...|
00000030  54 94 e1 bd 10 23 da a9  d3 0e 79 45 39 bf ca e6  |T....#....yE9...|
00000040  1d d3 0c 03 e9 f9 7b f1  05 18 6d ff 45 e4 4d 6c  |......{...m.E.Ml|
00000050  eb 5b c7 a0 aa 9f b9 d7  a6 95 f3 7f 79 a3 57 47  |.[..........y.WG|
00000060  57 46 02 d6 3e d8 1b 4a  d1 b8 9b ce 21 5c 24 19  |WF..>..J....!\$.|
00000070  54 dc b4 07 22 54 3d d3  58 71 bc 91 bf 0d 70 54  |T..."T=.Xq....pT|
und nach Ansicht von Kryptographie-Funktionen wurde diese Datei damit durch jemanden erzeugt, der den privaten Schlüssel besitzt, welcher zum öffentlichen Schlüssel in der Datei "/etc/avm_firmware_public_key1" aus der Version 06.83 der Firmware für eine FRITZ!Box 6590 gehört:
Code:
vidar:/home/FritzBox/FB6590 # check_signed_image FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.06.85.image -a 148.06.83/etc/avm_firmware_public_key1
Found OpenSSL 1.0.2l-fips  25 May 2017
Check dgst command ... OK
Check rsautl command ... OK
Checking the public key from 148.06.83/etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
vidar:/home/FritzBox/FB6590 # cat 148.06.83/etc/avm_firmware_public_key1
00c3b9b066566a4835958f7b6793c120b96564d3e77728b84c59d462f55aa9e53ee64ffd502c87c944fb3d725ccb75bd92a7e207c1c13c5ec1b107adef8395273e2672a72246dc45aa2ccf6a8bc0ec91a5836ff2bf8e196ce832752c4acdcddb3e021f3ab764e63e0d1ca2a6c33d6b932c55045078cb93d3e1b14b2e1b260b3b3d
010001
Ich denke nicht, daß die Quelle dieser, im Binärformat verbreiteten, Firmware damit in Zweifel zu ziehen wäre (oder AVM ist schon wieder mal ein privater Schlüssel "entfleucht") und nach den Lizenzbestimmungen, die zumindest für einige der in der Firmware verwendeten Komponenten gelten, ist AVM damit auch verpflichtet, die zugehörigen Quelltext-Dateien, inkl. aller zum Erstellen einer identischen Binärversion notwendigen Skript-Dateien für eine Build-Umgebung (GPLv2-Zitat: "[...] plus the scripts used to control compilation and installation of the executable."), nach Aufforderung durch einen Besitzer der bereitgestellten Binärversion (deren Besitz anhand der o.a. Kenntnisse des Dateiinhalts auch durch mich plausibel gemacht sein sollte, obwohl das für eine Anforderung der Quelltexte vermutlich gar keine Voraussetzung wäre) auch die passenden Quelltext-Dateien (und zwar auch für exakt diese Version der Firmware) herauszugeben.

Das muß zwar nicht vollkommen kostenlos (Aufwand für Datenträger und Versand wäre zu erstatten) und durch Bereitstellung auf einem - über das Internet erreichbaren - Server erfolgen, aber wenn es tatsächlich von zusätzlichen Bedingungen seitens AVM abhängig gemacht werden sollte und auf dem Postweg erfolgen soll (dazu müßte AVM ja auch erst einmal die passenden Daten erfragen bzw. sich vergewissern, daß die in irgendwelchen Signaturen enthaltene Adresse auch die richtige für einen Postversand wäre), müssen diese Umstände auch einem Anfragenden mitgeteilt werden.

Angesichts des Datums der Firmware (10.10.2017, 14:25:24 Uhr) ist ein "wir brauchen noch Zeit, um diese Version bereitzustellen" auch wenig plausibel und auch die seit meiner Anfrage vergangenen 35 Kalendertage (= 5 Wochen) sollten für eine Bereitstellung eigentlich ausreichend Zeit sein, selbst wenn man unterstellt, daß meine Anforderung die erste ihrer Art für die 148.06.85 gewesen sein sollte.

Ich erhalte ja ab und an auch mal "Firmware-Spenden" (mit Download-URLs per E-Mail) von anderen FRITZ!Box-Besitzern ... aber wenn mir nicht bei einem kürzlichen HDD-Problem doch noch "unersetzliche" Dateien unter die Räder gekommen sein sollten (wer kann schon heutzutage seine "Speicher-Disks" alle mindestens doppelt vorhalten - ich schaffe es nicht mehr und muß einige Daten dann halt als "wiederherstellbar aus dem Internet" klassifizieren, was zu einem "eine Kopie reicht auch" führt), habe ich von nirgendwoher bisher eine Quelle für einen Download der Source-Dateien einer FRITZ!Box 6590 erhalten - für die 06.85 wohlgemerkt.

Wenn also jemand die fraglichen Dateien von AVM bereits erhalten haben sollte, wäre ich für eine Rückmeldung (das muß noch nicht mal mit der Weitergabe der Quellen verbunden sein, auch wenn ich die natürlich - als "ultima ratio", wenn AVM weiterhin auf "Schweigen" schaltet - ebenfalls nehmen würde und dann meinerseits bereitstelle für einen Download durch andere) dankbar.
 
Ich habe die OS-Pakete für die 6590/06.85. Auf dem AVM Server sind sie allerdings nicht mehr abrufbar.
 
Zuletzt bearbeitet:
@f666:
Ich habe auf meine (erneute) Mail an AVM bisher keine weitere Antwort erhalten ... kommt da innerhalb von 14 Tagen (ab meiner letzten Mail) nichts weiter, wende ich mich an die FSFE und übergeben denen den kompletten Vorgang - vielleicht will man sich von dort mal einklinken, denn schließlich ist das auch Teil der Öffentlichkeitsarbeit: http://fsfe.org/activities/ftf/reporting-fixing-violations.en.html

Daß die Quellen meist ohnehin unvollständig sind und man auch erst heftig an Skript-Dateien herumschrauben muß, bevor da überhaupt erst einmal die Toolchain aus "buildroot" purzelt, daran hat man sich praktisch schon gewöhnt ... aber daß nun nicht mal mehr pro forma der Anschein der Einhaltung von Lizenzbedingungen bei der 6590 gewahrt wird (sofern es bei der aktuellen "Stille" bleibt), ist relativ neu - mit etwas Warterei konnte man sogar zu Zeiten des Routerzwangs durchaus von AVM auch die Quellen für eine 6360 kriegen.
 
Und weil es eigentlich so schön in diese Ecke mit dem Für und Wider der GPLv2 für den Linux-Kernel paßt (und kein Hersteller wird gezwungen, für sein Produkt auf "Linux" oder irgendwelche Komponenten unter GPL (und deren Derivaten) zurückzugreifen, da gibt es noch genug andere Projekte, die z.B. unter BSD-Lizenz o.ä. stehen und nach meiner Überzeugung bevorzugt AVM solche auch), hier noch ein Link zu einer Meldung, die heute "die Fachwelt" etwas spaltet (in den Kommentaren) bei der Ansicht, wie man sich richtig verhält, wenn die eigenen Produkte mit GPL-Software arbeiten: https://heise.de/-3986181

Ich habe noch einmal in meine E-Mail an AVM gesehen und dabei dann festgestellt, daß ich tatsächlich die Quellen für die 148.06.83-43781 angefordert hatte ... aber auch das spielt nicht wirklich eine Rolle, denn auch diese Version befindet sich in meinem Besitz:
Code:
vidar:/home/FritzBox/FB6590 # tar -x -f FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.06.83.image -O ./var/signature | hexdump -C
00000000  4e b5 50 23 bd 5e c5 0d  8e de 24 44 9e 80 bb 29  |N.P#.^....$D...)|
00000010  2d 79 82 a4 7d 20 0d 19  0d 89 9c c5 58 88 6e a0  |-y..} ......X.n.|
00000020  aa 30 ff 54 cb 0a d1 80  72 4d 1a f7 b0 53 f0 ab  |.0.T....rM...S..|
00000030  9e 08 97 c6 40 8b 2b 5f  d7 d0 4c 12 2c a4 a7 78  |....@.+_..L.,..x|
00000040  af 47 21 74 b6 bb 4b 9d  36 c4 3d ef 5a 5f 3a 59  |.G!t..K.6.=.Z_:Y|
00000050  11 74 13 1e f0 8a 57 48  01 2b 71 3d ce c7 b3 6f  |.t....WH.+q=...o|
00000060  66 6d e8 9c ad 46 3b 10  7b 90 5a d9 cc 76 f2 ef  |fm...F;.{.Z..v..|
00000070  b0 e4 b1 80 3b 93 c0 03  7b 4d 72 3e 7f c5 be c4  |....;...{Mr>....|
00000080
vidar:/home/FritzBox/FB6590 # check_signed_image FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.06.83.image -a 148.06.83/ATOM/etc/avm_firmware_public_key1
Found OpenSSL 1.0.2l-fips  25 May 2017
Check dgst command ... OK
Check rsautl command ... OK
Checking the public key from 148.06.83/ATOM/etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
vidar:/home/FritzBox/FB6590 # cat 148.06.83/ATOM/etc/avm_firmware_public_key1
00c3b9b066566a4835958f7b6793c120b96564d3e77728b84c59d462f55aa9e53ee64ffd502c87c944fb3d725ccb75bd92a7e207c1c13c5ec1b107adef8395273e2672a72246dc45aa2ccf6a8bc0ec91a5836ff2bf8e196ce832752c4acdcddb3e021f3ab764e63e0d1ca2a6c33d6b932c55045078cb93d3e1b14b2e1b260b3b3d
010001
Es steht AVM also frei (das stellte ich schon in meiner ersten Mail in das Belieben von AVM), für welche der beiden Firmware-Versionen sie mir die Sourcen überlassen (ich gehe ohnehin davon aus, daß diese weitgehend deckungsgleich sind) ... aber für eine der beiden möchte ich sie haben, damit ich daraus das passende Paket mit Kernel-Sourcen für meinen Freetz-Fork schnüren kann.
 
  • Like
Reaktionen: frater
Hat jemand schon nach den OS Paketen für die 6590 Version 06.87 gefragt?
 
wie stellt ihr die anfragen an AVM?

Meine Anfrage vom 19. Jan (allerdiungs noch für die 6490) ist bis heute nicht erfüllt.
Ein Mitarbeiter wollte mir die Quellen zur Verfügung stellen was aber irgendwie nicht klappte.
Am 8.2. hieß es dann es gäbe technische Schwiergkeiten er könne mir die Quellen aber nun per eMail zusenden, aus Technischen gründen müsse das aber in einer seperaten Mail passieren. 3 Stunden Später kam dann eine weitere Mail, dass es auch dabei technische Schwierigkeiten gegeben habe und der Mitarbeiter ist seit dem auf der Suche nach einer alternativen möglichkeit mir die Quellen zukommen zu lassen....
 
Das mit dem Versenden der Quellen per Mail kann nur eine Schnapsidee sein oder irgendein Vorwand, die Dateien nicht zu liefern ... angesichts der Größe der Pakete (ARM und ATOM kommen zusammen vermutlich auf mehr als 1 GB, zumindest bei der 6490 ist das so) gibt es praktisch keinen SMTP-Server in freier Wildbahn, der solche Nachrichten akzeptieren und seinerseits weitertransportieren würde - mal ganz abgesehen davon, daß eine Transport-Kodierung für irgendetwas anderes als FTP das noch einmal kräftig aufblasen könnte; bei Base64 um saubere 33%.

Was also ggf. per E-Mail versandt werden kann, sind die Zugangsdaten zu diesen Paketen und der Kunde kann/muß sie sich dann selbst herunterladen. Aber auch dabei legt AVM derzeit nicht wirklich irgendeinen Eifer an den Tag ... ich habe mich jetzt mal an die FSFE gewandt, da mir das auch deshalb stinkt, weil AVM einfach auf Durchzug geschaltet hat und es gar nicht mehr für nötig hält, überhaupt zu reagieren.

Für die 6490 habe ich die 06.87 aber online gestellt (die Dateien hatte ich aber nicht von AVM direkt, siehe #1) ... die Liste der vorhandenen Dateien findet man in http://yourfritz.de/6490/files.lst und für den Download muß man nur das "files.lst" gegen den gewünschten Dateinamen tauschen.
 
Ja die Quellen hab ich mittlerweile schon von fesc, mir geht es nur darum, dass AVM mal ihren kram auf die reihe bekommt.
Hauptsächlich frage ich mich ob ich da einfach einen neuen mitarbeiter bekommen hab, der keine ahnung hat oder ob das ganze absicht ist.

Ich hab ihnen mal angeboten das ganze auf meinen FTP server zu laden, falls es zu viele Technische probleme bei ihnen gibt...
 
Bei mir war es zumindest kein "Neuer" ... insofern stellt sich für mich diese Frage nicht wirklich - daher ja auch die Idee mit der FSFE.

Denn auch wenn es keinen Schadensersatz-Anspruch bei lizenzwidriger Nutzung von GPL-Software gibt (das ist eben nicht zu beziffern bzw. liegt i.d.R. bei 0 EUR), ist das immer noch eine Verletzung des Urheberrechts, wenn AVM sich hier nicht an die Lizenzbestimmungen der GPLv2 hält und das ist nun mal auch in Deutschland immer noch gesetzeswidrig. Vielleicht will AVM jetzt auch die "cure period" mal ausreizen, die einige (US-)Firmen ja seit dem Herbst 2017 von der GPLv3 auf die GPLv2 ausweiten wollen.

Da hilft dann vielleicht ein Hinweis von der FSFE (die ja zumindest einige der Urheber auch irgendwo vertritt) auf einen (erstmaligen) Lizenzverstoß weiter ... nach der GPLv3 hat der Lizenznehmer dann 30 Tage Zeit, für Abhilfe zu sorgen. Vermutlich braucht es erst einmal wieder so eine dokumentierte Information seitens eines Urhebers (der Lizenztext spricht von "copyright holder") oder eines Vertreters eines solchen, damit das auch rechtsfest ist und AVM es irgendwann dann doch noch lernt.

Inzwischen weicht man nämlich immer öfter und immer weiter von den Bestimmungen der GPL (egal ob v2 oder v3) ab, indem man nur noch unvollständige Kernel-Quellen zur Verfügung stellt (siehe "avm_kernel_config" - mit den originalen AVM-Quellen für VR9 kann man keinen funktionsfähigen Kernel mehr erzeugen, weil einerseits auf die Existenz eines FDT getestet wird und andererseits alles das, was zum Einbinden dieser Daten in den Kernel erforderlich ist (und hier reden wir auch nicht von dynamisch geladenen LKM o.ä., sondern von fest eingelinkten Bestandteilen und einem ganz klaren Verstoß gegen die GPLv2-Bestimmungen), in den AVM-Quellen einfach fehlt) oder - wie hier bei der 6590 - sich gar nicht mehr bemüßigt fühlt, die Quellen irgendwie bereitzustellen oder auf Anforderungen dieser Quellen zu reagieren (höchstens noch ausweichend).
 
Mir wurde von AVM diese Adresse genannt: [email protected]
Der angeblich direkte Weg für Anfragen dieser Art.
 
Diese E-Mail-Adresse steht auch genau so in der "info.txt", wo AVM auf die Verwendung von OpenSource-Software unter verschiedenen Lizenzen hinweist.

Schreibt man dort hin, kriegt man eine Ticket-Nummer und eine entsprechende "Bestätigung" - meine letzte hatte den Titel

"Supportanfrage zu FRITZ!Box 6590 Cable mit Ticket-ID 1680868"

Das führt aber eben noch nicht dazu, daß man dann auch die Dateien erhält - für die anderen von mir angefragten Modelle hat AVM diese Daten ja - vollkommen lizenzkonform - unter osp.avm.de bereitgestellt ... aber auch dort eben immer noch die unvollständigen Dateien oder ist da inzwischen auch alles Notwendige dabei, um den Bereich ab "__avm_kernel_config_start" im Kernel mit passenden Daten zu befüllen? Ich habe schon lange nicht mehr nachgesehen.
 
Ich bin ohnehin mal gespannt, wie sich AVM das beim FRITZ!OS 7 dann vorstellt ... nach dem, was man bisher sehen kann:
Code:
vidar:/home/FritzBox/FB7490/firmware/113.06.98-52558/kernel # strings kernel.unpacked | grep ntfs
antfs_follow_link
antfs_dir_read
antfs_lookup
antfs_create
antfs_unlink
antfs_mkdir
antfs_rmdir
antfs_rename
antfs_setattr
antfs_read
antfs_readpages
antfs_zero_cluster
antfs_zero_page
antfs_write_end
antfs_splice_write
antfs_write_begin
antfs_get_block
antfs_fsync
antfs_i_callback
antfs_evict_inode
antfs_statfs
antfs_write_inode
antfs_inode_new
antfs_inode_getattr
antfs_open_device
antfs_set_mountpoint
antfs_parse_options
ntfs_inode_update_times
ntfs_inode_free_space
ntfs_inode_add_attrlist
ntfs_inode_sync_file_name
ntfs_inode_sync_standard_information
ntfs_inode_sync_in_dir
ntfs_inode_attach_all_extents
ntfs_extent_inode_open
ntfs_inode_real_open
ntfs_inode_open
__ntfs_inode_release
ntfs_inode_real_close
ntfs_inode_na_open
ntfs_mft_record_free
ntfs_mft_data_extend_allocation
ntfs_mft_record_init
ntfs_mft_bitmap_extend_initialized
ntfs_mft_attr_extend
ntfs_mft_bitmap_extend_allocation_i
ntfs_mft_record_alloc
ntfs_mft_rec_alloc
ntfs_mft_record_layout
ntfs_file_record_read
ntfs_mft_record_check
ntfs_mft_records_write
ntfs_mft_records_read
4ntfs_logfile_reset
ntfs_set_shown_files
ntfs_volume_check_logfile
ntfs_device_mount
ntfs_hiberfile_open
ntfs_volume_check_hiberfile
ntfs_mftmirr_load
ntfs_mft_load
ntfs_volume_startup
ntfs_boot_sector_parse
ntfs_boot_sector_is_ntfs
ntfs_rl_get_compressed_size
ntfs_rl_sparse
ntfs_rl_truncate
ntfs_get_size_for_mapping_pairs
ntfs_rl_pwrite
ntfs_rl_pread
ntfs_mapping_pairs_decompress_i
ntfs_runlists_merge_i
ntfs_rl_extend
ntfs_device_linux_io_open
ntfs_device_linux_io_close
ntfs_device_linux_io_pread
ntfs_device_unix_io_pwrite
ntfs_device_unix_io_sync
ntfs_load_bitmap_attr
ntfs_link_i
ntfs_inode_free
ntfs_unlink
ntfs_create_symlink
__ntfs_create
ntfs_create
ntfs_dir_entry_type
ntfs_filldir
ntfs_mft_get_parent_ref
ntfs_readdir
ntfs_pathname_to_inode
ntfs_inode_lookup_by_name
ntfs_collate_ntofs_security_hash
ntfs_collate_ntofs_ulong
ntfs_collate_ntofs_ulongs
ntfs_cluster_free
ntfs_cluster_free_basic
ntfs_lcn_bitmap_clear_run
ntfs_cluster_free_from_rl
ntfs_cluster_alloc
ntfs_index_remove
ntfs_index_rm_node
ntfs_index_rm
ntfs_index_add_filename
ntfs_ib_insert
ntfs_ih_insert
ntfs_icx_parent_dec
ntfs_ib_split
ntfs_ibm_modify
ntfs_ibm_add
ntfs_ia_add
ntfs_ir_reparent
ntfs_ir_truncate
ntfs_ir_make_space
ntfs_ie_add
ntfs_ie_lookup
ntfs_ia_check
ntfs_ib_read
ntfs_icx_parent_inc
ntfs_ia_open
ntfs_ir_lookup
ntfs_index_lookup
ntfs_ib_write
ntfs_index_ctx_get
ntfs_attrlist_entry_rm
ntfs_attrlist_entry_add
ntfs_attrlist_need
ntfs_attr_get_free_bits
ntfs_attr_remove
ntfs_attr_exist
ntfs_attr_data_write
ntfs_attr_data_read
ntfs_attr_readall
antfs_do_cluster_alloc
ntfs_attr_make_non_resident
ntfs_attr_record_move_away
ntfs_attr_record_move_to
ntfs_attr_rm
ntfs_attr_add
ntfs_attr_can_be_non_resident
ntfs_non_resident_attr_record_add
ntfs_resident_attr_record_add
ntfs_make_room_for_attr
ntfs_attr_size_bounds_check
ntfs_attr_find_in_attrdef
ntfs_attr_get_search_ctx
ntfs_external_attr_find
ntfs_attr_find
ntfs_attr_lookup
ntfs_attr_name_get
ntfs_attr_mst_pwrite
ntfs_attr_mst_pread
ntfs_attr_pclose
ntfs_non_resident_attr_shrink
ntfs_attr_truncate_i
ntfs_attr_fill_hole
ntfs_attr_fill_zero
ntfs_attr_map_partial_runlist
ntfs_attr_update_meta
ntfs_attr_update_mapping_pairs_i
ntfs_non_resident_attr_expand_i
ntfs_attr_init_search_ctx
ntfs_resident_attr_resize_i
ntfs_attr_pwrite_i
ntfs_attr_pwrite
ntfs_attr_pread_i
ntfs_attr_pread
ntfs_attr_find_vcn
ntfs_attr_map_whole_runlist
ntfs_attr_map_runlist
ntfs_attr_open
ntfs_get_attribute_value
ntfs_malloc
ntfs_empty_logfile
ntfs_is_logfile_clean
ntfs_check_log_client_array
ntfs_check_restart_area
ntfs_check_restart_page_header
ntfs_check_and_load_restart_page
ntfs_check_logfile
ntfs_compressed_close
ntfs_compress_free
ntfs_comp_set
ntfs_compressed_pwrite
ntfs_decompress
ntfs_compressed_attr_pread
ntfs_mst_pre_write_fixup
ntfs_mst_post_read_fixup_warn
fs/antfs/file.c
3[%s] <ERROR> ntfs_attr_pread error reading mft_no %llu at offset %lld: %lld <> %lld
3[%s] <ERROR> ntfs_inode is missing!
fs/antfs/inode.c
3[%s] <ERROR> Colliding inode is valid ntfs inode: mft: %lld; ni->nii: %p; our ni: %p
antfs_inode
antfs
fs/antfs/libntfs-3g/inode.c
3[%s] <ERROR> Note : chkdsk cannot fix this, try ntfsfix
3[%s] <ERROR> ntfs_mft_attr_extend failed
fs/antfs/libntfs-3g/mft.c
3[%s] <ERROR> Failed to open ntfs attribute
3[%s] <ERROR> ntfs_mapping_pairs_decompress() failed
3[%s] <ERROR> libntfs: Critical error
fs/antfs/libntfs-3g/runlist.c
3[%s] <ERROR> ntfs_malloc failed
3[%s] <ERROR> ntfs_link wrong arguments
3[%s] <ERROR> ntfs_io_dup failed
3[%s] <ERROR> ntfs_ie_add_vcn failed: %d
3[%s] <ERROR> ntfs_ib_read failed: %d
3[%s] <ERROR> ntfs_ih_insert failed: %d
3[%s] <ERROR> ntfs_ib_write failed: %d
3[%s] <ERROR> ntfs_ucstombs
3[%s] <ERROR> ntfs_pread failed
3[%s] <ERROR> ntfs_attr_find_in_attrdef failed: %d
3[%s] <ERROR> ntfs_attr_can_be_resident failed.
3[%s] <ERROR> ntfs_attr_can_be_non_resident failed
3[%s] <ERROR> ntfs_attr_find failed
3[%s] <ERROR> Bad ntfs_attr_pclose recursion on inode %lld
3[%s] <ERROR> ntfs_attr_lookup failed
3[%s] <ERROR> Eeek! ntfs_attr_map_whole_runlist failed.
3[%s] <ERROR> ntfs_attr_can_be_resident failed
3[%s] <ERROR> ntfs_attr_open failed, inode %lld attr 0x%lx
3[%s] <ERROR> ntfs_attr_pread failed
3[%s] <ERROR> ntfs_attr_pread partial read (%lld : %lld <> %d)
3[%s] <ERROR> ntfs_attr_pwrite partial write (%lld: %lld <> %d)
vidar:/home/FritzBox/FB7490/firmware/113.06.98-52558/kernel #
, wird ja von AVM der Code für "Tuxera NTFS Embedded" (zumindest sieht es für mich so aus, als wäre es die kommerzielle Version von Tuxera) mit dem Kernel gelinkt.

Mir fehlt im Moment etwas die Phantasie, wie AVM da die Lizenzbedingungen aus der GPLv2 für den Kernel einhalten will, wenn man nicht parallel dazu noch eine Lizenz erworben haben sollte, auch diesen "high performance driver for NTFS" im Quelltext auszuliefern.

Als LKM kann ich mir das noch vorstellen ... da gibt es genug Beispiele (auch bei AVM) und auch eine recht gefestigte Meinung, ob und warum das statthaft sein kann. Aber beim statischen Linken mit dem Kernel wird es dann deutlich schwerer mit solcher Argumentation ... insofern bin ich bereits seit der ersten Version mit diesem Code etwas verblüfft und frage mich, was der (bei AVM hoffentlich vorhandene) Verantwortliche für "license compliance" sich dabei gedacht haben mag - ich hoffe mal, daß es nicht nur ein "Pfeif' auf die Lizenzbedingungen ..." war. Das mag in anderen Ländern noch gut gehen, aber gerade in Deutschland sind schon ein paar Prozesse wegen Verletzung der GPL-Bedingungen für diejenigen schlecht ausgegangen, die es mit dem Urheberrecht bzw. der GPL nicht so genau nehmen wollten.

Sollte es jedenfalls dabei bleiben und AVM liefert die Quellen für den "eingebauten NTFS-Treiber" nicht mit, kann man aus einem weiteren Grund keinen identischen Kernel mehr erzeugen und wäre bei Bau eines eigenen Kernels immer auf zusätzliche Änderungen angewiesen (der Code in "udev-mount-sd" funktioniert eben auch nur noch, wenn man einfach ein "mount -t antfs ..." absetzen kann) und/oder müßte Abstriche bei der Performance hinnehmen.

Das, was AVM da vermutlich vorhat, erscheint mir mehr wie die Quadratur des Kreises und ich hoffe nur zu sehr, daß ich mich mit meiner eher pessimistischen Annahme bzgl. des Verhaltens von AVM bei der Einhaltung der Lizenzbedingungen täusche ... immerhin könnte man durch die Verwendung eines LKM (also beim Einbinden des Tuxera-Codes als dynamisch zu ladendes Module) an dieser Stelle wenigstens so tun, als wäre man zur Einhaltung der Lizenzbedingungen gewillt.

Daß Tuxera sich darum keine grundsätzlichen Gedanken macht, kann man noch nachvollziehen ... schließlich kann man mit dem Code auch ein LKM erzeugen und es werden neben dem Linux-Kernel auch noch diverse andere OS mit anderen Lizenzbedingungen unterstützt. Aber wie AVM hier auf die Idee kommen kann, man könnte den Tuxera-Code statisch gegen den Kernel linken, verstehe ich absolut nicht (ich würde auch keine Performance-Einbußen erwarten, wenn das ein LKM wäre) ... allerdings beruht dieses Unverständnis tatsächlich auf der Annahme, daß die OSS-Quellen für FRITZ!OS 7 das Kernel-Module für NTFS-Support nicht enthalten werden - weil AVM vermutlich(!) keine Lizenz zur Verbreitung im Quellcode von Tuxera erworben haben wird.

Aber das ist ja alles ohnehin noch nicht spruchreif und AVM hat noch jede Menge Gelegenheiten, das irgendwie sinnvoll auszugestalten ... auf der anderen Seite fragt man sich halt, was sich die Verantwortlichen dabei denken und ob sie diese Fragen tatsächlich bei ihren Design-Entscheidungen berücksichtigt haben oder nicht.

Denn eigentlich gibt es für den von AVM vertretenen Standpunkt, daß man erst für eine Release-Version die OpenSource-Pakete bereitstellen müsse, keinerlei Grundlage im Text der GPL ... da wird lediglich auf die Verbreitung in binärer Form abgestellt und keine Unterscheidung zwischen Beta-, Test- oder irgendwelchen Release-Versionen getroffen. Verbreitet ein Hersteller eine Software, die (untrennbar) mit Komponenten unter GPL verbunden ist, muß er dafür auch die Quellen bereitstellen und nicht erst irgendwann in ferner Zukunft, wenn daraus vielleicht mal eine Release-Version erwachsen sein sollte.

PS: Bitte nicht zusammenfassen mit #14 - eigentlich wollte ich mit dem Thema eine Ebene höher auflaufen (direkt in "Modifikationen"), es paßt(e) halt im Moment nur recht gut in diesen Thread hinein und zum Gedankengang, was sich AVM wohl im Bezug auf die GPL und deren künftige Einhaltung vorgenommen haben mag.
 
Zuletzt bearbeitet:
Ich habe heute Downloadlinks für 6490 06.87 und 6590 06.85 bekommen. Die Dateien liegen Passworgeschützt auf ku2coh2thohl3ai.avm.de und die Downloadlinks sind einen Monat gültig.
 
Laut meinem AVM Mitarbeiter soll ich nächste woche die 6.87 für die 6590 bekommen!
 
Ich habe heute die Quellen für die 06.85 der 6590 erhalten. Die kommen nachher auch auf den Server unter yourfritz.de (muß sie noch etwas umpacken/ansehen) ... zur Verzeichnisstruktur muß ich mir noch ein paar Gedanken machen, weil bisher halt "6490" im Pfad enthalten ist.

Ansonsten ist das auch bei mir derselbe "Server" (ist wohl eher ein Client im AVM-LAN - die Adresse sieht schon sehr nach etwas "MyFRITZ!"-ähnlichem aus), auf dem die Dateien bei AVM liegen.
 
aber auch dort eben immer noch die unvollständigen Dateien oder ist da inzwischen auch alles Notwendige dabei, um den Bereich ab "__avm_kernel_config_start" im Kernel mit passenden Daten zu befüllen? Ich habe schon lange nicht mehr nachgesehen.
Wichtig wäre, dass die Quellen nun endlich vollständig sind, so dass man direkt einen Kernel bauen kann.
 
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.