port 80 landet netzwerkintern immer auf router gui

[Osiris1]

Was ich gemeint habe ist:

Ich gebe die normale ip ein. Die wird vom dhcp vergeben, sollte aber immer die gleiche sein (kann man ja irgendwo einstellen).

Dann wird das GUI geladen und die url ändert sich von der eingegebenen ip zur no-ip adresse (in der browser url leiste). Und ja das ist wirklich sehr merkwürdig.

Mich würde schon interessieren woran das Problem liegt. Ich weiß nur noch nicht wann ich dazukomme mir das anzuschauen. bin das Wochenende erstmal weg, werde mich aber nachher vielleicht dran setzen. Ich kann ja hier dann meine Erkenntnisse posten.

Neu gestartet hab ich das Pirelli noch nicht, da sonst der 24h disconnect zu einer Zeit stattfindet in der ich online bin. Aber ich werds nach dem we mal versuchen. (Muss ich halt nachher den Router nochmal neu starten damit der 24h disc wieder besser liegt).

[rwhome]

hallo Osiris1,

verwechsle bitte nicht reset (reset-knopf) mit restart = aus/ein
du kannst auch die funktion werkseinstellungen wiederherstellen benutzen im webinterface

viele user haben bei dieser firmware ein problem damit das die lan kommunikation 'einschläft'
interessant ist das es hilft wenn man einen switch anschließt

[Osiris1]

Die Werkseinstellungen werd ich aber so oder so nicht wiederherstellen. Da hängt zu viel dran, was weiter funktionieren sollte.

[rwhome]

wie du willst
du kannst auch auf eine neue firmware warten
und darauf hoffen das die einstellungen erhalten bleiben
was allerdings nicht viel nutzt wenn die durcheinander sind

[zid]

>"...Aber ich werds nach dem we mal versuchen..."
*sehr schön*, und falls es unklarheiten gibt, dann einfach fragen. es wär rein erkenntnismäßig wirklich wichtig, der sache etwas genauer nachzugehen. wenn wir uns schon ärgern, dann wollen wir wenigstens was lernen...
der rwhome hat vor längerer zeit in diesem forum im zusammenhang mim pire den begriff "pirellisieren" geprägt, und ich war damals ob dieser sprachgewalt ganz weg, wobei ich bis heute nicht weiß, ob er bei seinem wortkonstrukt "paralysieren" oder "tyrannisieren" im hinterkopf hatte...
egal: laß dich nicht pirellisieren, wir finden *sicher* eine lösung, die sauber funkt...

lg
zid

[rwhome]

hallo,

eher tyrannisieren
tyrannical sadist braucht masochist
ist an der zeit das man aufhört uns mit den adb dingern zu quälen

[zid]

okee, das sog. "hinterkopfproblem", das jetzt schon etwas länger im raum schwebt, wär damit auch gelöst. *der* faden kanns echt...
beim osiris muß die ganze chose aber schneller ablaufen...

lg
zid

[zid]

puh, hab echt in den keller watscheln müssen, um ein pire auszubuddeln...

liebe leute,

in meiner geistigen umnachtung is diese bemerkung vom rwhome komplett untergegangen:

>"...die epicentro firmware versionen unterstützen nat-loopback..."

ja, aber nur pseudo natloopback vulgo bouncing/reflecting. nixi true natloopback wie bei den sts/tgs.
nichtsdestotrotz ist meine aussage im abschnitt #2 dieses posts...
viewtopic.php?f=20&t=56636&#p468869
...kompletter schwachsinn :
ich komm noch drauf zurück.


die details:

0. hab ein kleines testbed aufgesetzt, das an einem tikerl hängt, weil man bei den tikerls sehr einfach mitsniffen und so das geschehen auf dem wartungsrechner, pire und server gleichzeitig mitverfolgen kann.

1. mein setup:
- e1-e6 des tikerl sind bridged, da passiert also überhaupt nix.
- e1: wartungsrechner mit der ip 10.0.0.145/24.
- e4: PRGAV4202N2 mit der fw. E_3.0.10 und der ip 10.0.0.138/24.
- e6: webserver mit standardport tcp/80 und der ip 10.0.0.1/24.

