port 80 landet netzwerkintern immer auf router gui

[Osiris1]

Die Reihenfolge war:
- 3.2.3# Resetten: hat nichts gebracht
- 3.2.3# ports routing umstellen 81-->80: php server funktioniert. ssh und linkstation aber nicht
- 5.3.5# firmware downgrade: ssh funktioniert auch wieder. nas scheint auch wie vorher zu funktionieren.

Ich weiß aber nicht mehr welche Firmware ich vor dem Probleme machenden Upgrade gehabt habe.

Konfiguriert habe ich es immer als 192.168.0.1 ip (Server war immer 17)

shark traces kann ich leider nicht anbieten, da meine Probleme mit dem Downgrade gelöst wurden. Soll ichs trotzdem mit sharky versuchen und dir die Ergebnisse schicken, obwohl jetzt alles zu funktionieren scheint?

Hab adsl.

[zid]

wir kommen auf das thema pire = "stochastischer router" zurück...

hallo osiris,

der riddik is ein junge aus der hardcore fraktion und sitzt, wenns um beschissene probs geht, immer fußfrei in der ersten reihe. dank dir, riddik, wieder 'ne affengeile nummer. die kann echt was...
und was hat der riddik gemacht?
er wollte die von mir gewünschten traces ziehen, und das ging schief, weil, und jetzt bitte festhalten, bei ihm die E_3.2.3 *völlig* problemlos funkt!!
die details:

1. ausgangspunkt:
i. PRGAV4202N2 mit der fw. E_3.2.2
ii. webserver am standardport tcp/80 und mit ip 192.168.0.25/24.
iii. weiterleitung am pire: pub-ip:80 -> 192.168.0.25:80
iv. es funken:
- externer zugriff auf den server, selbst getestet.
- interner zugriff auf den server über die private ip.
- interner zugriff auf den server über die öffentliche ip, i.e. der früher beschriebene bouncer.
- icmp usw. unauffällig

2. und jetzt riddiks test: upgrade von E_3.2.2 auf E_3.2.3
i. nach dem upgrade *KEIN* reset.
ii. es funken:
- externer zugriff auf den server, selbst getestet.
- interner zugriff auf den server über die private ip.
- interner zugriff auf den server über die öffentliche ip, i.e. der früher beschriebene bouncer.
- icmp unauffällig.

3. wie passen die ergebnisse vom riddik ins gesamtgeschehen- eine hypothese, hab mim riddik ein paar stunden telefoniert.
wenn ich im folgenden von "a1community" rede, dann mein ich den von dir früher erwähnten faden in der a1community.
oberflächlich betrachtet ist man in der typischen situation "stochatischer router", probs lassen sich nicht so einfach reproduzieren, weil die sw. notorisch parametrisch instabil implementiert ist. das problem dürfte sehr selten auftreten, weil die diskussion in der a1community nicht lang ist und der A1_Hermann auch schreibt, daß die experten es gar nicht bemerkt hätten.
d.h. eine ganz bestimmte, eher exotische kostellation und/oder eine bzw. ein paar wenige anwendungen, die nicht oft zum einsatz kommen, stören das bridging/switching des pire. routing prob ist es keins, weil im lan nicht geroutet wird.
sehr aufschlußreich sind deine pings und vor allem diese bermerkung vom Kurtiii in der a1community:

"...Interesanter weise ist das Problem zu lösen inden man diesen Rechner dauer pingt (ping x.x.x.x -t).
Dann funktioniert die Verbindung Porblemlos...

dauerpings auf den rechner x.x.x.x halten am pingenden rechner den arp eintrag von x.x.x.x am leben, is wie ein statischer eintrag für x.x.x.x. es gehen in dem fall keine arp requests raus und deshalb vermuten wir, daß das pire die arp requests und/oder arp replies nicht sauber weiterleitet, und dann kommts genau zu den beschriebenen effekten. das hättest du sehr einfach nachprüfen können:
- mit "ip n" im arp cache nachschauen, obs einen eintrag für den rechner x.x.x.x gibt und welchen nud state er hat (nud = network unreachability dedection).
- mit dem früher erwähnten "ip n add" statischen (nud = permanent) arp eintrag für den x.x.x.x setzen.
versuchsdauer ca. 1 min. und da brauchts nicht mal den shark.

