ich habe mir vor kurzem bei Lidl den Targa W500 gekauft und wollte ihn für meinen existierenden Arcor-Anschluss nutzen, also die EasyBox durch den Targa ersetzten. Nun bin ich dort auf einige Hürden gestoßen.
z.B. Es werden 2 PPPoE -Verbindungen aufgebaut, eine für Internet und eine für VOIP. Da gab es auch weitere Probleme, z.
B. dass sich vodsl nicht bei Arcor anmelden wollte, bzw. registrieren hat geklappt, jedoch konnte man nicht raustelefonieren. Wenn man angerufen wurde, dann hat nur der Anrufer den Angerufenen gehört.
Nun hab ich diese Probleme lösen können und wollte meine Arbeit gerne weiter geben dass die Bitswitcher weiter verbessert werden kann. Nur weiß ich nicht so recht an wen ich mich da am besten wenden sollte und ob daran überhaupt Interesse besteht. Bin kein Profi deswegen ist da manches bisschen hingepfuscht.
Also so als kurzen Überblick was ich geändert habe: - im Webinterface, die blöde MAC-Warnung korrigiert wenn man die Mac nicht klonen möchte.
- im Webinterface die Passwortkontrolle angepasst, dass man auch Kennwörter mit Sonderzeichen benutzen kann und die dann auch richtig gespeichert werden
- dsl.sh so angepasst dass 2 PPPoE Verbindungen aufgebaut werden, eine 1/32 für Internet und eine 2/32 für VOIP
- pppd umgeschrieben dass man mit Parameter -D es unterbinden kann dass die Default-Route bzw. der Nameserver von der zweiten (bei mir VOIP) überschrieben wird, denn man kann nur über die Internet-Leitung surfen.
- in die /etc/hosts arcor.de mit der internen 10er-IP eingetragen damit VOIP über die zweite Verbindung läuft.
- vodsl benutzt beim Sip-Protokoll den Parameter a=silenceSupp:off dies mag der Arcor-SIP-Server nicht, aufgrund dessen die Verbindung nicht aufgebaut werden kann. Es kommt die Fehlermeldung 503 Service Unavailable. da das Programm leider Closed-Source ist musste ich etwas "pfuschen" ich habe ein kleines SIP-Proxy-Programm geschrieben sipp, er schaut sich alle Pakete an und ersetzt den Parameter geschickt, so dass VOIP funktioniert. Um die Pakete nicht zu sehr zu verändern habe ich ihn transparent eingebunden. Spricht mit iptables das Packet zu Arcor zum Proxy umgeleitet dann ersetzt mein Proxy die Stelle und dann wird’s mit Hilfe von iptables wieder zurück zu Arcor gebogen, somit muss ich nur die ausgehenden Pakete betrachten ;-) Man musste im Kernel noch einstellen das iptables auch lokale Pakete ändern darf…
- Das waren eigentlich so die größten Änderungen, bcm_helper musste wegen des Symlinks auch angepasst werden.
Soweit so gut, ich hoffe einigen weiter geholfen zu haben.
Gruß Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Da hätt ich ja gern mal einen Patch von den ganzen Änderungen gesehen. Ich bin wirklich beeindruckt, hat sicher ne Menge Arbeit gemacht. Bitte poste wirklich mal deinen Patch und vielleicht hast du ja auch einen guten Vorschlag wie sich das richtig integrieren lässt, denn die zweite ppp-Verbindung scheint mir ja wirklich ein Sonderfall zu sein.
Schade das ich deinen Post erst jetzt entdeckt habe….
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Naja hab ein kleines Problem festgestellt, der Voip-Client auf der Targa hat sein Protokoll etwas falsch implementiert, hab einen kleinen Proxy gesschrieben der das etwas behebt, aber ich habe die Packete über netfilter einfach local umgeleitet, nur hat der contrack vom netfilter einen Strich durch die Rechnung gemacht, wollte mit notrack dagegenwirken, hab's aber nicht geschafft die raw-Tabelle mit notrack zu erstellen, bzw denke da ist auch ein Teil closed source. Jetzt gäbe es die Möglichkeit einen besseren Proxy zu programmieren aber dazu fehlte mir dann doch die Lust. das ppp hab ich einfach umgeschrieben.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ist trotzdem sehr interessant und versteh nicht was das conntrack damit zu tun hat bzw. was du mit besserem Proxy meinst? Passiert denn der Fehler mit dem Arcor-SIP-Server nur bei Gesprächsbeginn oder schon bei der Anmeldung?
Ist es denn immer so das bei Arcor eine zweite ppp-Verbindung aufgebaut wird? Wird diese auch mit anderen Einwahldaten (Username/Passwor etc.) benutzt?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DSL EasyBox A401 ersetzten durch Targa WR 500 Voip
Im Webinterface der EasyBox A401 erkennt man auf Startseite im „Ereignislogbuch“, dass 2 DSL-Verbindungen aufgebaut wurden.
Ereignislogbuch:
12/01/2008 00:00:28 If(PPPoE1) PPP connection ok !
12/01/2008 00:00:28 If(PPPoE2) PPP connection ok !
12/01/2008 00:00:27 If(PPPoE1) get secondary DNS IP:195.***.***.***
12/01/2008 00:00:27 If(PPPoE1) get primary DNS IP:195.***.***.***
12/01/2008 00:00:27 If(PPPoE1) get IP:188.***.***.***
12/01/2008 00:00:27 If(PPPoE2) get secondary DNS IP:10.***.***:***
12/01/2008 00:00:27 If(PPPoE2) get primary DNS IP:10.***.***.***
12/01/2008 00:00:27 If(PPPoE2) get IP:10.***.***.***
12/01/2008 00:00:27 If(PPPoE1) start PPP
12/01/2008 00:00:27 If(PPPoE1) receive PADS
12/01/2008 00:00:27 If(PPPoE1) send PADR
12/01/2008 00:00:27 If(PPPoE1) receive PADO
12/01/2008 00:00:27 If(PPPoE2) start PPP
12/01/2008 00:00:27 If(PPPoE2) receive PADS
12/01/2008 00:00:27 If(PPPoE2) send PADR
12/01/2008 00:00:27 If(PPPoE2) receive PADO
12/01/2008 00:00:26 If(PPPoE2) send PADI
12/01/2008 00:00:26 If(PPPoE1) send PADI
12/01/2008 00:00:25 ADSL Media Up !
Es wurden also 2 PPPoE-Verbindungen aufgebaut, eine mit der Internet-IP-Adresse (188.***.***.***) und der Intranet-IP-Adresse (10.***.***.***).
Die Vermutung liegt Nahe, dass Voip über die Interne Verbindung läuft und das Internet über die andere.
Diese Vermutung wird bestätigt, wenn man im Webinterface unter EXTRAS / Diagnoseprogramm sich die Protokolle von VC1 und VC2 anschaut.
Problem1:
- Keine Zugangsdaten von Arcor, sondern nur ein Modem-Installations-Code.
Lösung1:
- Die Voip-Zugangsdaten können mit dem VC2-Protokoll und durch BruteForce entschlüsselt werden. Passende Software findet man im Internet. Jedoch benötigen wir noch die Zugangsdaten für die PPPoE-Verbindungen.
- Um die anderen Zugangsdaten zu erhalten, benötigt man einen älteren Router. z.B. A400.
1. Den alten Router mit dem Modeminstallationscode einrichten.
2. Alte Firmware auf den A400-Router spielen.
3. Config-Datei speichern.
4. Config-Datei mit einem Hex-Editor öffnen und mit FF XOR-verknüpfen.
5. Nun stehen die Zugangsdaten der PPP-Verbindung im Klartext in der neuen Config-Datei.
Man erkennt sowohl das vorher entschlüsselte Voip-Kennwort, als auch die PPPoE Benutzernamen und Kennwörter.
Die Benutzernamen der beiden Verbindungen sowie die Kennwörter sind gleich.
Nun haben wir die Informationen, die wir brauchen um den Targa WR500 einzurichten.
Zum Glück gibt es schon die Bitswitcher- Software diese muss nur wie folgt verändert werden.
- Es müssen 2 PPPoE-Verbindungen aufgebaut werden.
- Der Voip-Client muss zum Funktionieren gebracht werden, leider ist er closed source und somit nicht veränderbar, und da der Client auch die Hardware steuert kann er nicht durch Asterisk ersetzt werden.
- Ein weiteres Problem ist, dass beide PPPoE-Verbindungen sich als Gateway eintragen wollen, dazu muss PPPoE umgeschrieben werden.
Die Probleme mit der 2 PPPoE-Verbindungen sind behoben, auch der PPPoE-Client hab ich umgeschrieben. Nur leider macht der Voip-Client Schwierigkeiten.
Das Protokoll ist „fehlerhaft“ implementiert, es werden Optionen mitgeschickt an der sich der Arcor-Sip-Server verschluckt.
(Mit einem SIP-Client auf dem Computer kann über die Intranet-Verbindung ohne Probleme telefoniert werden.)
Hab ein kleiner Programm geschrieben dass die fehlerhaften Optionen durch andere ersetzt, die funktionieren.
(Hab einfach die Pakete vom Tagra-Voip-Client mit denen vom Computer Voip-Client vergleichen/ersetzt.)
Um die Pakete zu manipulieren habe ich den Netfilter benutzt. Dieser leitet die ausgehenden Pakete zu dem Programm um. Dies funktioniert auch ganz gut und der Voip-Client kann sich am Arcor-Sip-Server anmelden und es kann raustelefoniert werden.
Das noch bestehende Problem ist dass ein eingehendes Gespräch vom Sip-Server initiiert wird, also das erste UDP-Paket kommt vom Server.
Die Contrack-Funktion vom Netfilter merkt sich ah ok Server will von Port 5060 zu Port 5060 und setzt daraufhin die Rückroute, damit der Server auch wieder Pakte vom Client bekommt, nur leider wird dadurch nicht mehr die „Umleitregel“ ausgeführt, welche dafür sorgen sollte die Pakete zu manipulieren. Jetzt gäbe es die Möglichkeit einen kompletten Sip-Proxy für den Router zu schreiben, dass der Targa-Voip-Client denkt er meldet sich am Proxy an und nicht beim Sip-Server.
Die alternative, die ich versucht habe war das Notrack in die Raw-Tabelle einzubauen und somit dem Netfilter anweise er soll Packete von 5060 nicht mit mit der Contrack-Funktionalität ausstatten. Doch leider geling mit das nicht, da vermutlich die Contrack-Tabelle auch closed source ist. Also bleibt wohl nur die Möglichkeit des Proxys.
Gruß Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sehr schöne Anleitung und ich bin ja entsetzt wie sehr der Provider versucht mit Installationscodes etc. den ganzen Krempel zu verbergen. Ist m.M.n. Schwachsinn da das eher zu Unzufriedenheit führt….aber egal.
Wegen dem Conntrack, denke ich sind folgende Zeilen aus dem firewall.sh-Skript Schuld:
491 setup_sip_input()
492 {
493 echo "setup_sip_input()" >>$DEBUG_FILE
494 exec_cmd "iptables -N SIP_INPUT"
495 exec_cmd "iptables -F SIP_INPUT"
496
497 voip_start=`nvram get voip_start`
498 if ; then
499 ata_regport=`nvram get ata_regport`
500 && ata_regport=5060
501 exec_cmd "iptables -A SIP_INPUT -p udp -dport $ata_regport -m state -state NEW -j ACCEPT"
502 # the original w500v opens the ports 16384..16400 too, sometimes an incomming call uses this ports
503 exec_cmd "iptables -A SIP_INPUT -p udp -dport 16384:16400 -m state -state NEW -j ACCEPT"
504 fi
505 exec_cmd "iptables -A SIP_INPUT -j RETURN"
506 }
Ich schlage daher folgende zusätzlich Regeln vor, die verhindern sollten das die Verbindung "stateful" behandelt wird (am besten in die custom-rules eintragen):
#SIP chain leeren
iptables -F SIP_INPUT
#eingehende Pakete einfach nur accepten aber NICHT stateful behandeln
iptables -A SIP_INPUT -p udp -dport 5060 -j ACCEPT
iptables -A SIP_INPUT -p udp -dport 16384:16400 -j ACCEPT
Wenn du noch Lust hast, dann probier das ruhig mal aus. Das sollte eigentlich das Problem lösen denke ich.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Achja, wollte noch fragen wo du die Sourcen vom pppd her hast, die liegen doch glaub ich gar nicht im dev_tree sondern sind auch von Broadcom nur als Binary mit gekommen?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das mit der Regel in der Firewall hat nichit funktinoiert, es wird dennoch in die Contrack-Tabelle aufgenommen.
Den Quellcode von pppdoe gibts in der Toolchain von Bitswitcher.
Also entweder schaff ichs noch irgendwie der raw-Tabelle beizubringen, dass sie auch den NOTRACK-Filter kann oder ich muss das Proxy-Programm umschreiben.
Gruß Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ich bin seit den letzten Tagen dabei deine Änderungen mal nachzuvollziehen, aber einige deiner Angaben sind
etwas unzureichend.
Ich habe bis jetzt folgendes gemacht:
-Web-Interface und Startskripte angepasst, es kann jetzt eine zweite ATM-Verbindung und eine
zweite PPP-Verbindung konfiguriert werden
-PPPd um "-D" erweitert sodass GW und DNS nicht überschrieben werden
-bcm_helper erweitert sodass das zweite PPP-Device auf .ppp1 verlinkt wird
Was ich jetzt nicht weiß, welche SIP-Optionen dem Arcor-Server Probleme machen und durch welche im Detail diese ersetzt werden müssen. Oder muss einfach nur a=silenceSupp:off aus dem Invite entfernt werden? Gib mir vielleicht mal noch ein bissel Hilfestellung bzw. kannst du meine Änderungen auch im svn mal anschauen und ggf. testen. Achja, wenn man anstelle von arcor.de gleich die richtige Registrar/Proxy-IP im Webinterface eingibt sollte doch die Manipulation der /etc/hosts nicht notwendig sein oder?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
strcpy(head,correctLen(head,strlen(content)));
strcpy(buffer,head);
strcat(buffer,content);
}
}
received = strlen(buffer);
/* Send the message back to client */
if (sendto(sock, buffer, received, 0,
(struct sockaddr *) &toserver,
sizeof(toserver)) != received) {
Die("Mismatch in number of echo'd bytes");
}
}
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Die Portumleitung hab ich mit iptables umgebogen, jedoch spielt mir bei eingehenden Anrufen die contrack-Tabelle einen Strich durch die Rechnung… Eventuell einen kompletten Proxy basteln.
Wenn du Sipgate einträgst funktionierts ohne Probleme mit dem SipClient, da muss kein Proxy verwendet werden, jedoch braucht man bei Sipgate auch keine zweite PPP-Verbindung ;-) Hab das Projekt erstmal eingestellt, da ich ein zuverlässiges Tel brauche und mit der bisherigen Lösung nicht angerufen werden kann.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich hab zur Lösung des Proxy-Problems ein iptables mangle Modul geschrieben (zu finden im svn).
Damit lassen sich einzelne SIP-Attribute oder Header Zeilen anfügen, löschen oder ersetzen.
Da das Modul in der mangle-Table sitzt sollte das conntrack kein Problem sein.
Dein Proxy lässt sich mit Hilfe des Moduls dann durch folgendes Skript ersetzen:
Hallo,
ich habe mir vor kurzem bei Lidl den Targa W500 gekauft und wollte ihn für meinen existierenden Arcor-Anschluss nutzen, also die EasyBox durch den Targa ersetzten. Nun bin ich dort auf einige Hürden gestoßen.
z.B. Es werden 2 PPPoE -Verbindungen aufgebaut, eine für Internet und eine für VOIP. Da gab es auch weitere Probleme, z.
B. dass sich vodsl nicht bei Arcor anmelden wollte, bzw. registrieren hat geklappt, jedoch konnte man nicht raustelefonieren. Wenn man angerufen wurde, dann hat nur der Anrufer den Angerufenen gehört.
Nun hab ich diese Probleme lösen können und wollte meine Arbeit gerne weiter geben dass die Bitswitcher weiter verbessert werden kann. Nur weiß ich nicht so recht an wen ich mich da am besten wenden sollte und ob daran überhaupt Interesse besteht. Bin kein Profi deswegen ist da manches bisschen hingepfuscht.
Also so als kurzen Überblick was ich geändert habe: - im Webinterface, die blöde MAC-Warnung korrigiert wenn man die Mac nicht klonen möchte.
- im Webinterface die Passwortkontrolle angepasst, dass man auch Kennwörter mit Sonderzeichen benutzen kann und die dann auch richtig gespeichert werden
- dsl.sh so angepasst dass 2 PPPoE Verbindungen aufgebaut werden, eine 1/32 für Internet und eine 2/32 für VOIP
- pppd umgeschrieben dass man mit Parameter -D es unterbinden kann dass die Default-Route bzw. der Nameserver von der zweiten (bei mir VOIP) überschrieben wird, denn man kann nur über die Internet-Leitung surfen.
- in die /etc/hosts arcor.de mit der internen 10er-IP eingetragen damit VOIP über die zweite Verbindung läuft.
- vodsl benutzt beim Sip-Protokoll den Parameter a=silenceSupp:off dies mag der Arcor-SIP-Server nicht, aufgrund dessen die Verbindung nicht aufgebaut werden kann. Es kommt die Fehlermeldung 503 Service Unavailable. da das Programm leider Closed-Source ist musste ich etwas "pfuschen" ich habe ein kleines SIP-Proxy-Programm geschrieben sipp, er schaut sich alle Pakete an und ersetzt den Parameter geschickt, so dass VOIP funktioniert. Um die Pakete nicht zu sehr zu verändern habe ich ihn transparent eingebunden. Spricht mit iptables das Packet zu Arcor zum Proxy umgeleitet dann ersetzt mein Proxy die Stelle und dann wird’s mit Hilfe von iptables wieder zurück zu Arcor gebogen, somit muss ich nur die ausgehenden Pakete betrachten ;-) Man musste im Kernel noch einstellen das iptables auch lokale Pakete ändern darf…
- Das waren eigentlich so die größten Änderungen, bcm_helper musste wegen des Symlinks auch angepasst werden.
Soweit so gut, ich hoffe einigen weiter geholfen zu haben.
Gruß Marc
Da hätt ich ja gern mal einen Patch von den ganzen Änderungen gesehen. Ich bin wirklich beeindruckt, hat sicher ne Menge Arbeit gemacht. Bitte poste wirklich mal deinen Patch und vielleicht hast du ja auch einen guten Vorschlag wie sich das richtig integrieren lässt, denn die zweite ppp-Verbindung scheint mir ja wirklich ein Sonderfall zu sein.
Schade das ich deinen Post erst jetzt entdeckt habe….
Naja hab ein kleines Problem festgestellt, der Voip-Client auf der Targa hat sein Protokoll etwas falsch implementiert, hab einen kleinen Proxy gesschrieben der das etwas behebt, aber ich habe die Packete über netfilter einfach local umgeleitet, nur hat der contrack vom netfilter einen Strich durch die Rechnung gemacht, wollte mit notrack dagegenwirken, hab's aber nicht geschafft die raw-Tabelle mit notrack zu erstellen, bzw denke da ist auch ein Teil closed source. Jetzt gäbe es die Möglichkeit einen besseren Proxy zu programmieren aber dazu fehlte mir dann doch die Lust. das ppp hab ich einfach umgeschrieben.
Ist trotzdem sehr interessant und versteh nicht was das conntrack damit zu tun hat bzw. was du mit besserem Proxy meinst? Passiert denn der Fehler mit dem Arcor-SIP-Server nur bei Gesprächsbeginn oder schon bei der Anmeldung?
Ist es denn immer so das bei Arcor eine zweite ppp-Verbindung aufgebaut wird? Wird diese auch mit anderen Einwahldaten (Username/Passwor etc.) benutzt?
DSL EasyBox A401 ersetzten durch Targa WR 500 Voip
Im Webinterface der EasyBox A401 erkennt man auf Startseite im „Ereignislogbuch“, dass 2 DSL-Verbindungen aufgebaut wurden.
Ereignislogbuch:
12/01/2008 00:00:28 If(PPPoE1) PPP connection ok !
12/01/2008 00:00:28 If(PPPoE2) PPP connection ok !
12/01/2008 00:00:27 If(PPPoE1) get secondary DNS IP:195.***.***.***
12/01/2008 00:00:27 If(PPPoE1) get primary DNS IP:195.***.***.***
12/01/2008 00:00:27 If(PPPoE1) get IP:188.***.***.***
12/01/2008 00:00:27 If(PPPoE2) get secondary DNS IP:10.***.***:***
12/01/2008 00:00:27 If(PPPoE2) get primary DNS IP:10.***.***.***
12/01/2008 00:00:27 If(PPPoE2) get IP:10.***.***.***
12/01/2008 00:00:27 If(PPPoE1) start PPP
12/01/2008 00:00:27 If(PPPoE1) receive PADS
12/01/2008 00:00:27 If(PPPoE1) send PADR
12/01/2008 00:00:27 If(PPPoE1) receive PADO
12/01/2008 00:00:27 If(PPPoE2) start PPP
12/01/2008 00:00:27 If(PPPoE2) receive PADS
12/01/2008 00:00:27 If(PPPoE2) send PADR
12/01/2008 00:00:27 If(PPPoE2) receive PADO
12/01/2008 00:00:26 If(PPPoE2) send PADI
12/01/2008 00:00:26 If(PPPoE1) send PADI
12/01/2008 00:00:25 ADSL Media Up !
Es wurden also 2 PPPoE-Verbindungen aufgebaut, eine mit der Internet-IP-Adresse (188.***.***.***) und der Intranet-IP-Adresse (10.***.***.***).
Die Vermutung liegt Nahe, dass Voip über die Interne Verbindung läuft und das Internet über die andere.
Diese Vermutung wird bestätigt, wenn man im Webinterface unter EXTRAS / Diagnoseprogramm sich die Protokolle von VC1 und VC2 anschaut.
Problem1:
- Keine Zugangsdaten von Arcor, sondern nur ein Modem-Installations-Code.
Lösung1:
- Die Voip-Zugangsdaten können mit dem VC2-Protokoll und durch BruteForce entschlüsselt werden. Passende Software findet man im Internet. Jedoch benötigen wir noch die Zugangsdaten für die PPPoE-Verbindungen.
- Um die anderen Zugangsdaten zu erhalten, benötigt man einen älteren Router. z.B. A400.
1. Den alten Router mit dem Modeminstallationscode einrichten.
2. Alte Firmware auf den A400-Router spielen.
3. Config-Datei speichern.
4. Config-Datei mit einem Hex-Editor öffnen und mit FF XOR-verknüpfen.
5. Nun stehen die Zugangsdaten der PPP-Verbindung im Klartext in der neuen Config-Datei.
Man erkennt sowohl das vorher entschlüsselte Voip-Kennwort, als auch die PPPoE Benutzernamen und Kennwörter.
Die Benutzernamen der beiden Verbindungen sowie die Kennwörter sind gleich.
Nun haben wir die Informationen, die wir brauchen um den Targa WR500 einzurichten.
Zum Glück gibt es schon die Bitswitcher- Software diese muss nur wie folgt verändert werden.
- Es müssen 2 PPPoE-Verbindungen aufgebaut werden.
- Der Voip-Client muss zum Funktionieren gebracht werden, leider ist er closed source und somit nicht veränderbar, und da der Client auch die Hardware steuert kann er nicht durch Asterisk ersetzt werden.
- Ein weiteres Problem ist, dass beide PPPoE-Verbindungen sich als Gateway eintragen wollen, dazu muss PPPoE umgeschrieben werden.
Die Probleme mit der 2 PPPoE-Verbindungen sind behoben, auch der PPPoE-Client hab ich umgeschrieben. Nur leider macht der Voip-Client Schwierigkeiten.
Das Protokoll ist „fehlerhaft“ implementiert, es werden Optionen mitgeschickt an der sich der Arcor-Sip-Server verschluckt.
(Mit einem SIP-Client auf dem Computer kann über die Intranet-Verbindung ohne Probleme telefoniert werden.)
Hab ein kleiner Programm geschrieben dass die fehlerhaften Optionen durch andere ersetzt, die funktionieren.
(Hab einfach die Pakete vom Tagra-Voip-Client mit denen vom Computer Voip-Client vergleichen/ersetzt.)
Um die Pakete zu manipulieren habe ich den Netfilter benutzt. Dieser leitet die ausgehenden Pakete zu dem Programm um. Dies funktioniert auch ganz gut und der Voip-Client kann sich am Arcor-Sip-Server anmelden und es kann raustelefoniert werden.
Das noch bestehende Problem ist dass ein eingehendes Gespräch vom Sip-Server initiiert wird, also das erste UDP-Paket kommt vom Server.
Die Contrack-Funktion vom Netfilter merkt sich ah ok Server will von Port 5060 zu Port 5060 und setzt daraufhin die Rückroute, damit der Server auch wieder Pakte vom Client bekommt, nur leider wird dadurch nicht mehr die „Umleitregel“ ausgeführt, welche dafür sorgen sollte die Pakete zu manipulieren. Jetzt gäbe es die Möglichkeit einen kompletten Sip-Proxy für den Router zu schreiben, dass der Targa-Voip-Client denkt er meldet sich am Proxy an und nicht beim Sip-Server.
Die alternative, die ich versucht habe war das Notrack in die Raw-Tabelle einzubauen und somit dem Netfilter anweise er soll Packete von 5060 nicht mit mit der Contrack-Funktionalität ausstatten. Doch leider geling mit das nicht, da vermutlich die Contrack-Tabelle auch closed source ist. Also bleibt wohl nur die Möglichkeit des Proxys.
Gruß Marc
Der Sip-Server von sipgate.de hat keine Probleme mit dem Targa Voip-Client.
Gruß Marc
Sehr schöne Anleitung und ich bin ja entsetzt wie sehr der Provider versucht mit Installationscodes etc. den ganzen Krempel zu verbergen. Ist m.M.n. Schwachsinn da das eher zu Unzufriedenheit führt….aber egal.
Wegen dem Conntrack, denke ich sind folgende Zeilen aus dem firewall.sh-Skript Schuld:
491 setup_sip_input()
492 {
493 echo "setup_sip_input()" >>$DEBUG_FILE
494 exec_cmd "iptables -N SIP_INPUT"
495 exec_cmd "iptables -F SIP_INPUT"
496
497 voip_start=`nvram get voip_start`
498 if ; then
499 ata_regport=`nvram get ata_regport`
500 && ata_regport=5060
501 exec_cmd "iptables -A SIP_INPUT -p udp -dport $ata_regport -m state -state NEW -j ACCEPT"
502 # the original w500v opens the ports 16384..16400 too, sometimes an incomming call uses this ports
503 exec_cmd "iptables -A SIP_INPUT -p udp -dport 16384:16400 -m state -state NEW -j ACCEPT"
504 fi
505 exec_cmd "iptables -A SIP_INPUT -j RETURN"
506 }
Ich schlage daher folgende zusätzlich Regeln vor, die verhindern sollten das die Verbindung "stateful" behandelt wird (am besten in die custom-rules eintragen):
#SIP chain leeren
iptables -F SIP_INPUT
#eingehende Pakete einfach nur accepten aber NICHT stateful behandeln
iptables -A SIP_INPUT -p udp -dport 5060 -j ACCEPT
iptables -A SIP_INPUT -p udp -dport 16384:16400 -j ACCEPT
Wenn du noch Lust hast, dann probier das ruhig mal aus. Das sollte eigentlich das Problem lösen denke ich.
Achja, wollte noch fragen wo du die Sourcen vom pppd her hast, die liegen doch glaub ich gar nicht im dev_tree sondern sind auch von Broadcom nur als Binary mit gekommen?!
Das mit der Regel in der Firewall hat nichit funktinoiert, es wird dennoch in die Contrack-Tabelle aufgenommen.
Den Quellcode von pppdoe gibts in der Toolchain von Bitswitcher.
Also entweder schaff ichs noch irgendwie der raw-Tabelle beizubringen, dass sie auch den NOTRACK-Filter kann oder ich muss das Proxy-Programm umschreiben.
Gruß Marc
Hallo Marc,
ich bin seit den letzten Tagen dabei deine Änderungen mal nachzuvollziehen, aber einige deiner Angaben sind
etwas unzureichend.
Ich habe bis jetzt folgendes gemacht:
-Web-Interface und Startskripte angepasst, es kann jetzt eine zweite ATM-Verbindung und eine
zweite PPP-Verbindung konfiguriert werden
-PPPd um "-D" erweitert sodass GW und DNS nicht überschrieben werden
-bcm_helper erweitert sodass das zweite PPP-Device auf .ppp1 verlinkt wird
Was ich jetzt nicht weiß, welche SIP-Optionen dem Arcor-Server Probleme machen und durch welche im Detail diese ersetzt werden müssen. Oder muss einfach nur a=silenceSupp:off aus dem Invite entfernt werden? Gib mir vielleicht mal noch ein bissel Hilfestellung bzw. kannst du meine Änderungen auch im svn mal anschauen und ggf. testen. Achja, wenn man anstelle von arcor.de gleich die richtige Registrar/Proxy-IP im Webinterface eingibt sollte doch die Manipulation der /etc/hosts nicht notwendig sein oder?!
Hier mein Proxy-Programm:
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <netinet/in.h>
#define BUFFSIZE 2000
void Die(char*);
char* strreplace(char*, char*, char*);
char* correctLen(char*,int);
void Die(char *mess) { perror(mess); exit(1); }
char* strreplace(char* text, char* find, char* replace)
{
char* p;
char* ret;
ret = text;
p = strstr (text,find);
if (p != NULL)
{
ret = malloc(strlen(text) + strlen(replace) + 1 - strlen(find));
if (ret == NULL) Die("ret == NULL");
if (p != text)
strncpy(ret, text, p-text);
strcpy(ret + (p-text), replace);
strcat(ret, p + strlen(find));
}
return ret;
}
char* correctLen(char* text, int contlen)
{
char start = "Content-Length:";
char end = "\r\n";
char contentlen;
char* startpos;
char* endpos;
char* ret;
ret = text;
startpos = strstr(text,start);
if (startpos != NULL)
endpos = strstr(startpos,end);
if (startpos != NULL && endpos != NULL)
{
snprintf (contentlen, (size_t)10, "%d", contlen);
ret = malloc(strlen(text) + 3);
if (startpos != text)
strncpy(ret, text, startpos-text+strlen(start));
strcat(ret,contentlen);
strcat(ret, endpos);
}
return ret;
}
int main(int argc, char *argv) {
int sock;
struct sockaddr_in server;
struct sockaddr_in fromclient;
struct sockaddr_in toserver;
char buffer;
char head;
char content;
char user1="User-Agent: TARGA WR 500 VoIP / Firmware v0.13 MxSF/v3.2.6.26";
char user2="User-Agent: DSL-EasyBox/DSL-EasyBox-10.02.506";
char content1="a=silenceSupp:off";
char content2="a=ptime:20\r\na=sendrecv";
char delimiter="\r\n\r\n";
unsigned int clientlen, serverlen;
int received = 0;
/* Create the UDP socket */
if ((sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
Die("Failed to create socket");
}
/* Construct the server sockaddr_in structure */
memset(&server, 0, sizeof(server)); /* Clear struct */
server.sin_family = AF_INET; /* Internet/IP */
server.sin_addr.s_addr = htonl(INADDR_ANY); /* Any IP address */
server.sin_port = htons(5061); /* server port */
/* Construct the server sockaddr_in structure */
memset(&toserver, 0, sizeof(toserver)); /* Clear struct */
toserver.sin_family = AF_INET; /* Internet/IP */
toserver.sin_addr.s_addr = inet_addr("10.64.112.6"); /* IP address */
//toserver.sin_addr.s_addr = inet_addr("192.168.2.100");
toserver.sin_port = htons(5061); /* server port */
/* Bind the socket */
serverlen = sizeof(server);
if (bind(sock, (struct sockaddr *) &server, serverlen) < 0) {
Die("Failed to bind server socket");
}
/* Run until cancelled */
while (1) {
/* Receive a message from the client */
clientlen = sizeof(fromclient);
if ((received = recvfrom(sock, buffer, BUFFSIZE, 0,
(struct sockaddr *) &fromclient,
&clientlen)) < 0) {
Die("Failed to receive message");
}
/*
fprintf(stderr,
"Client connected: %s\n", inet_ntoa(fromclient.sin_addr));
*/
buffer='\0';
/*Filtern ersetzten uvm.
User-Agent: TARGA WR 500 VoIP / Firmware v0.13 MxSF/v3.2.6.26
ersetzten zu User-Agent: DSL-EasyBox/DSL-EasyBox-10.02.506
*/
strcpy(buffer,strreplace(buffer,user1,user2));
char* p;
char* test;
int headlen;
test = strstr(buffer,content1);
if(test != NULL && test-buffer < received)
{
p=strstr(buffer,delimiter);
if (p != NULL)
{
head='\0';
content='\0';
headlen=p-buffer+strlen(delimiter);
strncpy(head,buffer,headlen);
head='\0';
strcpy(content,p+strlen(delimiter));
strcpy(content,strreplace(content,content1,content2));
strcpy(head,correctLen(head,strlen(content)));
strcpy(buffer,head);
strcat(buffer,content);
}
}
received = strlen(buffer);
/* Send the message back to client */
if (sendto(sock, buffer, received, 0,
(struct sockaddr *) &toserver,
sizeof(toserver)) != received) {
Die("Mismatch in number of echo'd bytes");
}
}
}
Die Portumleitung hab ich mit iptables umgebogen, jedoch spielt mir bei eingehenden Anrufen die contrack-Tabelle einen Strich durch die Rechnung… Eventuell einen kompletten Proxy basteln.
Wenn du Sipgate einträgst funktionierts ohne Probleme mit dem SipClient, da muss kein Proxy verwendet werden, jedoch braucht man bei Sipgate auch keine zweite PPP-Verbindung ;-) Hab das Projekt erstmal eingestellt, da ich ein zuverlässiges Tel brauche und mit der bisherigen Lösung nicht angerufen werden kann.
Ich hab zur Lösung des Proxy-Problems ein iptables mangle Modul geschrieben (zu finden im svn).
Damit lassen sich einzelne SIP-Attribute oder Header Zeilen anfügen, löschen oder ersetzen.
Da das Modul in der mangle-Table sitzt sollte das conntrack kein Problem sein.
Dein Proxy lässt sich mit Hilfe des Moduls dann durch folgendes Skript ersetzen: