Hallo,
nachdem ich nun endlich die korrekten SIP-Daten für Alice ermitteln konnte, wollte ich diese gleich mit dem W500 und der BS-Firmware ausprobieren.
Leider gibt es derzeit noch ein technisches Problem, was dies verhindert:
- Man benötigt bei Alice eine zweite PPP-Session mit einem separaten User/Passwort. Dies kann ich auch in BS anlegen und soweit ich das mitbekommen habe, verbindet sich die Kiste auch damit
- Der IP-Kreis dieses Verbindung ist 10.192.x.x. Hier baut der Router aber Mist, scheinbar erkennt er dies nicht als WAN-IP oder was auch immer. Jedenfalls klappt der Zugriff auf die Adressen irgendwie nicht.
- Lege ich diese PPP-Verbindung als erste an, so werden die korrekten Daten im Status angezeigt, es ist aber trotzdem keine Einwahl ins SIP möglich. Das Inet funzt dann auch nicht, da der Router dann diese Verbindung für das normale Surfen benutzen will und dort den NAT drauflegt.
Zur Veranschaulichung habe ich noch einen Screenshot gemacht.
Gibt es hier schon Lösungsansätze / Fixes?
Danke!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hier bräuchte ich noch ein paar detailliertere Informationen um den Fehler einzugrenzen. Die Ausgaben folgender Kommandos würden erstmal helfen:
ifconfig -a
route -n
Geht ein ping zum Registrar bzw. zum SIP-Proxy? Hilft ein manuellen Freigeben des zweiten ppp-Interfaces und das Einfügen einer NAT-Regel für das zweite PPP-Device etwa so?
iptables -A INPUT -i ppp_x_xx_x -j ACCEPT
iptables -A OUTPUT -o ppp_x_xx_x -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp_x_xx_x -j MASQUERADE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ware schön wenn du es mal runterladen und bei dir auf den Router unter '/etc/start_scripts/' kopieren könntest. Nach einem Neustart sollte dann die zweite ppp-Verbindung frei gegeben sein.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Web-Shell> ping -c 1 sip.alice-voip.de
ping: bad address 'sip.alice-voip.de'
-> Es wird der falsche DNS benutzt. Richtig wäre der DNS der 2.PPP-Verbindung. Wahrscheinlich ist das auch beim Voip so. Ich vermute, dass hier das Hauptproblem liegt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Es klappt zwar immer noch nicht, aber ich denke ich bin schon einen Schritt weiter.
Was definitiv noch fehlt, ist der DNS der 10er Verbindung. Ich weiss nur nicht, wie ich den auf der Shell ermitteln kann und dann manuell setzen könnte?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nee bei der 0.3.9 hat sich in dem Punkt nichts mehr geändert. Wir müssen erstmal rausfinden wie sich die Sache lösen lässt.
Versuch doch mal auf der shell die zweite ppp-Verbindung manuell zu starten. Also mit
ps ax
alle Prozesse anzeigen lassen. Da siehst du auch gleich alle Parameter die du dem pppd mitgeben musst. Dann beende den richtigen pppd mit
kill -9 <pid>
und starte ihn anschließend manuell. Da solltest du in den Ausgaben sehen welchen GW und welchen DNS er bezieht. Den DNS musst du dann in
/etc/resolv.conf
eintragen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"ps ax" gibt es nicht, aber "ps w".
Wenn ich den pppd-Prozess kille und ihn dann neu starte, kommt leider nur folgender Textoutput: "pppoe device is init."
Ideen?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Habe mit den "nameserver"-Einträgen experimentiert: Es macht keinen Unterschied, ob diese gesetzt sind oder nicht. Zumindest, wenn man in den VoIP-Einstellungen IPs anstatt FQDNs verwendet.
Was definitiv fehlt, ist der Routing-Eintrag für das Subnetz. Erst wenn ich manuell eine Route für 10.192.0.0 via den Default-GW der 2.PPP einrichte, kommt der Connect zustande.
Funzen tut es dann leider trotzdem immer noch nicht, es kommt beim Abnehmen ein unterbrochener Freiton (ca. 2 Sekunden Ton, dann kurze Unterbrechung usw.). Man kann weder angerufen werden noch raustelefonieren. Allerdings kommt beim angerufen werden nicht sofort die Meldung "Der gewünschte Gesprächspartner…:", sondern es dauert eine ganze Weile. Ich vermute, das hier auf höherer Ebene (Protokoll?) noch was fehlschlägt.
Gibt es die Möglichkeit, hier auf der Shell irgend eine Form von Debugging einzuschalten?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
nachdem ich nun endlich die korrekten SIP-Daten für Alice ermitteln konnte, wollte ich diese gleich mit dem W500 und der BS-Firmware ausprobieren.
Leider gibt es derzeit noch ein technisches Problem, was dies verhindert:
- Man benötigt bei Alice eine zweite PPP-Session mit einem separaten User/Passwort. Dies kann ich auch in BS anlegen und soweit ich das mitbekommen habe, verbindet sich die Kiste auch damit
- Der IP-Kreis dieses Verbindung ist 10.192.x.x. Hier baut der Router aber Mist, scheinbar erkennt er dies nicht als WAN-IP oder was auch immer. Jedenfalls klappt der Zugriff auf die Adressen irgendwie nicht.
- Lege ich diese PPP-Verbindung als erste an, so werden die korrekten Daten im Status angezeigt, es ist aber trotzdem keine Einwahl ins SIP möglich. Das Inet funzt dann auch nicht, da der Router dann diese Verbindung für das normale Surfen benutzen will und dort den NAT drauflegt.
Zur Veranschaulichung habe ich noch einen Screenshot gemacht.
Gibt es hier schon Lösungsansätze / Fixes?
Danke!
Hier bräuchte ich noch ein paar detailliertere Informationen um den Fehler einzugrenzen. Die Ausgaben folgender Kommandos würden erstmal helfen:
Geht ein ping zum Registrar bzw. zum SIP-Proxy? Hilft ein manuellen Freigeben des zweiten ppp-Interfaces und das Einfügen einer NAT-Regel für das zweite PPP-Device etwa so?
Ich habe auch im aktuellen firewall.sh-Skript die obigen Regeln mal eingebaut.
Das findest du hier: http://bitswitcher.svn.sourceforge.net/viewvc/bitswitcher/trunk/dev_tree/bs_extra/start_scripts/firewall.sh?revision=176
Ware schön wenn du es mal runterladen und bei dir auf den Router unter '/etc/start_scripts/' kopieren könntest. Nach einem Neustart sollte dann die zweite ppp-Verbindung frei gegeben sein.
Hallo!
Danke für die Antwort(en). Ich probiere es gleich mal aus und liefer Dir die Ausgaben der Kommandos.
Hallo, ich habe das Skript eingespielt. Leider bringt es augenscheinlich keine Änderung.
Hier die Ausgaben der Befehle:
Web-Shell> ifconfig -a
atm0 Link encap:UNSPEC HWaddr 00-80-10-00-31-00-10-00-00-00-00-00-00-00-00-00
MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:617232 (602.7 KiB) TX bytes:148368 (144.8 KiB)
br0 Link encap:Ethernet HWaddr 00:03:C9:B3:33:30
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1272 errors:0 dropped:0 overruns:0 frame:0
TX packets:1437 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:178976 (174.7 KiB) TX bytes:765025 (747.0 KiB)
cpcs0 Link encap:UNSPEC HWaddr 88-D0-FF-FF-FF-00-10-00-00-00-00-00-00-00-00-00
MTU:65535 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:617232 (602.7 KiB) TX bytes:148368 (144.8 KiB)
dsl0 Link encap:UNSPEC HWaddr 88-D0-00-00-00-00-10-00-00-00-00-00-00-00-00-00
MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 00:03:C9:B3:33:30
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1272 errors:0 dropped:0 overruns:0 frame:0
TX packets:1437 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:201872 (197.1 KiB) TX bytes:774181 (756.0 KiB)
Interrupt:28 Base address:0x6000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
nas_1_32 Link encap:Ethernet HWaddr 00:03:C9:B3:33:32
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:682 errors:0 dropped:0 overruns:0 frame:0
TX packets:826 errors:0 dropped:14 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:584771 (571.0 KiB) TX bytes:124668 (121.7 KiB)
nas_1_35 Link encap:Ethernet HWaddr 00:03:C9:B3:33:33
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:14 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1434 (1.4 KiB) TX bytes:2468 (2.4 KiB)
ppp_1_32_ Link encap:Point-to-Point Protocol
inet addr:77.6.103.57 P-t-P:213.20.59.72 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:641 errors:0 dropped:0 overruns:0 frame:0
TX packets:780 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:577821 (564.2 KiB) TX bytes:96427 (94.1 KiB)
ppp_1_35_ Link encap:Point-to-Point Protocol
inet addr:10.125.24.155 P-t-P:10.192.127.23 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:54 (54.0 B) TX bytes:54 (54.0 B)
Web-Shell> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.192.127.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp_1_35_1
213.20.59.72 0.0.0.0 255.255.255.255 UH 0 0 0 ppp_1_32_1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
0.0.0.0 213.20.59.72 0.0.0.0 UG 0 0 0 ppp_1_32_1
Was mir aufgefallen ist:
Web-Shell> ping -c 1 sip.alice-voip.de
ping: bad address 'sip.alice-voip.de'
-> Es wird der falsche DNS benutzt. Richtig wäre der DNS der 2.PPP-Verbindung. Wahrscheinlich ist das auch beim Voip so. Ich vermute, dass hier das Hauptproblem liegt.
Habe noch etwas herausgefunden:
Wenn ich manuell eine Route setzen, kriege ich bei "VoIP connection: connection established":
route add -net 10.192.0.0 netmask 255.255.0.0 gw 10.192.127.21
Es klappt zwar immer noch nicht, aber ich denke ich bin schon einen Schritt weiter.
Was definitiv noch fehlt, ist der DNS der 10er Verbindung. Ich weiss nur nicht, wie ich den auf der Shell ermitteln kann und dann manuell setzen könnte?!
Macht es Sinn die 0.3.9 zu testen oder ist da nichts weiter gefixt worden, was hierfür relevant ist?
Nee bei der 0.3.9 hat sich in dem Punkt nichts mehr geändert. Wir müssen erstmal rausfinden wie sich die Sache lösen lässt.
Versuch doch mal auf der shell die zweite ppp-Verbindung manuell zu starten. Also mit
alle Prozesse anzeigen lassen. Da siehst du auch gleich alle Parameter die du dem pppd mitgeben musst. Dann beende den richtigen pppd mit
und starte ihn anschließend manuell. Da solltest du in den Ausgaben sehen welchen GW und welchen DNS er bezieht. Den DNS musst du dann in
eintragen.
"ps ax" gibt es nicht, aber "ps w".
Wenn ich den pppd-Prozess kille und ihn dann neu starte, kommt leider nur folgender Textoutput: "pppoe device is init."
Ideen?
Okay, es kommt auch noch:
PPP: PPP1_35_1 Start to connect …
PPP: PPP1_35_1 Connection Up.
Aber kein GW oder DNS
Habe mit den "nameserver"-Einträgen experimentiert: Es macht keinen Unterschied, ob diese gesetzt sind oder nicht. Zumindest, wenn man in den VoIP-Einstellungen IPs anstatt FQDNs verwendet.
Was definitiv fehlt, ist der Routing-Eintrag für das Subnetz. Erst wenn ich manuell eine Route für 10.192.0.0 via den Default-GW der 2.PPP einrichte, kommt der Connect zustande.
Funzen tut es dann leider trotzdem immer noch nicht, es kommt beim Abnehmen ein unterbrochener Freiton (ca. 2 Sekunden Ton, dann kurze Unterbrechung usw.). Man kann weder angerufen werden noch raustelefonieren. Allerdings kommt beim angerufen werden nicht sofort die Meldung "Der gewünschte Gesprächspartner…:", sondern es dauert eine ganze Weile. Ich vermute, das hier auf höherer Ebene (Protokoll?) noch was fehlschlägt.
Gibt es die Möglichkeit, hier auf der Shell irgend eine Form von Debugging einzuschalten?