Beiträge von gierig

Da muss nichts von außen nach innen weitergeleitet werden.

BlackSpy, in der Zeile verrutscht ? Deine Ports sind so mehr L3 MGMT

Egress (Exiting) Ports required for UniFi Remote Access
Note: In most cases, these ports will be open and unrestricted by default.

53
3478
443
8883
123

Egress also raus um es nochmal fett zu schreiben.

8883 raus ist der wichtige... eigentlich läuft darüber auch in kurzen abständen Traffic..

aber Vielleicht ist da was faul bei deinem Anbieter/ Router oder darf nicht wirklich raus...

Hehe, network 101 Kurs und Grundlagen aneignen ist die böse Antwort.

die liebe Antwort ist:

Alles was im "192.168.1.0/24“ Netzwerk ist kann auch auf alles im 192.168.1.0/24 zugreifen.

Dafür wird nicht ein bisschen dein Router (USG) bemüht. Die IP Pakete wandern direkt

dahin. (ganz vereinfacht: Rechner fragt der Broadcast wer die IP mus local sein weil gleiches netz, NAS

antwortet ich hier mit der MAC 1:2:3:4:5:6, Rechner macht Paket fertig und schickt es über Ethernet direkt

an die MAC)

Wenn du das über die USG steuern Wills, muss das NAS in ein eignes Netzwerk/Vlan mit einem eignen

IP Kreis (z.b 192.168.2.0/24). Dann kannst du über die FW regeln bestimmen wer oder wa darauf zugreifen darf.

Mit „Sollte Seuche“ meine ich das die RFC nicht wirklich bindend sind. Steht ja auch „SHOULD“

Zitat

Auch hier schau ich mal bei Gelegenheit, wie mein kleiner Bubble das handhabt (der leistet sich ja auch ein AON), vielleicht bin ich ja nur verwöhnt

So, die Gelegenheit passte gerade:

Vereinigte Stadtwerke ... Oft belächelt aber sehr oft sitzen genau da noch Menschen die es Interessiert

und nicht „Millionen“ von Anschlüssen verwalten müssen. Und dann machen die auch noch AON

(immer noch oder sind sie umgesattelt wenn die noch ausbauen)

Hab nun keine Ahnung von der 3CX.

Aber ja es sieht danach aus als wenn auf dem 9004 das Gespräch laufen könnte und der 9005 dann RTCP ist.

Im Grunde müsst mann sich aber INVITE und den Response anschauen also genauer

die SDP Header ob ein RTCP auch wirklich ausgehandelt wird oder da auch Daten drüber laufen.

Könnt mir durchaus vorstellen das 3cx das versucht und Ressourcen dafür bereitstellt

(den laut RFC soll es ja „RTP Port +1“ sein) und pauschal von sich sendet.

Der Carrier das aber Ignoriert verfallen lässt, nicht annimmt und seinerseits nichts Sendet

Aber wie gesagt, ohne auf Trace Level die Invites zu checken oder zu prüfen

ob traffic in beide Richtungen fließt ist es schwer zu sagen.

Kannst du ein SIP trace auf deiner Anlage durchführen. Der invite vom ankommenden Anruf des carriers

müsste genug sein um Klarheit zu schaffen.

Im SDP des INVITE gibt es dann das media Attribute „rtcp:portnummer“ ungefähr so:

Wenn da vom Carrier nichts kommt... will er das auch nicht

Zitat von Nubbler

