Suchergebnisse

Jein, dem TAp-Interface eine andere IP zu geben ist gefaehrlich... denn ueber diese IP ist die Box dann nur ueber das TAP-Interface, also aus Richtung Server erreichbar, nicht aber aus dem lokalen Netz, da der lokale Client eine ARP-Anfrage schickt, die Fritz sie dann ueber das entsprechende...

Fritzbox: TAP hat die .101, LAN aber die .7. Das ist falsch! Beide Interfaces muessen die gleiche IP haben, oder optional TAP gar keine. Server: tap ist down, "ifconfig tap0 up" ausfuehren, KEINE IP zuweisen! eth5 ebenfalls keine IP zuweisen! Dem Interface "lan" auf dem Server die IP...

dann gib mal die "ifconfig"-Ausgabe von tap0 (Server und Fritz), eth0 (Server und Fritz), lan (Fritz) sowie dem Bridge-Interface auf dem Server

TAP ist keine Bridge. TAP ist ein normales Interface wie ETH0 etc. Eine Bridge ist ein virtuelles Interface bestehend aus mehreren anderen Interfaces. Eine Bridge allein macht erstmal gar nichts, erst wenn man Interfaces in sie einhängt schickt sie alles was von einem kommt an die anderen weiter...

Klar haben die anderen auch einen Einfluss drauf. Jedoch denke ich mal das Montag abends gegen 19 und 22 Uhr mehr in den Zellen los sein dürfte als in der Nacht von Sonntag auf Montag um 0 Uhr. Trotzdem konnte ich gerade zig Minuten problemlos vie UMTS telefonieren, was gestern so nicht ging...

Die hosts kann schon noch falsch sein, da du den gleichen Hostname dort auch 2 Mal eintragen koenntest mit verschiedenen IPs. Beim ping nimmt er dann den ersten Match den er findet. Oder ein Nameserver liefert die falsche Antwort. Mit den Eintraegen sollte das Routing eigentlich klappen...

Nee, dat laeuft definitiv nicht richtig, denn Localhost = 127.0.0.1 != 10.0.0.1 Der Route-Del sollte ebenfalls so nicht funktionieren, da das Gateway localhost und nicht 10.0.0.1 ist bei der eingetragenen Route. Was ist denn die Ausgabe von "route -n", um auszuschliessen das du nur eine...

Nö, die Route ist falsch. Auf dem Client musst du eine Route für das Netz 192.168.1.0/24 einrichten und das Gateway 10.0.0.x (Server-IP vom Tap-Netz) nehmen. Auf dem Server eine Route für das Netz 192.168.178.0/24 mit der Client-IP aus dem Tap-Netz als Gateway.

Frisch getestet. Wenn ichs WLAN in ein separates Netz packe und die Bridge entferne, dann entfernt die Fritz als erstes Mal das ganze LAN-Interface, es bleiben dann nur noch die Einzel-Interfaces. Ich hab dann manuell ein neues LAN-Interface aufgemacht und tap0 + eth0 dran gehängt. Ergebnis...

ja, bin ich mir sicher. Best Effort hin oder her, es ist schon merkwürdig das der Ping immer nur zusammenbricht wenn leichte Last da ist, aber unabhängig von der Höhe der Last

Also ich probier seit Freitag mit der 7270 und der Final-Firmware dran rum. Die Bandbreite reicht alle mal, die Ping-Zeit meistens... aber leider nicht immer. Die Verbindung ist unbelastet, mit Ausnahme des VoIP-Verkehrs. Meist liegt der Ping unter 150ms, aber alle paar Sekunden gibts einen...

Das ist Voraussetzung damit der Reboot kommt. Es müssen eth0, ath0 und tap0 in der Bridge sein, und dann ein Paket von ath0 kommen das über tap0 raus soll (oder evtl. umgekehrt, lässt sich ja schlecht sagen). Die Existenz in der Bridge allein ist aber noch nicht das Problem, erst wenn sie auch...

Thx, da war ich dann wohl doch was zu dusselig zum Suchen ;-) Dann machen wir mal drüben weiter.

Ah, hier ist das Problem :-) Wie hier beschrieben tritt die Problematik auch schon ohne freetz auf. Voraussetzung ist einfach ein OpenVPN-TAP das zum Interface LAN hinzugefügt wird. Der Reboot erfolgt dann schneller als man gucken kann sobald ein Paket vom WLAN aus über die Bridge geht. Geht da...

Tja, seit gestern (Mist, schon wieder so spät... vorgestern) hab ich nu eine 7270 hier stehen die als UMTS-Router dienen soll, also ohne DSL... spielt aber denke hierbei keine Rolle. Die Box soll das lokale Netz (LAN und WLAN) per OpenVPN-Tunnel und Bridging zu meinen anderen Standorten...

Schauen wir mal wie es in der Praxis ausschaut... für die paar wenigen Anrufe bei mir wirds schon reichen. Aber zurück zum Codec: kann die Probleme nicht nachvollziehen auf dem Hermes. G711 und GSM wirken beide gleich laut, auch das aufgenommene File sieht im Soundeditor soweit identisch aus...

Hm, also Freisprechen sollte völlig unbeeinflusst sein, das kommt erst auf einer weit höheren Schiene... wenn das mit dem G711er Codec klappt muss es auch hiermit klappen... Lautstärke werd ich nachher mal ein paar Testsamples durchjagen und mal schauen ob ich was sehen kann. Und GPRS via EDGE...

Einfach gesagt: er funktioniert. Der mitgelieferte MSGSM-Codec arbeitet nicht. Da bekommst du mit keinem bekannten SIP-Provider eine Verbindung zu Stande, es wird immer auf den uLaw/aLaw-Codec umgeschaltet, welche nur leider 64kBit Uebertragungsrate braucht, statt den 13kBit vom GSM0610. Erstere...

Ja, keine Sorge, ich hab die Suche benutzt, ich weiss... gabs nich ;-) Wers doch haben möchte: Hier klicken, runterladen, installieren. Wer erst wissen will was es ist ;-) : GSM-Codec, der mit der RTC-API von Windows Mobile 6 zusammen arbeitet. Ich hab auf Basis der originalen MS-GSM-DLL das...