SP-H ohne SIPPROXY

      Bis dahin hat alles geklappt, jetzt käme nun die eigentliche Aufgabe, die Entfernung des Sip-Proxy. Dabei möchte ich natürlich weiterhin die Möglichkeit haben einzelne Geräte aufs DSL festzunageln (meine 16000 Annex J Leitung reicht für die Telefonie voll aus) und die örtliche Verkabelung würde die Nutzung der Fritzbox als Router erschweren, sie soll also weiter Client bleiben. Ein Raspberry stellt im Netz einen Asterisk bereit zur Funktionserweiterung der Fritzbox. Dieser muß völlig unabhängig von anderen Sip-Geräten oder Providern Sip-Urls anrufen können und eben das verhindert der Sip-Proxy recht zuverlässig. Außerdem nutze ich die Telekom-Accounts neben anderen Providern, so daß das Script (wie und wo führt man das denn aus?) welches Routen für die Telekom-Server enthält so nicht ganz richtig ist.

      Leider weiß ich anhand des ersten Posts in diesem Thread wieder mal nicht wie das jetzt weiter zu realisieren wäre. Kann mich nochmal jemand an die Hand nehmen?

      Nunja dafür wirst Du das Firewall Script erweitern müssen.
      Indem ist bisher ja nur die Regel für die Fritzbox... ähnliches müsstest Du dann wohl für den Raspi machen.
      wie sich die Fritzbox im Clientmodus verhält kann ich Dir auch nicht sagen.
      Ich hab sie im normalen Routermodus.

      Hilfreich wäre wohl wenn Du mal

      IP Adresse SPH
      IP Adresse Fritzbox
      IP adresse Raspi
      posten würdest.
      Ich vermute mal danxde könnte Dir sobald er Zeit findet sagen welche Regeln Du zusätzlich brauchst.

      Es kann aber auch sein da der Raspi ja an der Fritzbox hängt das Du keine weiteren Regeln brauchst^^

      Du kannst also auch einmal manuell testen ob es funktioniert.
      also voiper und siproxd killen und das angepasste Firewallscript ausführen und warten :)
      wenn das erstmal mit der Fritzbox klappt kannst Du immer noch weiter machen mit dem raspi

      So, habe ich jetzt richtig verstanden:
      Das Script bootstrap_init.sh (auf dem Stick) anpassen indem man folgendes einfügt bzw. ergänzt:

      Shell-Script

      1. #!/bin/sh
      3. PATH=/bin:/sbin:/usr/bin:/usr/sbin:/opt/bin:/opt/sbin
      4. export PATH
      6. killall -9 voiper
      7. killall -9 siproxd
      9. #wait for dsl
      10. while [ $(date | cut -d ' ' -f 7) = 1970 ]; do sleep 1 ; done
      12. /opt/bin/fw.sh
      13. /opt/bin/route.sh
      Außerdem das runtergeladene Script fw.sh anpassen und nach /opt/bin auf dem Stick verschieben und dort auch noch route.sh anlegen mit dem Inhalt aus dem Posting von danXde?

      Startet denn der Rrouter jetzt auch noch ohne Stick und kann ich den Stick an meinem Linux-PC bearbeiten? Auf dem Router muß ich doch jetzt nichts mehr ändern oder?

      Noch ne Frage: Ist es richtig daß der kill-Befehl kommt noch bevor der Router online ist oder sollte man den kill-Befehl lieber nach der Warteschleife einfügen?

      w.erik schrieb:

      Startet denn der Rrouter jetzt auch noch ohne Stick und kann ich den Stick an meinem Linux-PC bearbeiten? Auf dem Router muß ich doch jetzt nichts mehr ändern oder?

      Die Idee des Bootstraps ist gerade, daß der Router ohne Stick normal bootet ;)
      Wenn was schief geht einfach Reboot ohne Stick...

      Und ja, Du kannst den Stick auch an einem Linux-Rechner bearbeiten - solange Du auf Dateirechte und evtl. Datei-Besitzer achtest.
      (ich selbst mach's aber lieber per Telnet/SSH vom Ubuntu-Rechner aus)

      mfg, emkay

      Um Probleme mit einer Telefonanlage hinter dem Speedport Hybrid zu beheben, die definitiv am SIP-Proxy des Speedport liegen, sollte dies doch reichen, oder?

      Quellcode

      1. killall siproxd voiper
      2. route add -net 217.0.0.0 netmask 255.255.224.0 ppp256

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ladiko“ ()

      @ladiko nein das reicht nicht, Du must auch die Firewall wegen NAT/Forwarding anpassen.

      je nachdem, was Du machst, musst Du bestimmte Einträge noch entfernen. Im fw.sh baue ich ja die komplette IPv4 iptables neu auf, daher brauche ich mich nicht um Altlasten kümmern, es verschwinden aber auch von mir nicht betrachtete Features wie "WLAN to GO", "Multicast für Entertain", etc.

      Relevante Zeilen sollten sein (FRITZBOXIP müsstest Du dann durch deine ANLAGENIP ersetzen):

      Quellcode

      1. # Wer SIPGATE zur Fritzbox braucht
      2. #
      3. ipt iptables -A FWD_SERVICE -s 217.10.64.0/20 -d $FRITZBOXIP/32 -i gre+ -p udp -m udp --dport 7078:7109 -j ACCEPT
      4. ipt iptables -A FWD_SERVICE -s 217.116.112.0/20 -d $FRITZBOXIP/32 -i gre+ -p udp -m udp --dport 7078:7109 -j ACCEPT
      5. ipt iptables -A FWD_SERVICE -s 212.9.32.0/19 -d $FRITZBOXIP/32 -i gre+ -p udp -m udp --dport 7078:7109 -j ACCEPT
      6. ipt iptables -A FWD_SERVICE -s 217.10.79.9/32 -d $FRITZBOXIP/32 -i gre+ -p udp -m udp --dport 5060 -j ACCEPT
      7. ipt iptables -A FWD_SERVICE -s 217.10.68.147/32 -d $FRITZBOXIP/32 -i gre+ -p udp -m udp --dport 5060 -j ACCEPT
      8. ipt iptables -A FWD_SERVICE -s 217.10.68.150/32 -d $FRITZBOXIP/32 -i gre+ -p udp -m udp --dport 5060 -j ACCEPT
      9. ipt iptables -A FWD_SERVICE -s 217.10.64.0/20 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 7078:7109 -j ACCEPT
      10. ipt iptables -A FWD_SERVICE -s 217.116.112.0/20 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 7078:7109 -j ACCEPT
      11. ipt iptables -A FWD_SERVICE -s 212.9.32.0/19 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 7078:7109 -j ACCEPT
      12. ipt iptables -A FWD_SERVICE -s 217.10.79.9/32 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 5060 -j ACCEPT
      13. ipt iptables -A FWD_SERVICE -s 217.10.68.147/32 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 5060 -j ACCEPT
      14. ipt iptables -A FWD_SERVICE -s 217.10.68.150/32 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 5060 -j ACCEPT
      15. #
      16. # Telekom VoIP
      17. #
      18. ipt iptables -A FWD_SERVICE -s 217.0.16.0/20 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 5060 -j ACCEPT
      19. ipt iptables -A FWD_SERVICE -s 217.0.0.0/20 -d $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 7078:7109 -j ACCEPT
      20. ipt iptables -A FWD_SERVICE -d 217.0.16.0/20 -s $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 5060 -j ACCEPT
      21. ipt iptables -A FWD_SERVICE -d 217.0.0.0/20 -s $FRITZBOXIP/32 -i ppp256 -p udp -m udp --dport 7078:7109 -j ACCEPT
      22. #
      24. #
      25. # Telekom VoIP
      26. #
      27. ipt iptables -t mangle -A FWD_FILTER_LIST -d 217.0.0.0/20 -p udp -m udp --dport 5060 -j MARK --set-xmark 0x10000000/0xf0000000
      28. ipt iptables -t mangle -A FWD_FILTER_LIST -d 217.0.0.0/20 -p udp -m udp --sport 5060 -j MARK --set-xmark 0x10000000/0xf0000000
      29. ipt iptables -t mangle -A FWD_FILTER_LIST -d 217.0.16.0/20 -p udp -m udp --dport 7078:7109 -j MARK --set-xmark 0x20000000/0xf0000000
      30. ipt iptables -t mangle -A FWD_FILTER_LIST -d 217.0.16.0/20 -p udp -m udp --sport 7078:7109 -j MARK --set-xmark 0x20000000/0xf0000000
      31. #


      Grüße

      danXde

      @all,

      ich habe das Paket ein wenig überarbeitet. Jetzt sollte der dibbler auch in kürzester Zeit die Prefixe ändern, wenn sich die Adressen im SP-H geändert haben. Das Routing und die ip6tables werden ebenfalls angepasst. Wenn Scopes freigegeben werden, werden diese dann auch gelöscht.

      dhcp6package-V0.9.zip

      Die vergebenen Leasetimes könnte man sicher noch optimieren. Aktuell vergibt meine Fritzbox sehr lange Leasetimes, daher muss ich bei Änderung dem Mac mal das WLAN ab und anschalten, damit er mitbekommt, das er neue IPv6-Adressen sich holt. Das wird man aber nicht im SP-H tunen können. :o)

      Grüße

      danXde

      Hallo, ich hab jetzt Telnet aktiviert, kann mich einlogen, aber:

      Quellcode

      1. $ killall siproxd voiper
      2. killall: cannot kill pid 3024: Operation not permitted
      3. killall: cannot kill pid 3025: Operation not permitted
      4. killall: cannot kill pid 3026: Operation not permitted
      5. killall: cannot kill pid 1078: Operation not permitted
      6. killall: cannot kill pid 1092: Operation not permitted
      7. killall: cannot kill pid 1093: Operation not permitted
      8. killall: cannot kill pid 1094: Operation not permitted
      9. killall: cannot kill pid 1095: Operation not permitted
      10. killall: cannot kill pid 1096: Operation not permitted
      11. killall: cannot kill pid 1097: Operation not permitted
      12. killall: cannot kill pid 1098: Operation not permitted
      13. killall: cannot kill pid 1137: Operation not permitted
      14. killall: cannot kill pid 1295: Operation not permitted
      15. killall: cannot kill pid 1298: Operation not permitted
      16. killall: cannot kill pid 1299: Operation not permitted
      17. killall: cannot kill pid 1300: Operation not permitted
      18. killall: cannot kill pid 1350: Operation not permitted
      19. killall: cannot kill pid 1351: Operation not permitted
      20. killall: cannot kill pid 1352: Operation not permitted
      21. killall: cannot kill pid 1353: Operation not permitted
      22. killall: cannot kill pid 1354: Operation not permitted
      23. killall: cannot kill pid 1355: Operation not permitted
      24. killall: cannot kill pid 1356: Operation not permitted
      25. killall: cannot kill pid 1367: Operation not permitted
      26. killall: cannot kill pid 1368: Operation not permitted
      27. killall: cannot kill pid 1369: Operation not permitted
      28. killall: cannot kill pid 1370: Operation not permitted
      29. $ whoami
      30. console


      Ich bin als der Benuter angemeldet, der in der config als X_CLI -> UserInfoInstance -> InstanceID="1" und UserLevel="0" aufgeführt ist. Ich dachte das wäre der Admin-User?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ladiko“ ()

      su ... :rolleyes:

      Wofür ist eigentlich voiper gut und wieso muss man das auch killen? Die würden jeweils eine im SPH eingetragene Nummer verwalten?

      Weiß jemand ob es problematisch ist, wenn ich

      Quellcode

      1. mount -o remount,rw mtd / (wie re-mounte ich mtd?=
      2. chmod -x /bin/siproxd
      3. chmod -x /bin/voiper

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ladiko“ ()

      @ladiko wir man das rootfs mounted findet man in einem anderen Beitrag. Umbenennen bzw. Ausführungsrechte entziehen verhindet, das diese daemons beim nächsten Reboot ausgeführt werden. Beides ist nur machbar, wenn mann auf dem SP-H kein VoIP machen will und nachgelagert nur ein Gerät hat, was direkt mit dem Telekom IMS eine ensprechende Verbindung aufbauen soll. Wenn mehrere Geräte sich gleichzeitig direkt mit dem IMS verbinden, muss man sicher anders vorgehen.

      Grüße

      danXde