WRT54G/DD-WRT v.24 -> Milkfish; für wen/wie/was? hat wer erfahrungen?

[schattenmann]

hoi zäme

hab mir die neueste dd-wrt auf den wrt gezogen; diesmal die voip-version.
nun wollte ich den milkfish ausprobieren, zögere jedoch etwas - es hat lange gedauert bis mein gigaset (c475ip) so funktioniert hat wie es soll...

bevor ich mir also die konfiguration zerschiesse, wollte ich mal fragen wer von euch den milkfish im einsatz hat, und - vor allem - was man damit machen kann...

bisher weis ich:
- milkfish fungiert als outbound-proxy
- wenn man sich im milkfish-forum anmeldet, kann man milkfish mit homesip verbinden, und mit spez. konfiguratin (usern/aliases/etc) auch sip-uri's direkt anwählen und kann mit homesip-uri angewählt werden...
- interne gespräche von client zu client läuft über den milkfish, nicht über's wan

was ich nicht ganz verstehe:
- inwiefern macht milkfish den wrt zu einem "sip-aware"-router? so wie ich das verstanden habe, muss man den eingehenden (sip)verkehr immernoch in der FW frei schalten, da mf sich nur für den outbound-traffic zwischenschaltet...
- was für funktionen lassen sich noch dem milkfish übergeben/hat es für einen 0815er-user (nur 1 mobilteil am gigaset, keine internen gespräche) weitere vorteile?

(was mir wichtig wäre:
- QOS. ich hab zwar qos eingerichtet, jedoch will das nicht so richtig; da meine leitung 200up/2000down hat, wäre es für mich wichtig das im upstream (down is immer satt zur verfügung) eine gewisse bandbreite für voip reserviert wird; mit den normalen qos-regeln hab ich es versucht, dies stellten sich jedoch als quelle für die meisten meiner lan-probleme heraus)
- sip-uri-erreichbarkeit; zum testen würd ich dafür den mf gerne paralel laufen lassen und die jetzige gigaset-konfig beibehalten, wenn dies "gut geht")

wär schön wenn jmd mit milkfish-dd-erfahrung diese teilen könnte; im milkfish-forum hab ich leider nichts in dieser richtung gefunden...

gruss,
der schattenmann

 

[Pingpong]

wenn man sich im milkfish-forum anmeldet, kann man milkfish mit homesip verbinden, und mit spez. konfiguratin (usern/aliases/etc) auch sip-uri's direkt anwählen und kann mit homesip-uri angewählt werden...

Der Sinn von diesem homesip erschliesst sich mir bisher nicht ganz. Der Dienst dient ja nur dazu unter einer URI anrufbar zu sein. Das gleiche kann man auch mit einem dyndns Account erreichen, dazu brauche ich keinen fremden Dienst von dem ich nicht weiss wie zuverlässig der funktioniert.

- inwiefern macht milkfish den wrt zu einem "sip-aware"-router? so wie ich das verstanden habe, muss man den eingehenden (sip)verkehr immernoch in der FW frei schalten, da mf sich nur für den outbound-traffic zwischenschaltet...

Milkfish ist ein Application Layer Gateway (ALG) für SIP. Es besteht aus einem SIP-Proxy und einem RTP-Proxy. Auch der ankommende Verkehr wird durch den Proxy geleitet. Auf Port 5060 lauscht ein SIP-Server der ankommende SIP-Requests verarbeitet. Die SIP und SDP Nachrichten werden so modifiziert dass sämtlicher Verkehr (SIP und RTP) immer über den Milkfish läuft.

hat es für einen 0815er-user (nur 1 mobilteil am gigaset, keine internen gespräche) weitere vorteile?

Der Hauptvorteil ist, dass der Router ein ALG für SIP hat, und so erst zuverlässig funktionierendes VoIP hinter NAT möglich wird. Alle anderen Workarounds (STUN in Verbindung mit Portfworwardings usw.) sind stark von der Art des eingesetzten NAT abhängig. Bei Port restricted Cone NAT (die heute am häufigsten verwendete Art) kann STUN prinzipiell nicht zuverlässig funktionieren (weil die STUN-Abfrage selbst bereits ein Mapping im Router erzeugt und der nachfolgende SIP Verkehr auf einen anderen Port umgeleitet wird solange dieses Mapping aktiv ist).