für das tcp/80-prob haben wir keine erklärung, ist möglicherweise noch ein zweites (überlagertes) prob. da wären die shark traces wirklich wertvoll gewesen.
insgesamt gibts eine traurige facette in der ganzen gschicht:
der A1_Hermann hat zwar ein ticket geöffnet, und die experten der ta werden hoffentlich nachforschen. wenns aber blöd hergeht- und das prob ist selten- werden sie wie der riddik gar nix sehen, und dann wird der bug weitergeschleppt...
und dann gibts noch den ökonomischen aspekt:
ich weiß jetzt net, auf wievielen geräten die 3.2.3er im einsatz ist, 100k+ werdens wohl schon sein. und dann gibts bei pi mal daumen 10 usern ein obskures prob, das eine sehr tiefgehende analyse brauchte, weil von den betroffenen keine sauberen analysen vorliegen. ökonomisch der helle wahnsinn...


>"...Soll ichs trotzdem mit sharky versuchen und dir die Ergebnisse schicken, obwohl jetzt alles zu funktionieren scheint?..."
nein, diese trace wär nur als vergleich interessant. und da beim riddik alles funkt, hamma nix zum vergleichen...


>"...Hab adsl..."
ok, dann bist du eh auf der sicheren seite und kannst im notfall auf ältere sts/tgs (st546v6, tg585v7...) zurückfallen, bei denen es noch nie bridging/switching probs gegeben hat und die dir heutzutage fast zum nulltarif nachgeschmissen werden.


lg
zid

[rwhome]

sherlock-wolf der netzlerei in aktion
habt ihr auch berücksichtigt das es zwei revisionen des pire gibt (ax/bx)

bei mir hat auch alles gefunkt ... hatte nur mit bx getestet (grüne voip ports , ax hat rote)
hatte bei meinen test allerdings alles an einen switch dran ... fürchte daher der test ist diesbezüglich nicht relevant

[Riddik]

habt ihr auch berücksichtigt das es zwei revisionen des pire gibt (ax/bx)

Nein, da aber ohne genauere Infos dies nicht nachvollziehbar ist, wird das
wohl eher in den Tiefen des Forums untergehehen

[Osiris1]

Wow. Ich bin beeindruckt. Das übersteigt inzwischen meine (bescheidenen) Netzwerkfähigkeiten.

Gut, wenn der Fehler wirklich so selten ist, liegts vermutlich echt an irgendeiner eigenartigen Konstellation. Bei mir sieht das ganze Netzwerk ca so aus:

- A1Router
- 2 D-Link Router (fixe ip, nur für wlan)
- 2 weitere Switches (Netgear 100mbit, D-Link 1Gbit)
- ein oki drucker
- ein Buffalo Linkstation NAS
- ein RaspberryPi
- ein Intel Nuc
- PC's und Laptops

- Ein PC's hält die Linkstation am Leben sofern der PC gestartet ist (ich schätze das wird normales wakeonlan sein, weiß aber nicht was die Software von Buffalo genau tut)
- RaspberryPi (KANN auch regelmäßig wakeonlan an die Linkstation senden)
- Intel Nuc sendet regelmäßig wakeonlan an die Linkstation wenn eingeschaltet

Vielleicht hats was damit zu tun. (Hab eine Zeit lang das NAS auch ganz ausgeschaltet gehabt und die putty Probleme waren weiter vorhanden)

EDIT: Gibts sonst Infos die ich euch nicht vorenthalten sollte? Da hier scheinbar schon ein paar Leute recht viel Zeit investiert haben, wäre es schade wenn am Schluss das Problem trotzdem nicht eingegrenzt werden kann.

[zid]

glatt verschätzt, schöner mist...

hallo osiris,