2. der test
- ich hab einen ddns-account bei spdns.de mit dem host ***.spdns.org, der zu 217.*.*.* aufgelöst wird.
- ich setze am pire eine weiterleitung für den tcp/80 auf den server 10.0.0.1, i.e. pub-ip:80 = 217.*.*.*:80 -> 10.0.0.1:80.
- ich greife aus dem lan mit dem wartungsrecher 10.0.0.145 auf den server über den hostname http://***.spdns.org und net über die private ip 10.0.0.1 zu. letzteres funkt sowieso- zumindest bei der E_3.0.10, bei der *sensationellen* E_3.2.3 aber halt nimmer lt. osiris.

3. die traces
- ich geh den 3-way-handshake für den tcp/80 des server anhand der traces durch.
- zeilen, die mit "# ***" beginnen, sind von mir eingefügte kommentare.

Code: Alles auswählen

> too sni pa p d
# ***
# *** SYN ***
# *** ein syn-packerl mit (src=10.0.0.145/dst=217.*.*.*:80) vom wartungsrechner kommt über e1 rein.
0 time=5.285 num=1 direction=rx interface=e1 src-address=10.0.0.145:51237 dst-address=217.*.*.*:80 (http) protocol=ip
   ip-protocol=tcp size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=54557 fragment-offset=0 ttl=64 tcp-flags=syn

# *** das tickerl leitet das packerl unverändert über den e4, an dem das pire hängt, zum pire weiter
1 time=5.285 num=2 direction=tx interface=e4 src-address=10.0.0.145:51237 dst-address=217.*.*.*:80 (http) protocol=ip
   ip-protocol=tcp size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=54557 fragment-offset=0 ttl=64 tcp-flags=syn

# *** am pire passiert das bouncing, das aus 2 schritten besteht:
# *** zuerst in der prerouting chain das dnat von 217.*.*.*:80 auf 10.0.0.1:80
# *** danach in der postrouting chain das masquerading der ip 10.0.0.145 auf 10.0.0.138, sodaß das routing dreieck voll genommen wird.
# *** ingesamt wird damit aus (src=10.0.0.145/dst=217.*.*.*:80) (src=10.0.0.138/dst=10.0.0.1:80).
# *** das derart modifizierte packerl kommt wieder über den e4 retour...:
2 time=5.287 num=3 direction=rx interface=e4 src-address=10.0.0.138:51237 dst-address=10.0.0.1:80 (http) protocol=ip ip-protocol=tcp
   size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=54557 fragment-offset=0 ttl=64 tcp-flags=syn

# *** der ccr übernimmt das packerl und leitet es über den e6 in richting server weiter:
3 time=5.287 num=4 direction=tx interface=e6 src-address=10.0.0.138:51237 dst-address=10.0.0.1:80 (http) protocol=ip ip-protocol=tcp
   size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=54557 fragment-offset=0 ttl=64 tcp-flags=syn

# ***
# *** SYN-ACK ***
# *** das syn-ack vom server mit (src=10.0.0.1:80/dst=10.0.0.138) kommt über den e6 rein und...:
4 time=5.287 num=5 direction=rx interface=e6 src-address=10.0.0.1:80 (http) dst-address=10.0.0.138:51237 protocol=ip ip-protocol=tcp
   size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64 tcp-flags=syn,ack

# *** ...wird vom tikerl unverändert über den e4 zum pire geschickt:
5 time=5.287 num=6 direction=tx interface=e4 src-address=10.0.0.1:80 (http) dst-address=10.0.0.138:51237 protocol=ip ip-protocol=tcp
   size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64 tcp-flags=syn,ack

# *** am pire wird das dnat/masquerading wieder rückabgewickelt. aus (src=10.0.0.1:80/dst=10.0.0.138) wird (src=217.*.*.*:80/dst=10.0.0.1)
# *** und das "restaurierte" packerl kommt über den e4 retour...:
6 time=5.288 num=7 direction=rx interface=e4 src-address=217.*.*.*:80 (http) dst-address=10.0.0.145:51237 protocol=ip
   ip-protocol=tcp size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64 tcp-flags=syn,ack

