Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: smbmount oder smbclient fur SMB1 / NT1
4 views
Skip to first unread message
Paul Muster
Feb 2, 2023, 9:22:04 AM2/2/23
to
Am 02.02.2023 um 14:50 schrieb Marc Haber:
> ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
> scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
> veröffentlichen kann. Die Daten, die auf der Karte liegen, sind dort
> unverschlüsselt und können von jedem, der das Gerät anfassen kann,
> einfach ausgelesen werden, indem man einfach die SD-Karte rauszieht
> und in einen Kartenleser steckt.
>
> Dieser Scanner steht in einem abgetrennten Netzwerksegment, weil er
> nur das bekanntermaßen unsichere SMB1-Protokoll spricht. Ein
> Linux-Rechner hängt die exportierte SD-Karte mit Hilfe des CIFS/SMB
> Clients im Linux-Kernel (mount -t cifs) ein und verarbeitet die Scans
> weiter. Eine andere Zugriffsmöglichkeit wie ftp gibt es nicht; man
> könnte noch die SD-Karte durch die Gegend tragen.
>
> Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
> smbclient mit verschiedenen Settings von client (min|max) protocol in
> der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
> einer funktionierende Verbindung.
Was hat sich vor einigen Wochen geändert? /var/log/apt/history.log
> Ist der SMB1/NT1 Support aus dem aktuellen Linux-Kernel und aus dem
> aktuellen smbclient inzwischen endgültig herausgeflogen?
Was ist denn der "aktuelle" Kernel bzw. der "aktuelle" smbclient bei der
von dir genutzten Distribution?
> Oder woran
> kann es sonst liegen, dass ich nur noch auf Umwegen an meine Scans
> herankomme?
Ping geht?
mfG Paul
> ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
> scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
> veröffentlichen kann. Die Daten, die auf der Karte liegen, sind dort
> unverschlüsselt und können von jedem, der das Gerät anfassen kann,
> einfach ausgelesen werden, indem man einfach die SD-Karte rauszieht
> und in einen Kartenleser steckt.
>
> Dieser Scanner steht in einem abgetrennten Netzwerksegment, weil er
> nur das bekanntermaßen unsichere SMB1-Protokoll spricht. Ein
> Linux-Rechner hängt die exportierte SD-Karte mit Hilfe des CIFS/SMB
> Clients im Linux-Kernel (mount -t cifs) ein und verarbeitet die Scans
> weiter. Eine andere Zugriffsmöglichkeit wie ftp gibt es nicht; man
> könnte noch die SD-Karte durch die Gegend tragen.
>
> Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
> smbclient mit verschiedenen Settings von client (min|max) protocol in
> der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
> einer funktionierende Verbindung.
Was hat sich vor einigen Wochen geändert? /var/log/apt/history.log
> Ist der SMB1/NT1 Support aus dem aktuellen Linux-Kernel und aus dem
> aktuellen smbclient inzwischen endgültig herausgeflogen?
Was ist denn der "aktuelle" Kernel bzw. der "aktuelle" smbclient bei der
von dir genutzten Distribution?
> Oder woran
> kann es sonst liegen, dass ich nur noch auf Umwegen an meine Scans
> herankomme?
Ping geht?
mfG Paul
Marc Haber
Feb 2, 2023, 10:16:06 AM2/2/23
to
Paul Muster <exp-3...@news.muster.net> wrote:
>Am 02.02.2023 um 14:50 schrieb Marc Haber:
>
>> ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
>> scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
>> veröffentlichen kann. Die Daten, die auf der Karte liegen, sind dort
>> unverschlüsselt und können von jedem, der das Gerät anfassen kann,
>> einfach ausgelesen werden, indem man einfach die SD-Karte rauszieht
>> und in einen Kartenleser steckt.
>>
>> Dieser Scanner steht in einem abgetrennten Netzwerksegment, weil er
>> nur das bekanntermaßen unsichere SMB1-Protokoll spricht. Ein
>> Linux-Rechner hängt die exportierte SD-Karte mit Hilfe des CIFS/SMB
>> Clients im Linux-Kernel (mount -t cifs) ein und verarbeitet die Scans
>> weiter. Eine andere Zugriffsmöglichkeit wie ftp gibt es nicht; man
>> könnte noch die SD-Karte durch die Gegend tragen.
>>
>> Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
>> smbclient mit verschiedenen Settings von client (min|max) protocol in
>> der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
>> einer funktionierende Verbindung.
>
>Was hat sich vor einigen Wochen geändert? /var/log/apt/history.log
Vermutlich neuer Kernel und neuer Userspace.
>Am 02.02.2023 um 14:50 schrieb Marc Haber:
>
>> ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
>> scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
>> veröffentlichen kann. Die Daten, die auf der Karte liegen, sind dort
>> unverschlüsselt und können von jedem, der das Gerät anfassen kann,
>> einfach ausgelesen werden, indem man einfach die SD-Karte rauszieht
>> und in einen Kartenleser steckt.
>>
>> Dieser Scanner steht in einem abgetrennten Netzwerksegment, weil er
>> nur das bekanntermaßen unsichere SMB1-Protokoll spricht. Ein
>> Linux-Rechner hängt die exportierte SD-Karte mit Hilfe des CIFS/SMB
>> Clients im Linux-Kernel (mount -t cifs) ein und verarbeitet die Scans
>> weiter. Eine andere Zugriffsmöglichkeit wie ftp gibt es nicht; man
>> könnte noch die SD-Karte durch die Gegend tragen.
>>
>> Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
>> smbclient mit verschiedenen Settings von client (min|max) protocol in
>> der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
>> einer funktionierende Verbindung.
>
>Was hat sich vor einigen Wochen geändert? /var/log/apt/history.log
>> Ist der SMB1/NT1 Support aus dem aktuellen Linux-Kernel und aus dem
>> aktuellen smbclient inzwischen endgültig herausgeflogen?
>
>Was ist denn der "aktuelle" Kernel bzw. der "aktuelle" smbclient bei der
>von dir genutzten Distribution?
> > Oder woran
> > kann es sonst liegen, dass ich nur noch auf Umwegen an meine Scans
> > herankomme?
>
>Ping geht?
nicht.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Andreas Kohlbach
Feb 8, 2023, 12:40:08 PM2/8/23
to
On 8 Feb 2023 15:33:22 GMT, Gerald E¡scher wrote:
>
> Die Freigabe mounten können, ist halt komfortabler, aber ich habe nichts
> gefunden bis zu welcher Kernelversion das cifs-Modul NetBIOS
> unterstützt. Vielleicht auch überhaupt nicht und es ist der Vorgänger
> smbfs nötig. smbfs ist in aktuellen Kerneln aber nicht mehr drin.
Ich habe auf einem Debian Testing SMB, und vor Jahren konnte ich über den
Eintrag in der /etc/fstab mounten. Ohne dass ich etwas änderte, geht das
nun nicht mehr. Vielleicht hat sich was im Kernel/Userland getan, was
meine "alte Methode" nicht mehr erlaubt.
Aber fast egal, da ich SMB nicht wirklich nutze. Bei Interesse kann ich
aber mal Versionsnummern posten.
Ich f'uppe mal in die Samba Gruppe.
--
Andreas
>
> Die Freigabe mounten können, ist halt komfortabler, aber ich habe nichts
> gefunden bis zu welcher Kernelversion das cifs-Modul NetBIOS
> unterstützt. Vielleicht auch überhaupt nicht und es ist der Vorgänger
> smbfs nötig. smbfs ist in aktuellen Kerneln aber nicht mehr drin.
Ich habe auf einem Debian Testing SMB, und vor Jahren konnte ich über den
Eintrag in der /etc/fstab mounten. Ohne dass ich etwas änderte, geht das
nun nicht mehr. Vielleicht hat sich was im Kernel/Userland getan, was
meine "alte Methode" nicht mehr erlaubt.
Aber fast egal, da ich SMB nicht wirklich nutze. Bei Interesse kann ich
aber mal Versionsnummern posten.
Ich f'uppe mal in die Samba Gruppe.
--
Andreas
Gerald E¡scher
Feb 8, 2023, 5:43:25 PM2/8/23
to
Andreas Kohlbach schrieb am 8/2/2023 18:39:
> On 8 Feb 2023 15:33:22 GMT, Gerald E¡scher wrote:
>>
>> Die Freigabe mounten können, ist halt komfortabler, aber ich habe nichts
>> gefunden bis zu welcher Kernelversion das cifs-Modul NetBIOS
>> unterstützt. Vielleicht auch überhaupt nicht und es ist der Vorgänger
>> smbfs nötig. smbfs ist in aktuellen Kerneln aber nicht mehr drin.
>
> Ich habe auf einem Debian Testing SMB, und vor Jahren konnte ich über den
> Eintrag in der /etc/fstab mounten.
Was gemountet? Welches Dateisystem? smbfs oder cifs?
> On 8 Feb 2023 15:33:22 GMT, Gerald E¡scher wrote:
>>
>> Die Freigabe mounten können, ist halt komfortabler, aber ich habe nichts
>> gefunden bis zu welcher Kernelversion das cifs-Modul NetBIOS
>> unterstützt. Vielleicht auch überhaupt nicht und es ist der Vorgänger
>> smbfs nötig. smbfs ist in aktuellen Kerneln aber nicht mehr drin.
>
> Ich habe auf einem Debian Testing SMB, und vor Jahren konnte ich über den
> Eintrag in der /etc/fstab mounten.
> Ohne dass ich etwas änderte, geht das
> nun nicht mehr. Vielleicht hat sich was im Kernel/Userland getan, was
> meine "alte Methode" nicht mehr erlaubt.
>
> Aber fast egal, da ich SMB nicht wirklich nutze. Bei Interesse kann ich
> aber mal Versionsnummern posten.
--
Gerald
Gerald E¡scher
Feb 8, 2023, 6:32:09 PM2/8/23
to
Marc Haber schrieb am 2/2/2023 16:16:
> Paul Muster <exp-3...@news.muster.net> wrote:
>>
>>Was ist denn der "aktuelle" Kernel bzw. der "aktuelle" smbclient bei der
>>von dir genutzten Distribution?
>
> Heute 6.1.8 und smbclient 4.17. Morgen kernel 6.1.9.
Nach Lektüre von
https://www.kernel.org/doc/html/latest/admin-guide/cifs/usage.html
meine ich, dass dein Scanner SMB1 verwendet, aber nur auf Port 139 über
NetBIOS. Das LAN-Manager-Protokoll kann cifs offensichtlich nicht, Port
139 aber schon.
"vers=1.0" wird mehrmals im Text erwähnt, ich vermisse diese Option
("vers=arg" in der Manpage von mount.cifs) allerdings in der
Auflistung der Mount Options. In der Auflistung vergessen worden oder
aus cifs.o rausgeflogen?
--
Gerald
> Paul Muster <exp-3...@news.muster.net> wrote:
>>
>>Was ist denn der "aktuelle" Kernel bzw. der "aktuelle" smbclient bei der
>>von dir genutzten Distribution?
>
> Heute 6.1.8 und smbclient 4.17. Morgen kernel 6.1.9.
https://www.kernel.org/doc/html/latest/admin-guide/cifs/usage.html
meine ich, dass dein Scanner SMB1 verwendet, aber nur auf Port 139 über
NetBIOS. Das LAN-Manager-Protokoll kann cifs offensichtlich nicht, Port
139 aber schon.
"vers=1.0" wird mehrmals im Text erwähnt, ich vermisse diese Option
("vers=arg" in der Manpage von mount.cifs) allerdings in der
Auflistung der Mount Options. In der Auflistung vergessen worden oder
aus cifs.o rausgeflogen?
--
Gerald
Marc Haber
Feb 22, 2023, 10:29:02 AM2/22/23
to
Marc Haber <mh+usene...@zugschl.us> wrote:
>ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
>scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
>veröffentlichen kann.
>ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
>scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
>veröffentlichen kann.
>Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
>smbclient mit verschiedenen Settings von client (min|max) protocol in
>der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
>einer funktionierende Verbindung.
And the Winner is: Eine Regression im Kernel.
>smbclient mit verschiedenen Settings von client (min|max) protocol in
>der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
>einer funktionierende Verbindung.
Im Kernel 5.8 geht es noch, im Kernel 6.1 ists kaputt.
Im Trace zeigt sich: TCP-Verbindungsaufbau auf Port 139, NETBIOS
Session Request, Negotiate Protocol Request vom Client (mit NT LM 0.12
und POSIX 2 als angebotenen Dialekten). Der Scanner antwortet mit
einem Positive Session Response und schickt dann direkt ein FIN
hinterher.
Das hat mich stutzig gemacht, warum sollte der zuerst sagen "alles
fein" und dann auflegen.
Ich habe daraufhin auf meinem Debian sid den Kernel 5.8 aus Debian
bullseye installiert, und mit diesem konnte ich das Laufwerk vom
Scanner problemlos einhängen und auch Daten übertragen.
Ich habe dann beide Traces nebeineinander gelegt und vom Zeitpunkt des
Abbruches zurück nachgeschaut, wo die Unterschiede sind. Dabei habe
ich festgestellt, dass das LENGTH Field im vom Client gesendeten
NETBIOS Session Request im "Gut" fall um 2 niedriger ist als im
"Schlecht" Fall, obwohl das IP-Paket in beiden Fällen gleich lang ist.
Ergo: Eins der Längenfelder muss falsch sein, und zwar
naheliegenderweise das aus dem "Schlecht"-Fall, und die falsche Länge
bringt den SMB-Server vom Scanner so heftig aus dem Tritt das dieser
das Handtuch wirft und auflegt.
Das habe ich im IRC angesprochen und Lalufu hat sich netterweise in
die Kernelsourcen gestürzt. Schließlich kam er dann mit
|https://github.com/torvalds/linux/commit/d7173623bf0b1503bc4e6f13cd0fccab5e98c6ce#diff-9da6c9cec14d939ab18e7037291932a32d5b394f6b74e1eb18b9c77%0A909701bb6
und dem Hinweis "probier mal in Zeile 2877 statt -2 ein -4" um die
Ecke.
Aktuellen Kernel genommen, Änderung durchgeführt, Kernel compiled,
ausprobiert, geht.
So muss Open Source funktionieren.
Vielen Dank an alle.
Grüße
Marc
XP+F'up in die Samba-Gruppe, da hätte das von Anfang an hin gehört.
Sorry dafür.
Gerald E¡scher
Feb 22, 2023, 12:57:37 PM2/22/23
to
Marc Haber schrieb am 22/2/2023 16:29:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>>ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
>>scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
>>veröffentlichen kann.
>
>>Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
>>smbclient mit verschiedenen Settings von client (min|max) protocol in
>>der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
>>einer funktionierende Verbindung.
>
> And the Winner is: Eine Regression im Kernel.
>
> Im Kernel 5.8 geht es noch, im Kernel 6.1 ists kaputt.
>
> Im Trace zeigt sich: TCP-Verbindungsaufbau auf Port 139, NETBIOS
> Session Request, Negotiate Protocol Request vom Client (mit NT LM 0.12
> und POSIX 2 als angebotenen Dialekten).
Wenn ich die Tabelle auf
> Marc Haber <mh+usene...@zugschl.us> wrote:
>>ich habe hier einen Scanner von ca 2008, der autark auf eine SD-Karte
>>scannen kann und den Inhalt dieser SD-Karte als SMB-Server im Netzwerk
>>veröffentlichen kann.
>
>>Seit einigen Wochen funktioniert dieser CIFS-Mount nicht mehr, auch
>>smbclient mit verschiedenen Settings von client (min|max) protocol in
>>der smb.conf fällt auf unterschiedliche Fehlermeldungen, aber nie zu
>>einer funktionierende Verbindung.
>
> And the Winner is: Eine Regression im Kernel.
>
> Im Kernel 5.8 geht es noch, im Kernel 6.1 ists kaputt.
>
> Im Trace zeigt sich: TCP-Verbindungsaufbau auf Port 139, NETBIOS
> Session Request, Negotiate Protocol Request vom Client (mit NT LM 0.12
> und POSIX 2 als angebotenen Dialekten).
<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/80850595-e301-4464-9745-58e4945eb99b>
und
<http://lug.krems.cc/docu/samba/ch03_03.html#ch03-67366>
richtig deute, entspricht "NT LM 0.12" dem Protokoll "NT1" aus der
smb.conf, auch "CIFS" genannt.
Demnach kann NT1 auch über den Port 139 (NetBIOS) laufen, das war mir
nicht klar.
> Das habe ich im IRC angesprochen und Lalufu hat sich netterweise in
> die Kernelsourcen gestürzt. Schließlich kam er dann mit
> |https://github.com/torvalds/linux/commit/d7173623bf0b1503bc4e6f13cd0fccab5e98c6ce#diff-9da6c9cec14d939ab18e7037291932a32d5b394f6b74e1eb18b9c77%0A909701bb6
> und dem Hinweis "probier mal in Zeile 2877 statt -2 ein -4" um die
> Ecke.
Bug eingebaut?
> Aktuellen Kernel genommen, Änderung durchgeführt, Kernel compiled,
> ausprobiert, geht.
>
> So muss Open Source funktionieren.
--
Gerald
Marc Haber
Feb 22, 2023, 2:24:51 PM2/22/23
to
Gerald E¡scher <Spa...@fahr-zur-Hoelle.org> wrote:
>Marc Haber schrieb am 22/2/2023 16:29:
>> Im Trace zeigt sich: TCP-Verbindungsaufbau auf Port 139, NETBIOS
>> Session Request, Negotiate Protocol Request vom Client (mit NT LM 0.12
>> und POSIX 2 als angebotenen Dialekten).
>
>Wenn ich die Tabelle auf
><https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/80850595-e301-4464-9745-58e4945eb99b>
>und
><http://lug.krems.cc/docu/samba/ch03_03.html#ch03-67366>
>richtig deute, entspricht "NT LM 0.12" dem Protokoll "NT1" aus der
>smb.conf, auch "CIFS" genannt.
>Demnach kann NT1 auch über den Port 139 (NetBIOS) laufen, das war mir
>nicht klar.
Und demnach unterstützt auch der neueste Kernel noch NT1. Ein noch
>Marc Haber schrieb am 22/2/2023 16:29:
>> Im Trace zeigt sich: TCP-Verbindungsaufbau auf Port 139, NETBIOS
>> Session Request, Negotiate Protocol Request vom Client (mit NT LM 0.12
>> und POSIX 2 als angebotenen Dialekten).
>
>Wenn ich die Tabelle auf
><https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/80850595-e301-4464-9745-58e4945eb99b>
>und
><http://lug.krems.cc/docu/samba/ch03_03.html#ch03-67366>
>richtig deute, entspricht "NT LM 0.12" dem Protokoll "NT1" aus der
>smb.conf, auch "CIFS" genannt.
>Demnach kann NT1 auch über den Port 139 (NetBIOS) laufen, das war mir
>nicht klar.
älterer Kernel (aus grml 2018.12) bietet zusätzlich noch an dieser
Stelle LANMAN2.1 und LM1.2X002 an, aber das war hier nicht ursächlich.
>> Das habe ich im IRC angesprochen und Lalufu hat sich netterweise in
>> die Kernelsourcen gestürzt. Schließlich kam er dann mit
>> |https://github.com/torvalds/linux/commit/d7173623bf0b1503bc4e6f13cd0fccab5e98c6ce#diff-9da6c9cec14d939ab18e7037291932a32d5b394f6b74e1eb18b9c77%0A909701bb6
>> und dem Hinweis "probier mal in Zeile 2877 statt -2 ein -4" um die
>> Ecke.
>
>Sprich, da hat jemand die Sourcen vom cifs-Modul verhübscht und einen
>Bug eingebaut?
von den Entwicklern und Subsystemmaintainern nicht ignoriert werden.
Grüße
Marc
Marc Haber
Feb 28, 2023, 5:19:36 AM2/28/23
to
Andreas Kohlbach <a...@spamfence.net> wrote:
Release) kam ein Patch in den mainline branch. Muss also nichts mehr
einreichen.
>Vielleicht könntest Du Deine Untersuchungen an entsprechenden Entwickler
>weiterleiten, dass die vielleicht in eines der nächsten Kernel-Releases
>einfließen möge?
Ich schrieb oben vielleicht nicht deutlich genug ist, dass es zwischen
all dem Rauschen, dem man als Kernelentwickler ausgesetzt ist, echt
schwierig ist, die Aufmerksamkeit eines Entwicklers für lange genug zu
erhaschen dass er versteht dass es sich hierbei um einen echten Bug
und einen dazu passenden Fix handelt.
Es gibt auch ein Bugzilla für den Kernel, aber da sind die
Reaktionszeiten eher Monate.
Der Kernel ist ein zu großes Projekt dass man als "nobody" irgendwie
angehört wird.
>On Wed, 22 Feb 2023 20:24:50 +0100, Marc Haber wrote:
>> So sieht es aus, ja. Eine klassische Regression. Jetzt muss man nur
>> von den Entwicklern und Subsystemmaintainern nicht ignoriert werden.
Stellt sich heraus, eine Woche vor meinen Aktionen (aber nach dem
>> So sieht es aus, ja. Eine klassische Regression. Jetzt muss man nur
>> von den Entwicklern und Subsystemmaintainern nicht ignoriert werden.
Release) kam ein Patch in den mainline branch. Muss also nichts mehr
einreichen.
>Vielleicht könntest Du Deine Untersuchungen an entsprechenden Entwickler
>weiterleiten, dass die vielleicht in eines der nächsten Kernel-Releases
>einfließen möge?
Ich schrieb oben vielleicht nicht deutlich genug ist, dass es zwischen
all dem Rauschen, dem man als Kernelentwickler ausgesetzt ist, echt
schwierig ist, die Aufmerksamkeit eines Entwicklers für lange genug zu
erhaschen dass er versteht dass es sich hierbei um einen echten Bug
und einen dazu passenden Fix handelt.
Es gibt auch ein Bugzilla für den Kernel, aber da sind die
Reaktionszeiten eher Monate.
Der Kernel ist ein zu großes Projekt dass man als "nobody" irgendwie
angehört wird.
Marc Haber
Mar 1, 2023, 3:00:36 PM3/1/23
to
Andreas Kohlbach <a...@spamfence.net> wrote:
>On Tue, 28 Feb 2023 11:19:34 +0100, Marc Haber wrote:
Das kommt bei den Debian Kernelmaintainern raus, die haben eher keine
Zeit sowas an die Upstream-Entwickler weiterzuleiten.
>On Tue, 28 Feb 2023 11:19:34 +0100, Marc Haber wrote:
>>
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>
>>>Vielleicht könntest Du Deine Untersuchungen an entsprechenden Entwickler
>>>weiterleiten, dass die vielleicht in eines der nächsten Kernel-Releases
>>>einfließen möge?
>>
>> Ich schrieb oben vielleicht nicht deutlich genug ist, dass es zwischen
>> all dem Rauschen, dem man als Kernelentwickler ausgesetzt ist, echt
>> schwierig ist, die Aufmerksamkeit eines Entwicklers für lange genug zu
>> erhaschen dass er versteht dass es sich hierbei um einen echten Bug
>> und einen dazu passenden Fix handelt.
>
>Wie sieht es mit "reportbug" (Debian) aus?
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>
>>>Vielleicht könntest Du Deine Untersuchungen an entsprechenden Entwickler
>>>weiterleiten, dass die vielleicht in eines der nächsten Kernel-Releases
>>>einfließen möge?
>>
>> Ich schrieb oben vielleicht nicht deutlich genug ist, dass es zwischen
>> all dem Rauschen, dem man als Kernelentwickler ausgesetzt ist, echt
>> schwierig ist, die Aufmerksamkeit eines Entwicklers für lange genug zu
>> erhaschen dass er versteht dass es sich hierbei um einen echten Bug
>> und einen dazu passenden Fix handelt.
>
Das kommt bei den Debian Kernelmaintainern raus, die haben eher keine
Zeit sowas an die Upstream-Entwickler weiterzuleiten.
0 new messages