Verbindungsprobleme zu news.individual.net

[Stefan+ (Stefan Froehlich)]

Seit +/- etwas mehr als einer Woche hat mein tin große Probleme,
sich mit news.individual.net zu verbinden. Initial klappt es
durchaus, die Verbindung reißt allerdings schon während der
Initialisierung ab; tin wiederholt den Vorgang dann so lange, bis es
dem Server zu blöd wird und er meine IP-Adresse in eine temporäre
Blacklist packt. Rund 1-2x am Tag, vorzugsweise Nachmittags/Abends
klappt es aus irgendwelchen Gründen dann doch, so auch jetzt, aber
wirklich zufriedenstellend ist das auf Dauer nicht.

Nun gibt es bei Individual.net viele User, und hätten mehrere davon
das gleiche Problem, wäre es wohl schon behoben oder wenigstens
bekannt. Auf der anderen Seite kommuniziert mein Server zwar mit
weit weniger, aber schon auch einigen anderen Rechnern in
unterschiedlichen Protokollen (einschließlich NNTP) völlig
problemlos. Die Konfiguration hat sich seit Monaten nicht verändert,
und relevante (Debian-) Updates gab es zuletzt auch keine.

Ich habe vor ein paar Tagen einmal tcpdump mitlaufen lassen, das
Ergebnis sieht im wesentlichen immer so ähnlich aus wie hier: Alles
passt, bis dann plötzlich und ohne für mich erkennbaren Grund
Schluss ist.