ich hab früher die anzahl der in betrieb befindlichen e3.2.3er mit 100k+ mal grob nach unten abgeschätzt, und diese abschätzung war net so guat.
jetzt hab ich nachgefragt. ergebnis: aktuell sind ziemlich genau 400k pires mit der e3.2.3er unterwegs.
und dann gibts pi mal daumen 10 hansl, die damit zoff haben...
frage somit: wieviele ppm, von "promille" kann in dem zusammenhang ja nicht mehr die rede sein, sind
(pi mal daumen 10 hansl)/(pi mal daumen 400k hansl)?
unterm strich ist das ganze in unsrem privatjargon ein sog. "high-low-problem".
severity: high, weils um (mindestens) eine grundfunktion geht.
priority: low, weil nicht viele leute davon betroffen sind, es passiert nur in exotischen konstellationen, und es gibt einfache workarounds, s.u.

>"...EDIT: Gibts sonst Infos die ich euch nicht vorenthalten sollte?..."
ja, wie sind die router/switches geschaltet? welche komponenten hängen *direkt* am pire?
eine kleine skizze deiner netztopologie wäre echt hilfreich, und das muß jetzt net so'n meisterwerk von kaliber leonardo da vinci 4.0 aka stoneii sein, man sollte nur sehen können, wo welche komponenten angesiedelt sind (ascii art genügt, aber auch openoffice calc/excel/... sind sehr praktisch für solche darstellungen).
mehr kannst du jetzt im nachhinein sowieso nicht tun. mit deinem downgrade hast du dir etwas luft geschaffen, robust ist dein system jedoch nicht. du solltest den spielraum dazu verwenden, robuste alternativen anzudenken. es könnte nämlich durchaus das folgende szenario ablaufen:

- die experten der ta können dein prob nicht reproduzieren oder schaun gar nicht nach, weils halt ein "trauriges minderheitenschicksal" is.
- das prob wird in neue fw-versionen weitergeschleppt (ist schon vorgekommen, ich spiel jetzt net die leere menge durch).
- die ta aktualisiert aus irgendwelchen gründen irgendeine sw. ihrer infrastruktur.
- durch die änderung der sw. auf ta-seite ist auf kundenseite ein upgrade der cpe-sw zwingend erforderlich.
- das upgrade bei den kunden wird auf biegen und brechen durchgeführt und bei dir machts "auf einmal" wieder *bumm*...
- so, und dann bist du mit einer sehr unangenehmen situation konfrontiert:
du hast lokal nix verändert, und auf einmal geht nix mehr- im ersten moment denkt man dann fast immer an ein defektes gerät.
- nach 1, 2d kommst du dann doch drauf, daß die ta ein (technisch notwendiges) upgrade auf deinem cpe durchgeführt hat- viel vergnügen...

was also tun in dieser äußerst lustigen situation, die dir sogar kostenlos- du mußt wirklich nix zahlen, des is jetzt ka schmäh- ins haus geliefert wird? einige workarounds wurden ja schon genannt, der einfachste kommt aber sicher vom Kurtiii, der in der a1community das schreibt:

"...Ich habe mal test halber alle Geräte auf eine normalen Switch angeschlossen da waren keine Probleme!..."

idee ist klar: wenn die bridge und/oder der switch des pire einen klescher haben, dann verwend ich das zeugs einfach nicht, punkt.
so gesehen relativ viel lärm für nix, wir sind wirklich bei priority low...

in deinem kleinen netz hätte eine systematische suche durchaus sinn gemacht, vor allem wenns ums eigene netz geht, weil du da nicht fremdbestimmt bist. du kannst die zeit und auch die vorgehensweise frei bestimmen. kein termindruck u.ä,, gar nichts...
also einfach kontrollrechner + server ans pire und dann jede komponente deines netzes zuerst mal einzeln durchtesten. wenn du bei diesem test nix findest, dann isses ein gekoppeltes problem, i.e. der traffic zwischen 2 oder mehr komponenten schießt das pire ab. und das siehst du, wenn du *schrittweise* von 0-betrieb auf normalbetrieb gehst. spätenstens da machts irgendwann mal bumm, sonst würde es ja keine probs geben.
dann nur noch problem endgültig eingrenzen, appetitlicher bericht mit problembeschreibung + testbeschreibung + outputs der verschiedenen tools, die du bei den tests verwendet hast, an den support der ta. die experten müßten sich nimmer mit problemreproduktion und -identifikation rumschlagen, sondern könnten gleich zur tat schreiten, weil du bei sauberer arbeit wirklich alles aufm silbertablett frei haus liefern kannst, der vorteil von kleinen netzen... sowas wird ernstgenommen und allen wär geholfen.