- QOS. ich hab zwar qos eingerichtet, jedoch will das nicht so richtig; da meine leitung 200up/2000down hat, wäre es für mich wichtig das im upstream (down is immer satt zur verfügung) eine gewisse bandbreite für voip reserviert wird; mit den normalen qos-regeln hab ich es versucht, dies stellten sich jedoch als quelle für die meisten meiner lan-probleme heraus)

Für QoS gibt es im DD-WRT Wiki eine gute Anleitung. Begrenze den Upstream auf 85% deiner Bandbreite und priorisiere das Telefon über seine MAC-Adresse. Was für Probleme hast du denn im LAN mit QoS? Das dürfte da eigentlich gar nicht eingreifen.

- sip-uri-erreichbarkeit; zum testen würd ich dafür den mf gerne paralel laufen lassen und die jetzige gigaset-konfig beibehalten, wenn dies "gut geht")

Nein, das geht nicht gut. Im Telefon muss der MF als Outbound Proxy eingetragen sein, und alle NAT-Workarounds (STUN etc.) im Telefon abgeschaltet sein. Keine Portforwardings am Router!
Um über SIP-URI erreichbar zu sein, richte dir einen Dyndns Account ein und konfiguriere den DDNS Updater. Trage deine dyndns Domain im Milkfish als "From-Domain" ein und deaktivere den Homesip-Kram.
Im SIP phonebook siehst du den User mit dem sich dein Telefon registriert hat. Angenommen der lautet "buero" und deine Dyndns Domain ist "zuhause.dyndns.org", dann bist du mit "sip:[email protected]" anrufbar.

 

[schattenmann]

Der Sinn von diesem homesip erschliesst sich mir bisher nicht ganz. Der Dienst dient ja nur dazu unter einer URI anrufbar zu sein. Das gleiche kann man auch mit einem dyndns Account erreichen, dazu brauche ich keinen fremden Dienst von dem ich nicht weiss wie zuverlässig der funktioniert.

So wie ich das verstanden hab, ist homesip zwecks "einfachste Konfiguration" eingeführt; nichts anderes als dyndns, man muss aber nur bn/pw eintragen, homesip aktivieren und gut ist... (für jemanden der sich zuwenig mit auskennt sicher nicht schlecht)

Milkfish ist ein Application Layer Gateway (ALG) für SIP. Es besteht aus einem SIP-Proxy und einem RTP-Proxy. Auch der ankommende Verkehr wird durch den Proxy geleitet. Auf Port 5060 lauscht ein SIP-Server der ankommende SIP-Requests verarbeitet. Die SIP und SDP Nachrichten werden so modifiziert dass sämtlicher Verkehr (SIP und RTP) immer über den Milkfish läuft.

Na toll und ich mach einen auf zwei Wochen-Experiment mit den Portforwardings bis es endlich funktionierte... Naja wieso einfach wenn's kompliziert auch geht, ne

Unter diesen Umständen versuch ich's mal mitm dem MF (kann ich gleich ma die DD-Backup-Funktion testen ob die's bringt

Für QoS gibt es im DD-WRT Wiki eine gute Anleitung. Begrenze den Upstream auf 85% deiner Bandbreite und priorisiere das Telefon über seine MAC-Adresse. Was für Probleme hast du denn im LAN mit QoS? Das dürfte da eigentlich gar nicht eingreifen.

Naja nach deren Wiki hab ich's ja versucht... 1. Prio Voip 2. Prio HTTP 3. Rest... alles für WAN <-> LAN; hab ich dann QOS so konfiguriert, dauert ein Übertragen von ner 300MB-Datei zwischen Schläptop und PC satte 20 Minuten... QOS aus -> keine 2min...

Jedoch muss ich zu sagen: ich hab QOS per IP-Adresse konfiguriert, nicht auf die MAC(alle Devices mit fixierter IP, ich verzichte in meinem Netz auf DHCP)...