Thread Management ist allerdings noch deaktiviert - Versuche ich dann noch morgen ob es einen negativen Einfluß hat (wenn ich das TElefon öfters klingeln lassen kann

Stand Heute sind keine O2 SIP IP den IDS Rules, sie tauchen auch nicht bei den ca. 1400 Firewall regeln auf die sich hinter „TOR und ALIEN“ Block verbergen.

Sollte das IDS was blocken siehst du es aber in den LOGS und zusätzliche die dann angelegt werden.

Anroste Glückwunsch auch wenns seltsam ist..

Zitat von bic

Für RTP (UDP) benötigt man mehrere Ports, bzw. mindesten zwei (einer als Sprachkanal und einer für die Statusinformationen), wobei aber hier ein Abstand von 4 Ports empfohlen wird.

Wer empfiehlt sowas ?

Üblicherweise wird der Sprachkanal auf einem graden Port aufgebaut und die RTCP auf den nächsten ungeraden.

Siehe RFC 3550 - Section 11

For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number.

Klar sollte Seuche und es muß sich keiner dran halten, aber offensichtlich wird ein von irgendjemanden empfohlen.

Aber um wieder auf ein Fuß zu treten:

Endkunden Carrier wie Telekom, Telefonica (o2), und die große Vodafon Bubble (UM, Kabel, Alice.),

sipGate uvm, werden einen Teufel tun und RTCP zu ihren Kunden schicken oder empfangen. Nachher steht da noch ein

schlechter MOS Score drinn und der Kunde fängt an zu reklamieren...und hat dann noch was in der Hand....

Nein nein nein... ein PORT für den Sprachkanal reicht. Alles andere wird überschätzt und braucht nur unnötige Ressourcen.

Zitat von Michael Drechsel

Auf jedes von diesen V-Lan kann ich mich nur noch einwählen wenn als V-Lan mein eigenes hinterlege.

WLAN Verbinden geht ?

Wenn ja:

Bekommst du eine IP oder wird eine 169.xx ?

Funktionieren die VLANS auf einem Netzwerkport mit Kabel an einem PC ?

Sprich einen Port auf das VLAN Stellen geht es dann ?

In Zeile 42 in deiner config findest du die Antwort…

ach ja Das ist hier nicht microcontroller Forum wo 24/7 200 Leute online sind und polierte Glaskugeln haben…

May Stupid Question: Welche Network Version hast du ?

Weil erst ab 7.0.20 gibt es wohl support für DHCP Delay für L3 Switche

"Implement L3 switch DHCP relay support."

Hab nie nen PRO mit L3 Funktion in den Finger gehabt im Unifi Universum..

aber:

DHCP Guarding aus (im Vlan Setup) Probiert ? Das hatte bei mir zu letzt Probleme gemacht als der DHCP noch auf einem CISCO Lief.

(das ging und war mit irgendein Update von einem USW 8 Poe kaputt...

DHCP Snooping (Netzwerk Global Switch Settings) macht da auch mal doofe Sachen...

ist ein test wert...

Schau auf den Port dein KODI spricht mit port 50606. Grep findet alles wo 5060 drinnen steht. Schau auf den DEST Port das ist 123

auf der 217.91.44.17

inetnum: 217.91.0.0 - 217.91.127.255

netname: DTAG-STATIC01

descr: Deutsche Telekom AG

descr: T-DSL Business static dial-up

pool.ntp.org: Statistics for 217.91.44.17

Ist ein NTP Server, Dein Kodi oder eher dein Raspi fragt die Uhrzeit ab...

bic, sorry wenn ich die auf die Füsse getreten bin das war nicht meine Absicht.

Nubbler

Firewall sieht gut, jedenfalls wenn die einzigen sind. Wenn du auf der UDM den IVITE siehts sollte su ih auch auf

deinem Mirror Port sehen. Wenn nicht wird er verschluckt oder geht woanders hin. (Fritze noch aktiv) ?

(sofern keine festen Weiterleitungen sollte "cat /proc/net/nf_conntrack | grep 5060“ auf welches ziel das Paket geht.

Steht hier nichts is die Tabelle schon wider gelöscht oder dein Telefon hat sich nicht rechtzeitig wieder refrescht.

Zur not halt die UDP Timeouts auf 15 min setzen, da ist LAAAANGE aber für ein test ganz angenehm)

Nun wird aber recht schwer „remote“ noch Tips zu geben.

bic

.....im Prinzip eine schöne Ausführung. Aber an der Realität ein wenig vorbei.

Kein Wort zu Registrierung Refresh, Session Refresh. der Tatsache das eben NICHT RTP direkt aufgebaut wird

sondern im Endkunden Business IMMER über den Proxy/SBC (genau über Media Gateway) gegangen wird.

Und nein JEDER Endkunden Carrier weis das seine Kunden zu 99%Hinter einem (p)NAT router sitzen.

Die SBCs können alle mit NAT umgehen und ignorieren Daten im FROM, Contact, PAI, SDP Media headdern

und senden es einfach an die IP die sich registriert hat. (im übrigen einer der Gründe warum keine direkte Verbindung

ermöglicht wird, Kunde für mit falschen IP kommen).

Damit eingehen funktioniert sind genau zwei dinge nötig:

• Die Registrierung des UAC am Proxy
• Das regelmäßige Senden von Informationen von UAC zu de Proxy damit das (p) nat die Verbindung nicht nach x Minuten vergisst.

Das passiert Überlichweise im Endkunden Geschäft über Neuregestrieren / Refresh der Anmeldung.

Fritzbox und andere können darüberhinaus (Verbindung offen halten) einfach SIP Pakete schicken

(Option Request ist das mittel der Wahl). Manchmal ist es nötig an der Timing der NAT Tabelle rumzudrehen

was hier schon das Thema war...

DER TO kann Raustelefonieren, sieht die INVITES ankommen auf der UDM und die Fritz!Box antwortet scheinbar mit leeren Pakete ist das aktuelle Thema. Da ist irgendwo was faul. Die frage ist bloß wo genau...

Zitat von bic

Also @TE - kümmere Dich um Deine Firewall

Um das nochmal deutlich zu sagen, nein hier ist alles gut soweit zu sehen ist.

Zitat von Lucascoco

wenn ich das Haus verlasse, habe ich öfter das Problem das die App auf IOS nicht auf Cloud umschaltet und man dann auch keine Benachrichtigungen bekomme.

Habe ich was verpasst ? Protect Meldet mir ganz fleißig die Klingel Versuche oder wenn er Bewegung an den Cams erreicht.

Das sind Push Notifikationen... das Pusch system läuft doch unabhängig von der app (außer das die das halt steuert)

die Notifications werden über die Apple server zu dir geschickt...

So der erg is: Protect will was melden, schickt dann (über die Unifi server) an die Apple Pusch server zurück zu deinem Gerät

das sich den „Push Kanal“ abonniert hat...

Könnte es sein das deine Büchse länger braucht um zu registrieren das kein gutes Wlan da ist und voll auf mobil

Empfang umschaltet ?

Klassiker und bestimmt schon jeden mal passiert.... Copy und Paste nicht wahr ?

Moin,

Auszubildender ? Möglicherweise will dich irgendwer zum nachdenken bringen mit der Aufgabenstellung.

Zitat von JulianW

Wir haben eine Standleitung der Telekom mit 255 festen IP Adressen

Mus eine sehr alte Leitung sein und ihr ein großer Laden der gegenüber dem RIPE erklären kann warum

er soviel IP benötigt. Neue (seit 10 Jahren ?) Standleitungen kommen üblicherweise mit

einem /29 oder /30 Netz, bei den aber 1-3 auf dem/den Router bleiben als Gateway/Failover..

Anyways Spielen wir mit:

255, also sagen 254 weil ein Gateway auf dem Telekom Router.

Die USG hätte gerne mindestens 1 davon den sie macht von Intern auf Extern (p)NAT welches nicht

vorgesehen ist abzuschalten (auch wenns geht). Damit ist es dann schon mal nicht möglich die IPs direkt

zu verfügung zu stellen. Nun gut, auf den WAN Interface lassen sich „zusätzliche“ IP einstellen. Die

jeweilige lässt sich dann in den Lokalen Netzwerken auswählen als Weg raus..

24 Ports ein Uplink macht dann 23 Mögliche Ports,

Also 23 Netze eingerichtet in 23 unterschiedlichen VLAN, diese dem jeweiligen Port

zu weisen. Jetzt nur noch mit Portweiterlitungen und Firewall Regeln alles

voneinander abschotten. Wobei ich garnicht weis ob die Portweiterungen bei UNFI

mit den ganzen externen Adressen umgehen kann...

Fertig is eine eher fragwürdige Konstruktion mit Lehrcharakter.

Zitat von hoppel118

Hast du ein 3V Akku mit passendem Ladegerät als Beispiel?

Rapthor Arlo Camera Wiederaufladbare Akkus 850mAh Kompatibel mit Arlo Wireless Security Camera 3V Lithium-Akku mit Ladegerät (4pcs)

USB-Akku, konstante Spannung für Hochstromanwendungen. 500 Zyklen Zeit und geringe Selbstentladung – lange Akkulaufzeit. Rapthor Akku kann bis zu 500 Zyklen…

amzn.eu

(wahlloser erster Treffer, evt. nicht der vertrauenswürdige...)

3Volt mit micro usb Anschluss zum aufladen..Haben halt grob halb so viel Ladung wie ne Einweg Batterie.

fraglich ist auch ob Akkus besser halten in solchen Geräten.

Zitat von luxlicht

Es könnte so einfach sein wenn nicht immer jeder sein Ding machen müsste

Stimmt also warum willst du dein eigenes Ding machen

Ich will noch nur 150tausend mal den gleichen Anschluss verkaufen. Schon doof genug passendes Personal

zu bekommen für den support auf den ich keine lust habe und nur Geld kostet. Aber na ja billiger wird

es wenn meine Palette nicht so gestreut ist. Und der support schneller ans Telefon kommen kann.

also bei gibt nur Fritz box und JediBox 1.4. Dafür ist auch die Technik ausgelegt.. diese 1% Prozente Individualisten

und Pseudo nerds nerven nur. Die will ich nicht und schon garnicht sollen die mit ihren Spielzeug an meine Leitung.

Nicht das die da noch das ganze Segment tot leuchten und ich hier auf einmal einen wütenden Mop vor der Tür

stehen habe die kein Internet haben. Währe peinlich wenn die aus der VieleLeute Straße rausbekommen

das ich Ihr GPON glas 20% Überbucht habe...Ne ne Ne ne Reicht wenn meine Vertriebler und mein Support wissen

wie die die Friztbox Seite aufbekommen. Passwörter reicht das PPOE schon schwer genug für die meisten

inklusive meinen support) Dann vielleicht noch GPON/ONT authentifizierung ? nein danke, ich bin die telekom mit ihrer

Hardwarekennung, Anschlusskennung, Teilnehmer Kennung, Teilnehmer Nummer und einen Passwort das länger

als mein P.... ist.

Nun Im Datenblatt steht:

"Lithium Battery CR123A"
Das ist eine Drei Volt Zelle.

die 3,7 dinger im CR123 Busweise sind Li-ion Akkus, wenns da nicht steht dann eher nicht nehmen.

Wenn ich nicht nicht irre dann sind das auch eher Hochstrom dinger die es nicht so mögen wenig belastet zu werden,

Es gibt aber auch 3 Volt Akkus in der große die auch ausdrücklich auf Low energy ausgelegt sind.

Mhhh mal durch den nichtvorhandnen Bart raufen und über das bisherige sinnieren.

Zitat von Nubbler

Nur Zufall das die FritzBox und das Gigaset die gleichen doofe Dinge machen?

Nein wohl eher nicht. Ich habe zwar schon Dinge gesehen, die ihr Menschen niemals glauben würdet.

Gigantische Schiffe, die brannten, draußen vor der Schulter des Orion. Und ich habe C-Beams gesehen,

glitzernd im Dunkeln, nahe dem Tannhäuser Tor. Aber zwei Geräte unterschiedlicher Hersteller die spontan

den gleichen Grütz machen ? Nein...

- hast du irgendwie aktive Komponente (switch, bridge, etc) zwischen UDM und deiner Fritz/Gigaset ?

- Du hast Neustarts durchgeführt, aber hast du auch mal den Stecker gezogen ?
- Irgendwelche Firewall regeln auf die UDM eingetragen (je nach IDS trägt das ding da auch selber regeln ein)

Wobei letzteres eher der letze Strohhalm ist. Die Pakete gehen ja raus. Firewall würden sie vernichten auf den weg raus.

Aber nicht „leeren“ und weiterleiten ( und tcpdunp sollte Pakete for eher Firewall Capture) aber mit diesen

ganzen hardwareOffloadSwitch halb ins OS Integriert weis Man ja nicht...

Im Grunde würde ich man in the mittel machen und zwischen UDM und Fritz noch einen switch hängen auf

dem ich den traffic Spiegeln kann auf einen dritten port und dann von da mitzuschneiden..

Von Gefühl ist es nun doch eher die UDM die das was macht...auch wenn sie das so nicht sollte...

Firewall und Stecker ziehen...

schon seltsam...

Keine Ahnung von Fritz Boxen, meine letze wurde noch mit Dampf betrieben und durfte ähnlich wie deine

noch als TK Anlage einige Zeit mitspielen. Das müsste ne 7170 von 2005-2006 gewesen sein...schwarz mit

1und1 logo aber noch ohne software Branding... ach das waren noch unschuldige Zeiten

aber

- Neustart

- SIP kram löschen / neu Anlegen

- Werkseinstellungen

- FW neu draufbüglen

gilt ja grob für alles

Für deine Sicherheit und zum Doppelten check, gleicher trace und dann mal

Raustelefonieren. Im trace solltest du dann die „SIP“ Pakete sehen diesmal halt

der invite von deiner box in Netz und die passenden antworten zurück.

Kick an

UDM sieht alles gut, ja die RTP regel ist unsinnig weil kommt so eh nicht zum tragen. Die SIP regel ist

eigentlich auch unnötig, schadet aber nicht solange du ein SIP gerät im netzt hast das nach extern will

über den 5060 port...

Der trace schaut aber gut aus:

Calls zur FritzBox, irgendwas will auch aus der Fritz Box wieder zurück zu Ip der Anruf herkommt

Das sieht aber nach Grütze aus. Da sollte sowas wie ring/try/ack auftauchen und nicht

leer bleiben. Ggf ins Paket reinschauen (wird unten angekauft sonst doppelklick)

nach Ethernet, IP, UDP frame sollte SIP auftauchen mit infos drinnen.

Aktuell nach Aktenlage macht deine Fritzbox doofe dinge und antworten nicht richtig.

Auf die schnelle wie es aussehen sollte / kann

Ob bei dir nun ein Training//200/Ringing/183 steht mag variieren je nach SIP Geschmack.

Aber irgendwas in der Art muss zurück gehen...

Ahh sieht doch schon ganz gut aus...

Dein Carrier schickt dir INVITES zu dir, versucht sich also zu erreichen. Und es gibt im ersten trace

zumindestens irgendwas das auch wieder zum carrier zurück geht. Das ist grob schon 50%

Die frage ist wer oder was der anfrage antwortet...

Hätte ich gleich so schreiben sollen

tcpdump -i any -s 0 -w /root/trace.pcap port 5060

Das zeichneten traffic für alle Schnittstellen für port 5060 auf.

Da solltest du dann auch traffic von und zu deiner Fritzbox sehen.

und die antworten...

Hattest du die UDM nach entfernen von TALK gebootet ?

mit netstat -tulpen | grep 5060 kannst du sichergehen das nicht auf der UDM

auf der 5060 lauscht (Ausgabe sollte leer bleiben).

bzw (bin nicht 100%ob die ganze Zeit zu sehen ist)

cat /proc/net/nf_conntrack | grep 5060

SOLLTE eine Zeile auftauchen wo die Fritzbox ip und die carrier ip erkennst (62.x.x.x in deinem fall)

BTW, ich finde Port Weiterleitungen nötig. Können aber helfen wenn man eh nur eine Anlage hat.

Aber deine RTP weitlerleiting von port 5004-5020 is grober Unfug.

Im zweiten trace m=audio 10472 RTP/AVP 96 9 97 8 98 99 möchte der Carrier über PORT 10472

mit dir sabbeln.