rwhome,

>"...habt ihr auch berücksichtigt das es zwei revisionen des pire gibt (ax/bx)..."
ich geh jetzt mal davon aus, daß das rot-grün-geplänkl nicht parteipolitischer natur is, sonst müßt ich wirklich noch mit einem pire-schwarz, das gibts wirklich, aufkreuzen, um dem österreichischen proporzsystem gerecht zu werden...
spaß beiseite, der riddik hat folgendes gemacht:
pire: grün
wartungsrechner: schlankes win xp
server: auf basis debian, tcp/80.
alles direkt am pire und nullo probs.

>"...hatte bei meinen test allerdings alles an einen switch dran ... fürchte daher der test ist diesbezüglich nicht relevant..."
ja, leider. mit dem switch umgehst du die potentiell gebrochene bridge des pire, s.a. den test/workaround vom Kurtiii.
- zuerst direkt am pire testen.
- arp is im fadenkreuz, also nicht vergessen, vor jedem test den arp cache des kontrollrechners zu flushen, weil du dir sonst artefakte einhandeln könntest.
- sehr interessant ist das tcp-80-prob. hab jetzt schon mit einigen leuten darüber diskutiert, wirklich erklären kanns keiner. im grunde genommen gehts um die frage, wann und wie die umleitung abläuft. das würde man mim shark sofort sehen, wir reden also über *genau einen* click, und niemand machts. jeder furz wird heutzutage angeklickt, aber nur nicht der button vom shark. ich schnalls net...


lg
zid

[rwhome]

hallo zid,

ich mache die politik für vieles verantwortlich ... aber dafür ist sie nicht zuständig

würde mal sagen es sind mehr als 10 die ihr a1 modem alle daumen lang aus/einschalten weil es nicht mehr funkt
es ist ja nicht nur das pirelli betroffen ... z.b. auch das dv2210
auch da gibt es seit längerer zeit benutzer welche berichten das die netzwerkkommunikation einschläft
vielleicht ist es da 'nur' ein dhcp problem

da ich diese probleme früher schon nicht nachvollziehen konnte habe ich auch nicht mehr ernsthaft weitergetestet
vielleicht liegs an bestimmten chargen (bauteile mit anderen toleranzen) oder an einem schwachen netzteil (da gabs auch schon tolle effekte) oder halt an der jeweiligen netzwerkkonstellation (vorrangig haben anscheinend linux geräte ein problem)

das tcp-80-prob. kann man eventuell forcieren indem man das captive portal am pire aktiviert (welches übrigens auch nicht so funkt wie vorgesehen)
gibt auch mit dmz (exposed host) probleme

habe mir gerade ein tg588 bestellt und verbanne das pirelli auf ewig ... arrivederci pirelli
ein dv2210 kommt mir nicht ins haus

[trox]

Also damit ich das richtig verstehe, du verbindest dich auf deinen internen Webserver (192.168.0.17:80) und wirst dann auf deine No-IP URL weitergeleitet?

Kannst du deinen Webserver temporär so umstellen, dass nur eine einfache HTML Testseite geliefert wird? Für mich hört sich das eher nach einer HTML Weiterleitung an.

[zid]

hallo jungs,

rwhome,

>"...würde mal sagen es sind mehr als 10 die ihr a1 modem..."
jaja, betonung liegt auf "pi mal daumen", verstehs einfach metaphorisch...

>"...vielleicht liegs an bestimmten chargen (bauteile mit anderen toleranzen) oder an einem schwachen netzteil..."
das is schon ein altes thema. die dinger müssen immer mehr können und dürfen net mehr als hausnummer 200, 300 eier kosten, weil sonst vati und mutti 'ne krise kriegen und das zeugs net kaufen. es geht kostenmäßig eine schere auf, die zu lasten der (fertigungs)qualität (egal ob hw. oder sw.) geschlossen wird. und dann gibts halt diese "seltsame" probs.
tjo, und vati/mutti glauben dann auch noch in ihrer geistigen umnachtung, daß neu nicht nur billiger, sondern qualitätsmäßig sogar besser is. so durchgeknallt mußt auch mal sein...