#v+
12:51:01.069659 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 1:104, ack 1, win 85, options [nop,nop,TS val 1536153292 ecr 3764378232], length 103
0x0000: 4c52 620a 9d3e d007 ca8d 23f5 0800 4500 LRb..>....#...E.
0x0010: 009b 4850 4000 2f06 eebb 8285 040b 5fd9 ***@./......._.
0x0020: 2de8 0077 be30 e2da b72b 414c 4e94 8018 -..w.0...+ALN...
0x0030: 0055 9d6b 0000 0101 080a 5b8f d6cc e05f .U.k......[...._
0x0040: da78 3230 3020 5468 6520 7365 7276 6572 .x200.The.server
0x0050: 2077 656c 636f 6d65 7320 7175 6165 6c6d .welcomes.quaelm
0x0060: 6963 682e 6174 2028 3935 2e32 3137 2e34 ich.at.(95.217.4
0x0070: 352e 3233 3229 2e20 4175 7468 6f72 697a 5.232)..Authoriz
0x0080: 6174 696f 6e20 7265 7175 6972 6564 2066 ation.required.f
0x0090: 6f72 2072 6561 6469 6e67 2061 6e64 2070 or.reading.and.p
0x00a0: 6f73 7469 6e67 2e0d 0a osting...
[...]
12:51:03.314649 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 318:348, ack 110, win 85, options [nop,nop,TS val 1536155537 ecr 3764380476], length 30
0x0000: 4c52 620a 9d3e d007 ca8d 23f5 0800 4500 LRb..>....#...E.
0x0010: 0052 4859 4000 2f06 eefb 8285 040b 5fd9 ***@./......._.
0x0020: 2de8 0077 be30 e2da b868 414c 4f01 8018 -..w.0...hALO...
0x0030: 0055 a3dc 0000 0101 080a 5b8f df91 e05f .U........[...._
0x0040: e33c 3530 3120 6865 6164 6572 205b 7261 .<501.header.[ra
0x0050: 6e67 657c 4d65 7373 6167 6549 445d 0d0a nge|MessageID]..
12:51:03.314822 IP hetzner.48688 > news.individual.net.nntp: Flags [P.], seq 110:127, ack 348, win 502, options [nop,nop,TS val 3764380507 ecr 1536155537], length 17
0x0000: d007 ca8d 23f5 4c52 620a 9d3e 0800 4500 ....#.LRb..>..E.
0x0010: 0045 819a 4000 4006 a4c7 5fd9 2de8 8285 ***@.@..._.-...
0x0020: 040b be30 0077 414c 4f01 e2da b886 8018 ...0.wALO.......
0x0030: 01f6 1489 0000 0101 080a e05f e35b 5b8f ..........._.[[.
0x0040: df91 4c49 5354 204e 4557 5347 524f 5550 ..LIST.NEWSGROUP
0x0050: 530d 0a S..
12:51:03.351056 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 348:3244, ack 127, win 85, options [nop,nop,TS val 1536155566 ecr 3764380507], length 2896
0x0000: 4c52 620a 9d3e d007 ca8d 23f5 0800 4500 LRb..>....#...E.
0x0010: 0b84 485a 4000 2f06 e3c8 8285 040b 5fd9 ***@./......._.
0x0020: 2de8 0077 be30 e2da b886 414c 4f12 8018 -..w.0....ALO...
0x0030: 0055 1fc8 0000 0101 080a 5b8f dfae e05f .U........[...._
0x0040: e35b 3231 3520 4465 7363 7269 7074 696f .[215.Descriptio
0x0050: 6e73 2069 6e20 666f 726d 2022 6772 6f75 ns.in.form."grou
[...]
12:51:03.351056 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 3244:4444, ack 127, win 85, options [nop,nop,TS val 1536155566 ecr 3764380507], length 1200
12:51:03.351057 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 4444:7340, ack 127, win 85, options [nop,nop,TS val 1536155566 ecr 3764380507], length 2896
12:51:03.351057 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 7340:10236, ack 127, win 85, options [nop,nop,TS val 1536155566 ecr 3764380507], length 2896
12:51:03.351057 IP news.individual.net.nntp > hetzner.48688: Flags [P.], seq 10236:14580, ack 127, win 85, options [nop,nop,TS val 1536155566 ecr 3764380507], length 4344
[...]
0x03d0: 6169 6c61 626c 650d 0a61 6c61 6261 6d61 ailable..alabama
0x03e0: 2e61 6e6e 6f75 6e63 6509 416e 6e6f 756e .announce.Announ
0x03f0: 6365 6d65 6e74 7320 6f66 2069 6e74 6572 cements.of.inter
12:51:03.351222 IP hetzner.48688 > news.individual.net.nntp: Flags [.], ack 14580, win 436, options [nop,nop,TS val 3764380544 ecr 1536155566], length 0
0x0000: d007 ca8d 23f5 4c52 620a 9d3e 0800 4500 ....#.LRb..>..E.
0x0010: 0034 819b 4000 4006 a4d7 5fd9 2de8 8285 ***@.@..._.-...
0x0020: 040b be30 0077 414c 4f12 e2da f01e 8010 ...0.wALO.......
0x0030: 01b4 1478 0000 0101 080a e05f e380 5b8f ...x......._..[.
0x0040: dfae ..
12:51:03.381016 IP news.individual.net.nntp > hetzner.48688: Flags [R.], seq 14580, ack 127, win 85, length 0
0x0000: 4c52 620a 9d3e d007 ca8d 23f5 0800 4500 LRb..>....#...E.
0x0010: 0028 74e2 0000 3206 ff9c 8285 040b 5fd9 .(t...2......._.
0x0020: 2de8 0077 be30 e2da f01e 414c 4f12 5014 -..w.0....ALO.P.
0x0030: 0055 792a 0000 0000 1227 6823 .Uy*.....'h#
12:51:05.382525 IP hetzner.48704 > news.individual.net.nntp: Flags [S], seq 1402842817, win 64240, options [mss 1460,sackOK,TS val 3764382575 ecr 0,nop,wscale 7], length 0
0x0000: d007 ca8d 23f5 4c52 620a 9d3e 0800 4500 ....#.LRb..>..E.
0x0010: 003c d21f 4000 4006 544b 5fd9 2de8 8285 .<***@.@.TK_.-...
0x0020: 040b be40 0077 539d aec1 0000 0000 a002 ***@.wS.........
0x0030: faf0 1480 0000 0204 05b4 0402 080a e05f ..............._
0x0040: eb6f 0000 0000 0103 0307 .o........
[etc.pp.]
#v-

Da alle anderen Protokolle bislang völlig unauffällig sind, versuche
ich es einmal mit den Newsreader/Newsserver-Gruppen. Aber falls
jemand eine Idee hat, was sonst ursächlich sein mag, kann das auch
gerne in passendere Gefielde umziehen.

Servus,
Stefan

[Clemens Schüller]

Post by Stefan+ (Stefan Froehlich)
Seit +/- etwas mehr als einer Woche hat mein tin große Probleme,
sich mit news.individual.net zu verbinden. Initial klappt es

[[ ... ]]

Schnellschuss: Schon mal mit einem aktuellen Snapshot[1] gegengecheckt?
Dein tin ist von 2022.




Footnotes:
[1] ftp://ftp.tin.org/tin/v2.6/snapshots

[Heiko Schlichting]

Post by Stefan+ (Stefan Froehlich)
Seit +/- etwas mehr als einer Woche hat mein tin große Probleme,
sich mit news.individual.net zu verbinden. Initial klappt es
durchaus, die Verbindung reißt allerdings schon während der
Initialisierung ab [...]

Da habe ich leider auch keine Idee. Änderungen, die das bewirken könnten,
hat es auf unserer Seite meines Wissens nicht gegeben.

Post by Stefan+ (Stefan Froehlich)
Nun gibt es bei Individual.net viele User, und hätten mehrere davon
das gleiche Problem, wäre es wohl schon behoben oder wenigstens
bekannt.

Ja. Es hat am 2024-06-17 in der Zeit von 15 bis etwa 17 Uhr Arbeiten des
Bereichs Netze der Universität gegeben, wo es zu einzelnen Unterbrechungen
kam, wenn bestimmte Voraussetzungen erfüllt waren. Das kann aber keine
Nachwirkungen haben.

Sofern tin das unterstützt, kannst Du natürlich folgendes ausprobieren und
schauen, ob sich etwas am Verhalten ändert:

https://news.individual.de/faq.php#1.13

Vielleicht hat Dein Provider Dich jetzt auf eine neue Firewall ("mit KI")
aufgeschaltet? Usenet ist inzwischen so exotisch, dass ein "ist kein Web,
kenn ich nicht, muss böse sein" zuschlagen könnte. Vermutlich ist aber
etwas viel trivialeres die Ursache in Deinem Fall.

Heiko

[Stefan+ (Stefan Froehlich)]

Post by Heiko Schlichting

Post by Stefan+ (Stefan Froehlich)
Seit +/- etwas mehr als einer Woche hat mein tin große Probleme,
sich mit news.individual.net zu verbinden. Initial klappt es
durchaus, die Verbindung reißt allerdings schon während der
Initialisierung ab [...]

Da habe ich leider auch keine Idee. Änderungen, die das bewirken
könnten, hat es auf unserer Seite meines Wissens nicht gegeben.

Hätte mich jetzt auch eher gewundert, weil es ein recht bizarres
Verhalten ist.

Post by Heiko Schlichting
Ja. Es hat am 2024-06-17 in der Zeit von 15 bis etwa 17 Uhr
Arbeiten des Bereichs Netze der Universität gegeben, wo es zu
einzelnen Unterbrechungen kam, wenn bestimmte Voraussetzungen
erfüllt waren. Das kann aber keine Nachwirkungen haben.

Zudem ist das ganze ja auch recht stochaistisch. Nachdem ich mit
Hilfe von Urs die Endlosschleife der Reconnects entfernt habe, kann
ich nun immerhin einzelne Versuche starten ohne am Ende in der
Blacklist zu landen - davon klappt bislang gefühlt ca. jeder zehnte.
Immer noch nicht zufriedenstellen, aber schon deutlich besser als
"1x Usenet pro Tag".

Post by Heiko Schlichting
Sofern tin das unterstützt, kannst Du natürlich folgendes
https://news.individual.de/faq.php#1.13

Nachdem die ersten zwei Versuche damit erfolgreich waren, war ich
schon sehr verwirrt - war aber nur Zufall, das Verhalten ist genau
das gleiche.

Post by Heiko Schlichting
Vermutlich ist aber etwas viel trivialeres die Ursache in Deinem
Fall.

Vermutlich... aber wo? Das sitzt offenbar ziemlich tief unten im
Schichtenmodell, so viele Verantwortliche kommen da nicht in Frage.

Servus,
Stefan

[Dennis Preiser]

Post by Stefan+ (Stefan Froehlich)
Zudem ist das ganze ja auch recht stochaistisch. Nachdem ich mit
Hilfe von Urs die Endlosschleife der Reconnects entfernt habe, kann
ich nun immerhin einzelne Versuche starten ohne am Ende in der
Blacklist zu landen - davon klappt bislang gefühlt ca. jeder zehnte.
Immer noch nicht zufriedenstellen, aber schon deutlich besser als
"1x Usenet pro Tag".

In Deinem packet dump trat das Problem auf, als der Server die newsgroup
descriptions gesendet hat. (tin schickt LIST NEWSGROUPS und der Server
schickt für jede Gruppe die Beschreibung zurück.) Das ist jede Menge
Traffic Server -> tin, evtl. kommt dabei was in Deinem Netz (Paketfilter
etc.) durcheinander. Du könntest versuchen, das Laden der Beschreibungen
zu unterbinden, entweder mit show_description=OFF im tinrc oder per '-d'
beim Aufruf von tin.

Dennis

[Marcel Logen]

Post by Dennis Preiser

Post by Stefan+ (Stefan Froehlich)
Zudem ist das ganze ja auch recht stochaistisch. Nachdem ich mit

[...]

Post by Dennis Preiser
In Deinem packet dump trat das Problem auf, als der Server die newsgroup
descriptions gesendet hat. (tin schickt LIST NEWSGROUPS und der Server
schickt für jede Gruppe die Beschreibung zurück.) Das ist jede Menge
Traffic Server -> tin, evtl. kommt dabei was in Deinem Netz (Paketfilter
etc.) durcheinander. Du könntest versuchen, das Laden der Beschreibungen
zu unterbinden, entweder mit show_description=OFF im tinrc oder per '-d'
beim Aufruf von tin.

Bei den Beschreibungen der tw.*-Gruppen erscheinen hier bei ei-
nem Test mit OpenSSL seltsame Sonderzeichen, die wohl kein gül-
tiges UTF-8 sind, auf dem Terminal.

Marcel

[Urs Janßen]

Post by Marcel Logen

Post by Dennis Preiser
descriptions gesendet hat. (tin schickt LIST NEWSGROUPS und der Server
schickt für jede Gruppe die Beschreibung zurück.) Das ist jede Menge
Traffic Server -> tin, evtl. kommt dabei was in Deinem Netz (Paketfilter
etc.) durcheinander. Du könntest versuchen, das Laden der Beschreibungen
zu unterbinden, entweder mit show_description=OFF im tinrc oder per '-d'
beim Aufruf von tin.

Bei den Beschreibungen der tw.*-Gruppen erscheinen hier bei ei-
nem Test mit OpenSSL seltsame Sonderzeichen, die wohl kein gül-
tiges UTF-8 sind, auf dem Terminal.

sowas filtert tin dann (hoffentlich) weg; der abbruch kommt ja von wo
anders. das koennte man evtl, mit -T (tls) und/oder -C (compression)
umgehen (achtung, bei grossem active kann das dauern und zu timeout
fuehren bei niedrigem nntp_read_timeout_secs (ich bin bei 30 sek.,
default sind 120), ggf. mit -t anpassen) wenn -d (no descriptions) nicht
in frage kommt.

[Urs Janßen]

Post by Marcel Logen
Bei den Beschreibungen der tw.*-Gruppen erscheinen hier bei ei-
nem Test mit OpenSSL seltsame Sonderzeichen, die wohl kein gül-
tiges UTF-8 sind, auf dem Terminal.

ich hab mal mit ucsdet_detect() aus ICU bzw. uchardet_get_encoding()
aus uchardet geguckt ob man den zeichensatz der beschreibung raten kann,
aber die fehlerrate ist doch sher hoch (einfach zu wenig input und daher
zu mehrdeutig). auf client seite kann man da wohl wenig machen wenn das
newsgroups-file auf serverseite nicht durchgaengig in einem zeichensatz ist.

achja, da ich kein individual-account habe kann ich nicht sagen ob das hier
der fall ist.

[Marcel Logen]

[individual: LIST NEWSGROUPS]

Post by Urs Janßen

Post by Marcel Logen
Bei den Beschreibungen der tw.*-Gruppen erscheinen hier bei ei-
nem Test mit OpenSSL seltsame Sonderzeichen, die wohl kein gül-
tiges UTF-8 sind, auf dem Terminal.

ich hab mal mit ucsdet_detect() aus ICU bzw. uchardet_get_encoding()
aus uchardet geguckt ob man den zeichensatz der beschreibung raten kann,
aber die fehlerrate ist doch sher hoch (einfach zu wenig input und daher
zu mehrdeutig). auf client seite kann man da wohl wenig machen wenn das
newsgroups-file auf serverseite nicht durchgaengig in einem zeichensatz ist.
achja, da ich kein individual-account habe kann ich nicht sagen ob das hier
der fall ist.

Es ist wohl nicht durchgängig in einem Zeichensatz.

Es kommen - soweit ich das sehen kann - sowohl ISO-8859-1
als auch UTF-8 vor. Und bei den "cn.*"- und "tw.*"-Gruppen
eben vermutlich wieder andere Kodierungen ("Big5" für tw?).

In RFC3977 finde ich dazu:

| The description SHOULD be in UTF-8. However, servers often obtain
| the information from external sources. These sources may have used
| different encodings (ones that use octets in the range 128 to 255 in
| some other manner) and, in that case, the server MAY pass it on
| unchanged. Therefore, clients MUST be prepared to receive such
| descriptions.

<https://datatracker.ietf.org/doc/html/rfc3977#section-7.6.6>

Hat aber möglicherweise mit Stefans Problem nicht viel zu tun.

Marcel (Lines: 45)

fup2 d.c.s.newsserver

[Urs Janßen]

Post by Marcel Logen

Post by Urs Janßen
ich hab mal mit ucsdet_detect() aus ICU bzw. uchardet_get_encoding()
aus uchardet geguckt ob man den zeichensatz der beschreibung raten kann,
aber die fehlerrate ist doch sher hoch (einfach zu wenig input und daher
zu mehrdeutig). auf client seite kann man da wohl wenig machen wenn das
newsgroups-file auf serverseite nicht durchgaengig in einem zeichensatz ist.

Es ist wohl nicht durchgängig in einem Zeichensatz.
Es kommen - soweit ich das sehen kann - sowohl ISO-8859-1
als auch UTF-8 vor. Und bei den "cn.*"- und "tw.*"-Gruppen
eben vermutlich wieder andere Kodierungen ("Big5" für tw?).

damit (Big5) koennte ucsdet_detect() o.ae. (Encode::Guess) sogar klappen,
schwer wirds in europa bei ISO-8859-1 vs. ISO-8859-3 vs. ISO-8859-4 vs.
ISO-8859-16 oder KOI8-R vs. KOI8-U u.ae.

Post by Marcel Logen
| The description SHOULD be in UTF-8. However, servers often obtain
| the information from external sources. These sources may have used
| different encodings (ones that use octets in the range 128 to 255 in
| some other manner) and, in that case, the server MAY pass it on
| unchanged.

docheckgroups sollte (ewig nicht mehr angesehen ("meine" version
(basierend auf dem ding von Lutz Donnerhacke) ist von 2005 ,-), denke nicht,
dass das inzwische eingebaut wurde) sich um eine wandlung nach utf-8 kuemmern
(wenn mime-header vorhanden sind einfach iconv drauf loslassen, wenn nicht
hat man wenigstenz mehr context als bei _einer_ zeile. da waer dann auch die
trefferquote beim raten hoeher.

pgp/gpg stoert hier allerdings etwas, also erst checken dann umwandeln.

falls das immer noch nicht der fall ist sollte der admin das machen (wie
auch immer - ich hab IIRC die checkgroups durch recode gejagt).

Post by Marcel Logen
| Therefore, clients MUST be prepared to receive such descriptions.

tin prueft auf utf-8 und ersetzt alles was nicht passt durch '?', in
west-europa ist das lesbar, ab middle-east koennte es unleserlich werden ,-)
auf client seite raten ist halt deutlich fehleranfaelliger als auf sever
seite...

Post by Marcel Logen
Hat aber möglicherweise mit Stefans Problem nicht viel zu tun.
fup2 d.c.s.newsserver

wer weiss, so neumodischer firewall krams bildet sich ja immer oefter ein
protokolle zu verstehen und dann verbindungen zu beenden wenn ihnen
irgendwas nicht passt ... gerne auch mal mit falschen error codes.

kann aber auch was ganz anderes sein.

[Heiko Schlichting]

Post by Urs Janßen
docheckgroups sollte (ewig nicht mehr angesehen ("meine" version
(basierend auf dem ding von Lutz Donnerhacke) ist von 2005 ,-), denke nicht,
dass das inzwische eingebaut wurde) sich um eine wandlung nach utf-8 kuemmern
(wenn mime-header vorhanden sind einfach iconv drauf loslassen, wenn nicht
hat man wenigstenz mehr context als bei _einer_ zeile. da waer dann auch die
trefferquote beim raten hoeher.
pgp/gpg stoert hier allerdings etwas, also erst checken dann umwandeln.
falls das immer noch nicht der fall ist sollte der admin das machen

Habe ich notiert. Das Durcheinander ist wirklich fürchterlich und
eigentlich wäre es an der Zeit, dass für checkgroups u.a. Controlmessages
vorgeschrieben wird, dass die entsprechenden Bezeichnungen immer in UTF-8
verwendet werden sollen (im Sinne von müssen).

Heiko

[Stefan Wiens]

Post by Urs Janßen

Post by Marcel Logen
Bei den Beschreibungen der tw.*-Gruppen erscheinen hier bei ei-
nem Test mit OpenSSL seltsame Sonderzeichen, die wohl kein gül-
tiges UTF-8 sind, auf dem Terminal.

ich hab mal mit ucsdet_detect() aus ICU bzw. uchardet_get_encoding()
aus uchardet geguckt ob man den zeichensatz der beschreibung raten kann,
aber die fehlerrate ist doch sher hoch (einfach zu wenig input und daher
zu mehrdeutig). auf client seite kann man da wohl wenig machen wenn das
newsgroups-file auf serverseite nicht durchgaengig in einem zeichensatz ist.
achja, da ich kein individual-account habe kann ich nicht sagen ob das hier
der fall ist.

LIST NEWSGROUPS geht auch ohne Login.

Ich habe in den letzten Tagen Unterschiede hinsichtlich nntps
und nntp beobachtet. Letzteres führte zu plötzlichen
"Connection closed by foreign host", mehr oder weniger
reproduzierbar an derselben Stelle,
und auf Login kam es anscheinend nicht an.
Aktuell tritt es aber hier nicht mehr auf.

[Urs Janßen]

Post by Stefan Wiens

Post by Urs Janßen
achja, da ich kein individual-account habe kann ich nicht sagen ob das hier
der fall ist.

LIST NEWSGROUPS geht auch ohne Login.

alt.* und free.* und alles mit nur ascii oder ohne beschreibung
ignoriert bleibt dann wohl[1]

be.*: ISO-8859-13
cn.*: GB18030
cna.*: BIG5
ee.*: WINDOWS-1252
es.*: ISO-8859-1
esp.*: ISO-8859-1
fido7.*: KOI8-R
finet.*: ISO-8859-1
fr.*: UTF-8
france.*: ISO-8859-1
ger.*: ISO-8859-2
han.*: UHC
is.*: UTF-8
it.*: UTF-8
it-alt.*: IBM852
maus.*: WINDOWS-1252
muc.*: ISO-8859-2
no.*: ISO-8859-15
relcom.*: KOI8-R
scout.*: BIG5
se.*: ISO-8859-1
sfnet.*: ISO-8859-1
swnet.*: ISO-8859-1
tw.*: BIG5

erlaubt (SHOULD vs. MUST), aber mind. unschoen.

[1]
#v+
for h in \
$(cut -d '.' -f 1 newsgroups | sort | uniq | sort |\
grep -Ev "^(free|alt)$" );\
do echo -n $h".*: "; pcregrep "^"$h"\." newsgroups | uchardet ;\
done | grep -Ev "ASCII"
#v-

urs

[Stefan+ (Stefan Froehlich)]

Post by Stefan Wiens

[...]

LIST NEWSGROUPS geht auch ohne Login.
Ich habe in den letzten Tagen Unterschiede hinsichtlich nntps und
nntp beobachtet. Letzteres führte zu plötzlichen "Connection
closed by foreign host", mehr oder weniger reproduzierbar an
derselben Stelle, und auf Login kam es anscheinend nicht an.
Aktuell tritt es aber hier nicht mehr auf.

Kurioserweise hier seit rund einem Tag nach meinem ersten Posting
auch nicht mehr (nntps habe ich erst gegen Ende versucht, da hatte
ich aber anfangs ebenso Abbrüche). Ich frage mich jetzt, ob ich
besser noch ein paar Tage länger damit gewartet hätte, hier darüber
zu schreiben, oder genau umgekehrt sofort hätte fragen sollen...
Aber Hauptsache es läuft.

Servus,
Stefan

[Stefan+ (Stefan Froehlich)]

Post by Stefan+ (Stefan Froehlich)

Post by Stefan Wiens

[...]

LIST NEWSGROUPS geht auch ohne Login.
Ich habe in den letzten Tagen Unterschiede hinsichtlich nntps und
nntp beobachtet. Letzteres führte zu plötzlichen "Connection
closed by foreign host", mehr oder weniger reproduzierbar an
derselben Stelle, und auf Login kam es anscheinend nicht an.
Aktuell tritt es aber hier nicht mehr auf.

Kurioserweise hier seit rund einem Tag nach meinem ersten Posting
auch nicht mehr (nntps habe ich erst gegen Ende versucht, da hatte
ich aber anfangs ebenso Abbrüche). Ich frage mich jetzt, ob ich
besser noch ein paar Tage länger damit gewartet hätte, hier
darüber zu schreiben, oder genau umgekehrt sofort hätte fragen
sollen... Aber Hauptsache es läuft.

So etwas sollte man nicht schreiben, nie. Seit gestern ist es wieder
ganz übel, ich habe gerade einmal einen Connect bei über 100
Versuchen zustandegebracht. NNTP vs. NNTPS macht dabei genau gar
keinen Unterschied.

Servus,
Stefan

[Stefan+ (Stefan Froehlich)]

Post by Marcel Logen

Post by Dennis Preiser

Post by Stefan+ (Stefan Froehlich)
Zudem ist das ganze ja auch recht stochaistisch. Nachdem ich mit

[...]

Post by Dennis Preiser
In Deinem packet dump trat das Problem auf, als der Server die
newsgroup descriptions gesendet hat. (tin schickt LIST NEWSGROUPS
und der Server schickt für jede Gruppe die Beschreibung zurück.)
Das ist jede Menge Traffic Server -> tin, evtl. kommt dabei was in
Deinem Netz (Paketfilter etc.) durcheinander. Du könntest
versuchen, das Laden der Beschreibungen zu unterbinden, entweder
mit show_description=OFF im tinrc oder per '-d' beim Aufruf von
tin.

Bei den Beschreibungen der tw.*-Gruppen erscheinen hier bei ei-
nem Test mit OpenSSL seltsame Sonderzeichen, die wohl kein gül-
tiges UTF-8 sind, auf dem Terminal.

Das sollte wenigstens auf Protokollebene kein Problem darstellen,
zudem tritt der Fehler ja nicht immer, und auch nicht immer an
dieser Stelle auf (meistens schon, das kann aber auch einfach
statistisch bedingt sein).

Ob SSL-Übertragung etwas ändert muss ich mir ein andermal ansehen,
da jetzt gerade alle Verbindungsversuche funktionieren, als ob nie
etwas gewesen wäre... Heisenbug.

Servus,
Stefan

[gaussianblue]

Dennis Preiser <***@d--p.de> writes:

(Schnitt)

Post by Dennis Preiser
In Deinem packet dump trat das Problem auf, als der Server die newsgroup
descriptions gesendet hat. (tin schickt LIST NEWSGROUPS und der Server
schickt fÃŒr jede Gruppe die Beschreibung zurÃŒck.) Das ist jede Menge
Traffic Server -> tin, evtl. kommt dabei was in Deinem Netz (Paketfilter
etc.) durcheinander. Du könntest versuchen, das Laden der Beschreibungen
zu unterbinden, entweder mit show_description=OFF im tinrc oder per '-d'
beim Aufruf von tin.

Im tcpdump haben alle Pakete Options ([nop,nop,TS val usw...) nur dieses
eine TCP RST/ACK nicht.

[Dennis Preiser]

Post by Stefan+ (Stefan Froehlich)
Ich habe vor ein paar Tagen einmal tcpdump mitlaufen lassen, das
Ergebnis sieht im wesentlichen immer so ähnlich aus wie hier: Alles
passt, bis dann plötzlich und ohne für mich erkennbaren Grund
Schluss ist.

Hier empfängst Du ein TCP RST/ACK ([R.]), d.h. die Gegenseite bestätigt den
Empfang vorheriger Pakete (ACK) und teilt Dir mit, dass die

Post by Stefan+ (Stefan Froehlich)
12:51:03.381016 IP news.individual.net.nntp > hetzner.48688: Flags [R.], seq 14580, ack 127, win 85, length 0

Und hier baust Du eine neue TCP-Verbindung auf (SYN, [S]), auch erkennbar am

Post by Stefan+ (Stefan Froehlich)
12:51:05.382525 IP hetzner.48704 > news.individual.net.nntp: Flags [S], seq 1402842817, win 64240, options [mss 1460,sackOK,TS val 3764382575 ecr 0,nop,wscale 7], length 0

Die Frage ist, warum die Gegenseite die Verbindung wegwirft. Passiert
das auch mit news.individual.de?

Dennis

[Stefan+ (Stefan Froehlich)]

Post by Dennis Preiser

Post by Stefan+ (Stefan Froehlich)
Ich habe vor ein paar Tagen einmal tcpdump mitlaufen lassen, das
Alles passt, bis dann plötzlich und ohne für mich erkennbaren
Grund Schluss ist.

Hier empfängst Du ein TCP RST/ACK ([R.]), d.h. die Gegenseite
bestätigt den Empfang vorheriger Pakete (ACK) und teilt Dir mit,

Post by Stefan+ (Stefan Froehlich)
12:51:03.381016 IP news.individual.net.nntp > hetzner.48688: Flags [R.], seq 14580, ack 127, win 85, length 0

Und hier baust Du eine neue TCP-Verbindung auf (SYN, [S]), auch erkennbar am

Post by Stefan+ (Stefan Froehlich)
12:51:05.382525 IP hetzner.48704 > news.individual.net.nntp: Flags [S], seq 1402842817, win 64240, options [mss 1460,sackOK,TS val 3764382575 ecr 0,nop,wscale 7], length 0

Meine TCP/IP-Kenntnisse sind ueberschaubar, aber so im wesentlichen
habe ich mir das zusammengereimt, ja.

Post by Dennis Preiser
Die Frage ist, warum die Gegenseite die Verbindung wegwirft.
Passiert das auch mit news.individual.de?

Ja. Da das auf die gleichen IP-Adressen aufgelöst wird und der
Server vom ursprünglich verwendeten Namen nichts mitbekommt hätte
mich alles andere auch sehr überrascht.

Nicht gegenwärtig war mir jedoch, dass zwei verschiedene IP-Adressen
verwendet werden. Doch auch hier: Beide sind gleichermaßen davon
betroffen.

Servus,
Stefan

[gaussianblue]

Seit +/- etwas mehr als einer Woche hat mein tin große Probleme,
sich mit news.individual.net zu verbinden. Initial klappt es
durchaus, die Verbindung reißt allerdings schon wÀhrend der
Initialisierung ab; tin wiederholt den Vorgang dann so lange, bis es
dem Server zu blöd wird und er meine IP-Adresse in eine temporÀre
Blacklist packt. Rund 1-2x am Tag, vorzugsweise Nachmittags/Abends
klappt es aus irgendwelchen GrÃŒnden dann doch, so auch jetzt, aber
wirklich zufriedenstellend ist das auf Dauer nicht.

Hi. Also was du schilderst kommt mir sehr bekannt vor. Seit einer Woche
hängt nn . Um News weiterlesen zu können muss ich nn abbrechen und
neu starten. Normalerweise beim Newslesen gehe ich mehrere Gruppen durch.
Ich öffne sie. nn gibt mir eine Liste der Artikel mit dem Betreff. Ich öffne
ein Artikel, oder vielleicht auch nicht. Ich gehe zur nächsten Gruppe.
Jetzt wenn ich wie gewohnt News lese, an einem scheinbar zufälligen Moment
wenn ich von einer Gruppe zu einer anderen wechsle, hängt nn.
Dabei schreibt
er unten in der Statuszeile, dass er sich neu verbindet. Wenn ich nn schnell genug
abbreche, kann ich beim Neustart von nn News weiterlesen. Wenn ich ihn aber
nicht abbreche sondern warte und erst dann abbreche, wird mir die Verbindung mit
dem Server verweigert, mit der Begründung, dass ich wegen einer zu hohen
Anzahl an Verbindungen temporär gesperrt bin. Der server ist news.cis.dfn.de .
individual.net und news.cis.dfn.de werden beide von der FU Berlin betrieben.
Kann ich etwas tun. um zu helfen. das Problem zu debuggen?