# *** ...und wird vom tikerl über den e1 zum rechner weitergeleitet:
7 time=5.288 num=8 direction=tx interface=e1 src-address=217.*.*.*:80 (http) dst-address=10.0.0.145:51237 protocol=ip
   ip-protocol=tcp size=60 ip-packet-size=60 ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64 tcp-flags=syn,ack

# ***
# *** ACK ***
# *** das spielchen vom syn wiederholt sich usw...
8 time=5.288 num=9 direction=rx interface=e1 src-address=10.0.0.145:51237 dst-address=217.*.*.*:80 (http) protocol=ip
   ip-protocol=tcp size=52 ip-packet-size=52 ip-header-size=20 dscp=0 identification=54558 fragment-offset=0 ttl=64 tcp-flags=ack

9 time=5.288 num=10 direction=tx interface=e4 src-address=10.0.0.145:51237 dst-address=217.*.*.*:80 (http) protocol=ip
   ip-protocol=tcp size=52 ip-packet-size=52 ip-header-size=20 dscp=0 identification=54558 fragment-offset=0 ttl=64 tcp-flags=ack

10 time=5.289 num=13 direction=rx interface=e4 src-address=10.0.0.138:51237 dst-address=10.0.0.1:80 (http) protocol=ip
   ip-protocol=tcp size=52 ip-packet-size=52 ip-header-size=20 dscp=0 identification=54558 fragment-offset=0 ttl=64 tcp-flags=ack

11 time=5.289 num=14 direction=tx interface=e6 src-address=10.0.0.138:51237 dst-address=10.0.0.1:80 (http) protocol=ip
   ip-protocol=tcp size=52 ip-packet-size=52 ip-header-size=20 dscp=0 identification=54558 fragment-offset=0 ttl=64 tcp-flags=ack

unterm strich also ein bouncer/reflector ("pseudo natloopback") und und kein true natloopback. der begriff "pseudo natloopback" ist leider eine unglückliche formulierung, weil eine loop suggeriert wird, die bei einem bouncer gar nicht vorhanden ist. ein bouncer ist nun mal ein routing dreick und eben keine loop.

so, und jetzt nur noch den dreck dieses posts aufwischen:
viewtopic.php?f=20&t=56636&#p468869
ich schreibe da, und !! DIESE AUSSAGE IST FALSCH !!:
"...2. pseudo natloopback, i.e. ein bouncer/reflector am lan-intf, kann nicht konfiguriert, weil die firewall des pires zu unflexibel ist..."

RICHTIG IST::
bei den e-fws. des pire wird beim setzen einer portweiterleitung im hintergrund automatisch der entsprechende bouncer eingerichtet, sodaß der zugriff auf lokale server über öffentliche ips möglich ist- falls die fw. halt net komplett verbuggt ist.

dank dir, rwhome.


zurück zu deinem thema osiris,

hab dein prob mit leuten diskutiert, die was von der materie verstehen, und die sind unisono der meinung, daß nach einem zwangsupgrade auf die E_3.2.3 ein reset vorzunehmen ist, weils sonst, mal ganz abgesehen von den inherenten hoppalas der 3.2.3er, zu "lustigen" effekten kommen kann. die ausgangskonfig wird nämlich nicht immer sauber übernommen...
das kann natürlich *sehr unangenehm* werden, wenn du vor der zwangsbeglückung eine offene fw. laufen hattest und da die konfig an deine anforderungen sehr individuell angepaßt hast.
praktikable workarounds:
- einfach und billig:
am pire auf su gehen und ein spielzeug, das die bezeichnung "router" verdient, als dialer nachschalten.
- einfach und nimmer ganz so billig:
wenn du kein zweites gerät laufen lassen willst, dann bleibt dir praktisch nur noch cisco übrig. mit bestimmten dsl-treibern sind manche modelle bei der ta white listed. und bei den ciscos kannst du nicht nur so ziemlich jeden furz ein- und verstellen, du bist mit einem service contract auch unabhängig von der ta, weil du dir damit *bei cisco* jederzeit die neueste und komplett offene sw. runterziehen kannst.


lg
zid



liebste jutta, *twitscher*, *twitscher*, *flöt*, *flöt*, *flöt*