>"...das tcp-80-prob. kann man eventuell forcieren indem man das captive portal am pire aktiviert..."
ja, aber diese situation trifft auf den osiris nicht zu, falls ich jetzt nix überlesen hab. denn:
- er hatte irgendeine fw-version, an die er sich nimmer erinnern kann, am pire, und die welt war gut.
- die ta druckt ihm die e3.2.3 aufs aug, oder er zieht sie sich selbst rein, frei nach dem geistesgestörten motto "neu is besser". und dann machts bumm, ohne daß er auf seiner seite irgendwo konfigurationsänderungen vorgenommen hätte...

>"...habe mir gerade ein tg588 bestellt und verbanne das pirelli auf ewig..."
bin auch grad am eliminieren der pires in einigen netzen mit guest zones u.ä., *grml*
da ziehst einen extrem anspruchslosen ansatz auf (nixi vlans, bridge separation oder ähnlicher chichi, sondern einfach nur 'ne mischung aus router und router-on-a-stick am nachgeschalteten dialer), weil ein pire im spiel ist und das risiko rausgenommen werden muß, und dann stellt sich heraus, daß das einzige, das bei diesem pimperlansatz für den inetzugang aus dem private lan von vitaler bedeutung is, nämlich die lan-bridge des pire, nicht robust is. knickt die lan-bridge des pire ab, dann is das private lan off.
besser gehts nimmer. den dialog mim anschlußinhaber, der in dem fall sicher kommt, kann ich mir so richtig gut vorstellen:
"...du, wo, mia kumma auf amol nimmer ins inet, bei die gäst gibts oba kane probs. was kennt des sei? und was suin ma jetz mochn...?"
"...ganz einfach. du haust deine gäste raus und ziehst mit deiner family in eure gästezimmer um. ein kleiner, hausinterner umzug wird ja wohl net das prob sein?..."

die pikanterie bei der ganzen gschicht:
wenn der osiris nicht dieses prob gehabt und ich nicht zufällig seine posts gelesen hätte, dann wüßt ich gar nicht, daß diese netze auf einem pulverfaß sitzen...

vom tg588 hört man aktuell nur gutes:
der dsl-treiber der neuen r10.5.4.w dürfte geradezu sensationell sein. damit ist der fahrplan aufgelegt...



trox,

>"...hört sich das eher nach einer HTML Weiterleitung an..."
es gibt im zusammenhang mit dem/den osiris'schen prob/s eine menge unbewiesene hypothesen, an eine html-umleitung denken wir aber weniger, denn:

- ausgangspunkt: osiris mit igendeiner fw. aufm pire, und die welt is gut.
- es "passiert" aus irgendwelchen gründen ein update auf die e3.2.3, und die welt is nimmer gut.
- es gibt ein downgrade auf die tau5.3.5, und die welt is wieder gut.

wenn man jetzt davon ausgeht, daß der osiris net über den schwarzen humor verfügt, den ein paar wirklich sehr liebe freunde bei mir ab und zu an den tag legen, um mich aus jux und tollerei a bißl zu nerven, *die* jungs dürfen das *immer*, dann is 'ne html-umleitung auf seinem server im zusammenhang mit diesem prob kein thema...


lg
zid

[Riddik]

daß diese netze auf einem pulverfaß sitzen...

naja, das ist ja nicht geklärt was wirklich die Ursache war...
Du weisst ja eh, wie das mit dem beweisen der Schuld ist

[zid]

riddik, du lauser, tu mich jetzt net nerven...
es geht hier net um "schuld und sühne", sondern einfach nur die um frage, wie man bei wan-konstruktionen, die die lan bridge des pire vital brauchen, vorgehen sollte.
meine antwort: grundansatz so, wie er is, belassen und pire raus, s.a. die ausführungen vom rwhome.
und ich hab, wie du eh weißt, in den letzten tagen diesbezüglich kritische netzwerke bereinigt. die aktion is noch nicht ganz abgeschlossen, aber das wird schon...

lg
zid