Was ich aber noch nicht ganz verstehe (bin Schweizer, bei uns dauert's manchmal n bisl länger ;-) :

MF wird im Tel als Outbound-Proxy eingetragen; fungiert auch als Inbound-Proxy... So wie du das erklärst, fängt MF alle VoIP-Pakete ab und leitet die weiter... Muss man das dem Tel nicht irgendwie mitteilen? (ich stell mir das so vor, dass das Tel auf ein Paket vom VoIP-Provi auf 5060 wartet, nie bekommt, da a) ja MF die Pakete weiterleitet, welche aber - wegen falscher Herkunft - gebounced werden b) die Pakete gar nicht mehr vom VoIP-Provi auf 5060 durchkommen können, da kein Portforwarding mehr aktiv)

 

[Pingpong]

Was ich aber noch nicht ganz verstehe (bin Schweizer, bei uns dauert's manchmal n bisl länger ;-) :

MF wird im Tel als Outbound-Proxy eingetragen; fungiert auch als Inbound-Proxy... So wie du das erklärst, fängt MF alle VoIP-Pakete ab und leitet die weiter... Muss man das dem Tel nicht irgendwie mitteilen? (ich stell mir das so vor, dass das Tel auf ein Paket vom VoIP-Provi auf 5060 wartet, nie bekommt, da a) ja MF die Pakete weiterleitet, welche aber - wegen falscher Herkunft - gebounced werden b) die Pakete gar nicht mehr vom VoIP-Provi auf 5060 durchkommen können, da kein Portforwarding mehr aktiv)

Was heisst abfangen? Der Provider schickt die Pakete direkt zum MF, und der schickt sie dann weiter zum Telefon. Wenn sich dein Telefon beim Provider registriert, dann hat das als Absenderadresse eine aus deinem LAN (also z.B. 192.168.1.2). Ohne STUN weiss das Telefon ja nix von der WAN-IP. Der MF ändert diese Adresse im SIP-Header und trägt seine eigene ein. Der Provider glaubt nun die Registrierung käme vom MF. Foglich schickt er bei ankommenden Gesprächen die Pakete ebenfalls zum MF. Dieser tauscht nun wieder die Adressen aus und leitet sie zum Telefon weiter. Das Forwarding erledigt sozusagen der MF und tauscht dabei gleichzeitg die Adressen im Header. Deswegen heisst das Application Layer Gateway, weil es im Gegensatz zum Router (der auf TCP Ebene arbeitet) die Pakete auf Applikations-Ebene manipuliert und weiterleitet.

Strenggenommen bräuchte man solche ALGs auch für andere Protokolle, z.B. FTP. Bei FTP hat man es aber durch Einführung des passive Mode in Kombination entsprechender Forwardings eines ganzen Portranges auch so hinbekommen. Bei SIP klappt das so nicht, weil hier nicht nur 2 Parteien, sondern gleich 3 Parteien beteiligt sind (Provider und 2 Telefone). Ausserdem besitzen die meisten Linux-Router sogenannte NAT-Helper Module, u.a. für FTP. Es gibt auch ein NAT-Helper Modul für SIP, aber ich kenne keinen Router der das drin hat.

Im Prinzip macht der MF also nix anderes wie jeder normale Router, nur eben auf einer anderen Ebene. Der Router manipuliert die TCP- und UDP-Pakete und leitet sie weiter, das SIP-ALG manipuliert die SIP-, SDP- und RTP-Pakete und leitet sie weiter. Genau das selbe, nur eine Ebene höher.

 

[schattenmann]

danke für die erklärung, von der seite hab ich's gar nicht betrachtet!

super erklärungen, mir is nu einiges über die funktionsweise von sonem router klar geworden... werd mich wohl eingehender mit dem thema beschäftigen, so wie's aussieht hab ich zu viel (gefährliches) halbwissen...

:groesste:

hab's nun vorhin einfach riskiert, den MF angeworfen, die zeitrauende PF-konfig rausgekillt, und hey...... es funktioniert... (ok, ich fühl mich jetzt wie der grösste vollidiot (weil ich auch schon mit der v23 ne voip-version hätte haben können), aber es funktioniert

nunja, es dauerte etwas bis der proxy oben war, aber so oft starte ich den router ja nicht neu; ansonsten muss ich ihn wohl doch wieder auf "normal" takten (hab den WRT auf kleinster leistung im moment)...