ich hab wie üblich mist gebaut, net haun.
könntest du bitte den abschnitt #2 dieses posts...:
viewtopic.php?f=20&t=56636&#p468869
...bis auf die iptables-zeilen, die stimmen ausnahmsweise, ausgrauen und mit einem "//edit" auf die richtigstellung in diesem post verweisen?

dank dir & lg
zid

[Osiris1]

Phu nach dem Informationsoverload brauch ich glaub ich der Sache nicht mehr genauer nachgehen Weil ich nichtmal das bisher gepostete ganz verstehe (gut hab mich damit aber auch noch nicht beschäftigt).

Zum Reset:
Damit ist ein Factory Reset gemeint? Würde damit auch die always on Einstellung zurückgesetzt werden? Dann müsste ich nämlich auf jeden Fall wieder beim Support anrufen...

EDIT: Mein NAS spinnt inzwischen auch schon seit ein paar Wochen. Vielleicht hängt das auch mit dem Router zusammen. Andererseits haben die Linkstation noch nie wirklich als sonderlich zuverlässig gegolten.

EDIT2: Auch PuTTY ist unglaublich langsam geworden.

[Osiris1]

1. Ja. Der Restbutton setzt das always on zurück.
2. Ich musste zusätzlich einen Grund angeben warum ich diese Einstellung überhaupt benötige.

Erinnert mich etwas an das hier:
http://dietagespresse.com/a1-startet-gr ... verlieren/

Zum Putty Problem: Teilweise extrem langsam (hängt komplett und ist damit unbenutzbar). Hab aber keine Ahnung ob das was mit dem Router zu tun hat oder nicht. Müsste ich morgen mal unabhängig testen.

ahja:

Code: Alles auswählen

time host 192.168.0.*
;; connection timed out; no servers could be reached

real    0m10.151s
user    0m0.110s
sys     0m0.020s


umgekehrt kommt ca sowas raus:

Code: Alles auswählen

Ping wird ausgeführt für raspberrypi.home [192.168.0.*] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.0.*: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.*: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 192.168.0.*
    Pakete: Gesendet = 4, Empfangen = 2, Verloren = 2
    (50% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms


Kanns sein, dass da auch das Modem schuld ist? Was wurde da bitte zerschossen? *.*

[Osiris1]

Das Problem scheint weit verbreitet zu sein:
https://www.a1community.net/t5/Festnetz ... alse#M3690

[Osiris1]

So hab jetzt wieder die Firmware 4.8.3.DWVV_TAU_5.3.5.
Damit funktioniert das SSH wieder ohne Probleme. (Das NAS muss ich erst testen)

[wicked_one]

So hab jetzt wieder die Firmware 4.8.3.DWVV_TAU_5.3.5.
Damit funktioniert das SSH wieder ohne Probleme. (Das NAS muss ich erst testen)

Interessanter wäre, ob die neue Firmware sauber funktioniert, wenn sie nicht mit Artefakten alter konfigurationen zerlegt wurde...

[Osiris1]

Nein funktioniert auch nicht. Habe das Modem resettet und alles neu eingestellt. Gebracht hat das aber auch nichts.

[zid]

na seawas, der pöse seth is ganz schön am werken, jetzt brauchts wieder die isis und nephthys...

hallo osiris,

ich gehs nochmals durch, daß ichs auch versteh:
1. du hast die hl angerufen und ein downgrade auf die 5.3.5er durchführen lassen.
2. du hast mit dem *reset button* resettet.
3. neu konfiguriert mit
- adreßbereich fürs lan 192.168.0.0/24, server-ip wie gehabt 192.168.0.17
- server rennt am standardport tcp/80 und deshalb weiterleitung pub-ip:80 -> 192.168.0.17:80
- ddns
das war alles?
und was *genau* funkt jetzt net? welche fw. hattest du vor dem upgrade auf die e3.2.3? die 5.3.5er?
selbst auf die gefahr hin, daß ich mich wiederhole: wir brauchen shark traces, sonst diskutieren wir ins leere.
hab dir eine pn mit meiner mail-adr. geschickt, schick mir die *unveränderte* pcap, und falls noch traces mit der 3.2.3er vorliegen, die auch.
hast du einen adsl- oder vdsl-zugang?

lg
zid