Hallo, nachdem ich eine Baustelle geschlossen habe und der Laptop nun wieder ins Internet kann, versuche ich die zweite Baustelle zu schließen. Ich möchte einen PocketPC, der über SynCE eingebunden wird, ansprechen können. Der PocketPC hat mit synce-serial-config die IP 192.168.0.44 und die DNS 192.168.0.1 zugwiesen bekommen. Der PC, an dem der PocketPC über USB hängt, hat die IP 192.168.0.55. Über eth1 geht es in das Netz 192.168.0.0/24 und über ppp0(eth0) ins Internet. Früher habe ich das Thema über einen Ausgang aus der Firewall gelöst (angepaßtes Script von SuSE). Das hatte allerdings den Nachteil, daß das Internet nicht ging, wenn der PocketPC angesprochen wurde (beides ging nicht). Ich habe nun den PocketPC in die /etc/hosts eingetragen und er kann auch von synce-serial-start gefunden werden. In der Firewall habe ich weitere Ports geöffnet: FW_SERVICES_INT_TCP="22 80 8080 10001 139 5678 5679 990" Die Ports 5678 und 5679 werden vom PocketPC gebraucht, während der PC 990 benutzt (evtl. muß der dann noch wo anders rein?). Ich bekomme nun folgende Meldungen der Firewall: Feb 27 23:10:47 linux kernel: SuSE-FW-DROP-NEW-CONNECT IN=ppp0 OUT= MAC= SRC=192.168.0.1 DST=192.168.0.44 LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=64022 DF PROTO=TCP SPT=1092 DPT=5679 WINDOW=32768 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402) Es werden Pakete verworfen. Liegt das daran, daß noch ein Port nicht geöffnet ist oder versucht er über das Device eth1 die Pakete zu leiten? Braucht der PocketPC ein eigenes Netz, das dann über USB zu erreichen ist? Vielen Dank für jeden Tip und schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
* Sonntag, 27. Februar 2005 um 23:19 (+0100) schrieb Andreas Mantke:
Der PocketPC hat mit synce-serial-config die IP 192.168.0.44 und die DNS 192.168.0.1 zugwiesen bekommen. Der PC, an dem der PocketPC über USB hängt, hat die IP 192.168.0.55. Über eth1 geht es in das Netz 192.168.0.0/24 und über ppp0(eth0) ins Internet. Früher habe ich das Thema über einen Ausgang aus der Firewall gelöst (angepaßtes Script von SuSE). Das hatte allerdings den Nachteil, daß das Internet nicht ging, wenn der PocketPC angesprochen wurde (beides ging nicht). Ich habe nun den PocketPC in die /etc/hosts eingetragen und er kann auch von synce-serial-start gefunden werden. In der Firewall habe ich weitere Ports geöffnet:
FW_SERVICES_INT_TCP="22 80 8080 10001 139 5678 5679 990"
Die Ports 5678 und 5679 werden vom PocketPC gebraucht, während der PC 990 benutzt (evtl. muß der dann noch wo anders rein?).
Ich bekomme nun folgende Meldungen der Firewall: Feb 27 23:10:47 linux kernel: SuSE-FW-DROP-NEW-CONNECT IN=ppp0 OUT= MAC= SRC=192.168.0.1 DST=192.168.0.44 LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=64022 DF PROTO=TCP SPT=1092 DPT=5679 WINDOW=32768 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402)
Hm, da stimmt anscheinend das Routing nicht ganz. Wer hat die "192.168.0.1" und wo "steht" (Wie ist er an den o.g. Internet-Router angeschlossen?) dieser Rechner? Welcher Rechner soll mit dem PocketPC kommunizieren? Wie lauten die Ausgaben auf dem Internet-Router (ohne Internetverbindung, aber mit Verbindung zum PocketPC) von: 'ifconfig' und 'route -n'? (Wenn möglich, auch die äquivalenten Angaben vom PocketPC.) Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Andreas, hallo *, Am Montag, 28. Februar 2005 12:10 schrieb Andreas Koenecke: (...)
Hm, da stimmt anscheinend das Routing nicht ganz. Wer hat die "192.168.0.1" und wo "steht" (Wie ist er an den
Die hatte bisher kein PC. Ich habe jetzt 192.168.0.55 eingestellt und bekomme keine Firewallmeldungen wie oben mehr (jetzige Meldungen siehe meine andere Mail).
o.g. Internet-Router angeschlossen?) dieser Rechner? Welcher Rechner soll mit dem PocketPC kommunizieren? Wie lauten die Ausgaben auf dem Internet-Router (ohne Internetverbindung, aber mit Verbindung zum PocketPC) von: 'ifconfig' und 'route -n'?
Ausgabe von (nach Umstellen auf Remote-Adress 192.168.0.55=eth1 des PC): route -n Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.55 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 <-------- snip ---> und von ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:30:84:73:A4:FF inet6 Adresse: fe80::230:84ff:fe73:a4ff/64 Gültigkeitsbereich:Verbindung UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1734 errors:0 dropped:0 overruns:0 frame:0 TX packets:1646 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:1618327 (1.5 Mb) TX bytes:155153 (151.5 Kb) Interrupt:10 Basisadresse:0x8000 eth1 Protokoll:Ethernet Hardware Adresse 00:80:AD:78:9F:D9 inet Adresse:192.168.0.55 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::280:adff:fe78:9fd9/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:11 Basisadresse:0xe000 lo Protokoll:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5515 errors:0 dropped:0 overruns:0 frame:0 TX packets:5515 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:1649992 (1.5 Mb) TX bytes:1649992 (1.5 Mb) ppp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:192.168.0.44 P-z-P:192.168.0.55 Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:52 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:3 RX bytes:2961 (2.8 Kb) TX bytes:115 (115.0 b)
(Wenn möglich, auch die äquivalenten Angaben vom PocketPC.)
Da muß ich im Moment passen. Keine Ahnung, wie ich dem die entlocke??? Schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
* Montag, 28. Februar 2005 um 19:01 (+0100) schrieb Andreas Mantke:
Am Montag, 28. Februar 2005 12:10 schrieb Andreas Koenecke:
Hm, da stimmt anscheinend das Routing nicht ganz. Wer hat die "192.168.0.1" und wo "steht" (Wie ist er an den
Die hatte bisher kein PC.
Aber irgend ein Rechner hat Pakete mit dieser Quell-Adresse versendet. Ich vermute (wie auch Jan), die 192.168.0.1 hatte der PocketPC.
Ich habe jetzt 192.168.0.55 eingestellt und bekomme keine Firewallmeldungen wie oben mehr (jetzige Meldungen siehe meine andere Mail).
Das macht die Sache aber noch schlimmer...
Ausgabe von (nach Umstellen auf Remote-Adress 192.168.0.55=eth1 des PC): route -n
Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.55 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
und von ifconfig
[ ... ]
eth1 Protokoll:Ethernet Hardware Adresse 00:80:AD:78:9F:D9 inet Adresse:192.168.0.55 Bcast:192.168.0.255 Maske:255.255.255.0 [ ... ]
ppp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:192.168.0.44 P-z-P:192.168.0.55 Maske:255.255.255.255
Jetzt haben sowohl "eth1" als auch das PPP-Device des PocketPC die "192.168.0.55". Ich würde dir raten, die PPP-Verbindung in ein anderes Netz zu legen, z.B. "192.168.1.1(/24)" für den Router und "192.168.1.2(/24)" für den PocketPC. Mehr in meiner Antwort zu deinem anderen Posting.
(Wenn möglich, auch die äquivalenten Angaben vom PocketPC.)
Da muß ich im Moment passen. Keine Ahnung, wie ich dem die entlocke???
Wenn man auf so einem PocketPC noch 'cmd.exe' oder 'command.exe' ausführen kann, dann dort 'ipconfig'(?) und 'route print'. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Am Sonntag, 27. Februar 2005 23:19 schrieb Andreas Mantke:
nachdem ich eine Baustelle geschlossen habe und der Laptop nun wieder ins Internet kann, versuche ich die zweite Baustelle zu schließen. Ich möchte einen PocketPC, der über SynCE eingebunden wird, ansprechen können. Der PocketPC hat mit synce-serial-config die IP 192.168.0.44 und die DNS 192.168.0.1 zugwiesen bekommen.
192.168.0.1 als DNS-Server? Nicht als Remote-IP?
Der PC, an dem der PocketPC über USB hängt, hat die IP 192.168.0.55. Über eth1 geht es in das Netz 192.168.0.0/24 und über ppp0(eth0) ins Internet.
Ich kenne SynCE nicht, aber wenn ich mir das über google so abgucke, dann benutzt das ppp. Und du hast ja schon einen ppp laufen. Kann es sein, daß sich die dann "beißen"? Was ist die Ausgabe von "synce-serial-start"?
Früher habe ich das Thema über einen Ausgang aus der Firewall gelöst (angepaßtes Script von SuSE). Das hatte allerdings den Nachteil, daß das Internet nicht ging, wenn der PocketPC angesprochen wurde (beides ging nicht).
Wie genau hast du das gelöst?
Ich habe nun den PocketPC in die /etc/hosts eingetragen und er kann auch von synce-serial-start gefunden werden. In der Firewall habe ich weitere Ports geöffnet:
FW_SERVICES_INT_TCP="22 80 8080 10001 139 5678 5679 990"
Damit öffnest du Ports für die Pakete, die über das interne Interface, also eth1 'reinkommen. Der PocketPC hängt aber gar nicht an eth1 ...
Die Ports 5678 und 5679 werden vom PocketPC gebraucht, während der PC 990 benutzt (evtl. muß der dann noch wo anders rein?).
... wie man hier sieht:
Ich bekomme nun folgende Meldungen der Firewall: Feb 27 23:10:47 linux kernel: SuSE-FW-DROP-NEW-CONNECT IN=ppp0 OUT= MAC= SRC=192.168.0.1 DST=192.168.0.44 LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=64022 DF PROTO=TCP SPT=1092 DPT=5679 WINDOW=32768 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402)
Es werden Pakete verworfen.
"IN=ppp0" Eigentlich ist ppp0 doch dein "Internet", oder? Anscheinend schnappt sich SynCE das ppp0, dann funktioniert auch kein Internet mehr.
Liegt das daran, daß noch ein Port nicht geöffnet ist oder versucht er über das Device eth1 die Pakete zu leiten?
So wie es aussieht eben nicht über eth1. Dann würde dein FW_SERVICES_INT_TCP wirken und nicht IN=ppp0 im Log stehen.
Braucht der PocketPC ein eigenes Netz, das dann über USB zu erreichen ist?
Soweit ich das verstehe macht der sich für die Kommunikation über USB tatsächlich ein eigenes ppp-Interface. Aber wie das geht, daß er ppp0 nimmt, wenn schon ein ppp auf ppp0 läuft, das ist mir schleierhaft. :-( MfG, Jan -- Don't ever slam a door, you might want to go back.
Hallo Jan, Am Montag, 28. Februar 2005 13:31 schrieb Jan Ritzerfeld:
Am Sonntag, 27. Februar 2005 23:19 schrieb Andreas Mantke:
nachdem ich eine Baustelle geschlossen habe und der Laptop nun wieder ins Internet kann, versuche ich die zweite Baustelle zu schließen. Ich möchte einen PocketPC, der über SynCE eingebunden wird, ansprechen können. Der PocketPC hat mit synce-serial-config die IP 192.168.0.44 und die DNS 192.168.0.1 zugwiesen bekommen.
192.168.0.1 als DNS-Server? Nicht als Remote-IP?
Du hast Recht. Die Ausgabe von synce-serial-start lautet: Serial connection established. Using interface ppp0 Connect: ppp0 <--> /dev/ttyUSB0 local IP address 192.168.0.44 remote IP address 192.168.0.1 Script /etc/ppp/ip-up finished (pid 7934), status = 0x0 LCP terminated by peer Script /etc/ppp/ip-down finished (pid 8281), status = 0x0 Connection terminated. Connect time 1.4 minutes. Sent 1835 bytes, received 2961 bytes. (zum Schluß wird sie abgebrochen, da das Device nicht antwortet, Anfrage kommt aber an, da der PocketPC klingelt).
Der PC, an dem der PocketPC über USB hängt, hat die IP 192.168.0.55. Über eth1 geht es in das Netz 192.168.0.0/24 und über ppp0(eth0) ins Internet.
Ich kenne SynCE nicht, aber wenn ich mir das über google so abgucke, dann benutzt das ppp. Und du hast ja schon einen ppp laufen. Kann es sein, daß sich die dann "beißen"? Was ist die Ausgabe von "synce-serial-start"?
siehe oben. Es ist so, wie Du vermutest.
Früher habe ich das Thema über einen Ausgang aus der Firewall gelöst (angepaßtes Script von SuSE). Das hatte allerdings den Nachteil, daß das Internet nicht ging, wenn der PocketPC angesprochen wurde (beides ging nicht).
Wie genau hast du das gelöst?
Es gibt das Script SuSEFirewallcustom, das unter scripts liegt. Das kann man anpassen und an der angegebenen Stelle in die Firewall einbauen. (...)
In der Firewall habe ich weitere Ports geöffnet:
FW_SERVICES_INT_TCP="22 80 8080 10001 139 5678 5679 990"
Damit öffnest du Ports für die Pakete, die über das interne Interface, also eth1 'reinkommen. Der PocketPC hängt aber gar nicht an eth1 ...
Stimmt, sehe ich jetzt auch klarer. (...)
Ich bekomme nun folgende Meldungen der Firewall: Feb 27 23:10:47 linux kernel: SuSE-FW-DROP-NEW-CONNECT IN=ppp0 OUT= MAC= SRC=192.168.0.1 DST=192.168.0.44 LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=64022 DF PROTO=TCP SPT=1092 DPT=5679 WINDOW=32768 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402)
Es werden Pakete verworfen.
"IN=ppp0" Eigentlich ist ppp0 doch dein "Internet", oder? Anscheinend schnappt sich SynCE das ppp0, dann funktioniert auch kein Internet mehr.
Das habe ich jetzt verstanden. Allerdings wie ändern. Über pppX muß das ja sicherlich weiterhin abgewickelt werden. (...)
Braucht der PocketPC ein eigenes Netz, das dann über USB zu erreichen ist?
Soweit ich das verstehe macht der sich für die Kommunikation über USB tatsächlich ein eigenes ppp-Interface. Aber wie das geht, daß er ppp0 nimmt, wenn schon ein ppp auf ppp0 läuft, das ist mir schleierhaft. :-(
Ich habe es gerade ausprobiert. Wenn ich das Internet zuerst starte, nutzt SynCE ppp1. Ansonsten blockiert es ppp0. So nun habe ich das ganze noch einmal anders eingestellt: Remote-Adresse auf 192.168.0.55 (PC-Adresse an eth1) umgestellt: Ausgabe in /var/log/messages nun: Feb 28 18:47:38 linux synce-serial-start: Executing '/usr/sbin/pppd call synce-device' Feb 28 18:47:38 linux pppd[11734]: pppd 2.4.1 started by andi, uid 0 Feb 28 18:47:39 linux pppd[11734]: Serial connection established. Feb 28 18:47:39 linux pppd[11734]: Using interface ppp0 Feb 28 18:47:39 linux pppd[11734]: Connect: ppp0 <--> /dev/ttyUSB0 Feb 28 18:47:39 linux pppd[11734]: local IP address 192.168.0.44 Feb 28 18:47:39 linux pppd[11734]: remote IP address 192.168.0.55 Feb 28 18:47:40 linux SuSEfirewall2: Firewall rules successfully set in QUICKMODE for device(s) " ppp+" plus masquerading Feb 28 18:47:40 linux pppd[11734]: Script /etc/ppp/ip-up finished (pid 11756), status = 0x0 Feb 28 18:47:45 linux poll.tcpip: fetchmail: Query status=11 (DNS) Also keine Firewall-Drop-Meldungen (nur cer Versuch von fetchmail, Mails aus dem Postfach zu holen) mehr, aber es geht trotzdem noch kein Besuch auf dem Device (Browsen mit Konqui). Schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
* Montag, 28. Februar 2005 um 19:03 (+0100) schrieb Andreas Mantke:
Ich habe es gerade ausprobiert. Wenn ich das Internet zuerst starte, nutzt SynCE ppp1. Ansonsten blockiert es ppp0.
Ja, "wer zuerst kommt, mahlt zuerst"... Sofern der 'pppd' nicht allzu alt ist, kann man ihn mit einer Option anweisen, ein bestimmtes "pppX" zu benutzen. Dazu muss man aber erst einmal herausfinden, _wo_ man die Option setzen kann: AFAIR erzeugt 'synce-serial-config' ein "${PEER_FILE}". Schau doch mal unter "/etc/ppp/" und "/etc/ppp/peers/", ob du dort eine entsprechende Datei findest. In dieser Datei fügst du noch ein "unit 1" hinzu und 'synce' sollte zukünftig immer "ppp1" verwenden.
So nun habe ich das ganze noch einmal anders eingestellt: Remote-Adresse auf 192.168.0.55 (PC-Adresse an eth1) umgestellt: Ausgabe in /var/log/messages nun:
[ ... ]
Feb 28 18:47:39 linux pppd[11734]: Connect: ppp0 <--> /dev/ttyUSB0 Feb 28 18:47:39 linux pppd[11734]: local IP address 192.168.0.44 Feb 28 18:47:39 linux pppd[11734]: remote IP address 192.168.0.55 Feb 28 18:47:40 linux SuSEfirewall2: Firewall rules successfully set in QUICKMODE for device(s) " ppp+" plus masquerading
IMHO das nächste Problem. "ppp+" bedeutet alle "pppX" und das ist hier so nicht erwünscht. Ich kenne mich mit der 'SuSEfirewall' nicht aus, aber es muss doch einstellbar sein, dass er "$FW_DEV_WORLD" und "$FW_DEV_INT" unterscheiden kann? Vermutlich muss der QUICKMODE abgeschaltet werden.(?) Vorausgesetzt 'synce' benutzt "ppp1" wie oben beschrieben, dann muss "ppp1" noch zu "FW_DEV_INT=" hinzugefügt werden. (Und falls du die synce-PPP-Verbindung -- wie vorgeschlagen -- in ein anderes Netz gelegt hast, dieses Netz noch zu "FW_MASQ_NETS=" hinzufügen.)
Feb 28 18:47:40 linux pppd[11734]: Script /etc/ppp/ip-up finished (pid 11756), status = 0x0 Feb 28 18:47:45 linux poll.tcpip: fetchmail: Query status=11 (DNS)
Und noch ein Problem: In "/etc/ppp/ip-up" werden alle "pppX" gleich behandelt. Ändere mal in "/etc/ppp/ip-up" die Zeile "ppp*)" in "ppp0)". Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Andreas, Am Montag, 28. Februar 2005 21:23 schrieb Andreas Koenecke:
* Montag, 28. Februar 2005 um 19:03 (+0100) schrieb Andreas Mantke:
Ich habe es gerade ausprobiert. Wenn ich das Internet zuerst starte, nutzt SynCE ppp1. Ansonsten blockiert es ppp0.
Ja, "wer zuerst kommt, mahlt zuerst"... Sofern der 'pppd' nicht allzu alt ist, kann man ihn mit einer Option anweisen, ein bestimmtes "pppX" zu benutzen. Dazu muss man aber erst einmal herausfinden, _wo_ man die Option setzen kann: AFAIR erzeugt 'synce-serial-config' ein "${PEER_FILE}". Schau doch mal unter "/etc/ppp/" und "/etc/ppp/peers/", ob du dort eine entsprechende Datei findest. In dieser Datei fügst du noch ein "unit 1" hinzu und 'synce' sollte zukünftig immer "ppp1" verwenden.
das entsprechende Peer-File heißt synce-device und verträgt den Eintrag unit 1. Damit wird jetzt brav ppp1 benutzt.
So nun habe ich das ganze noch einmal anders eingestellt: Remote-Adresse auf 192.168.0.55 (PC-Adresse an eth1) umgestellt: Ausgabe in /var/log/messages nun:
[ ... ]
Feb 28 18:47:39 linux pppd[11734]: Connect: ppp0 <--> /dev/ttyUSB0 Feb 28 18:47:39 linux pppd[11734]: local IP address 192.168.0.44 Feb 28 18:47:39 linux pppd[11734]: remote IP address 192.168.0.55 Feb 28 18:47:40 linux SuSEfirewall2: Firewall rules successfully set in QUICKMODE for device(s) " ppp+" plus masquerading
IMHO das nächste Problem. "ppp+" bedeutet alle "pppX" und das ist hier so nicht erwünscht. Ich kenne mich mit der 'SuSEfirewall' nicht aus, aber es muss doch einstellbar sein, dass er "$FW_DEV_WORLD" und "$FW_DEV_INT" unterscheiden kann? Vermutlich muss der QUICKMODE abgeschaltet werden.(?) Vorausgesetzt 'synce' benutzt "ppp1" wie oben beschrieben, dann muss "ppp1" noch zu "FW_DEV_INT=" hinzugefügt werden. (Und falls du die synce-PPP-Verbindung -- wie vorgeschlagen -- in ein anderes Netz gelegt hast, dieses Netz noch zu "FW_MASQ_NETS=" hinzufügen.)
Ich habe jetzt in die Variable für intern *INT ppp1 hinzugefügt und auch in der Masqierungsvariablen das neue Netz 192.168.0.0/24 hinzugefügt. Jetzt sieht es folgendermaßen in /var/log/messages aus: Feb 28 22:30:29 linux kernel: SuSE-FW-DROP-NEW-CONNECT IN=ppp1 OUT= MAC= SRC=192.168.1.3 DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=38936 DF PROTO=TCP SPT=1202 DPT=7438 WINDOW=32768 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402) Ich komme damit immer noch nicht auf den PocketPC drauf. Eine Kommandozeile finde ich auf dem übrigens leider nicht, so daß ich von dort nicht gucken kann.
Feb 28 18:47:40 linux pppd[11734]: Script /etc/ppp/ip-up finished (pid 11756), status = 0x0 Feb 28 18:47:45 linux poll.tcpip: fetchmail: Query status=11 (DNS)
Und noch ein Problem: In "/etc/ppp/ip-up" werden alle "pppX" gleich behandelt.
Ändere mal in "/etc/ppp/ip-up" die Zeile "ppp*)" in "ppp0)".
Die habe ich jetzt auch geändert. Bringt aber für die Firewall nichts. Ich komme weiterhin nicht auf den PocketPC. Schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
Hallo Andreas. * Montag, 28. Februar 2005 um 22:46 (+0100) schrieb Andreas Mantke:
Ich habe jetzt in die Variable für intern *INT ppp1 hinzugefügt und auch in der Masqierungsvariablen das neue Netz 192.168.0.0/24 hinzugefügt.
Jetzt sieht es folgendermaßen in /var/log/messages aus:
Feb 28 22:30:29 linux kernel: SuSE-FW-DROP-NEW-CONNECT IN=ppp1 OUT= MAC= SRC=192.168.1.3 DST=192.168.1.2 LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=38936 DF PROTO=TCP SPT=1202 DPT=7438 WINDOW=32768 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402)
(Erscheint beim Verbindungsaufbau noch die Meldung >>... QUICKMODE for device(s) " ppp+" plus masquerading<<?) Der PocketPC (192.168.1.3) versucht zum Router (192.168.1.2) eine Verbindung zu Port 7438 aufzubauen. Dieser Port ist aber nicht in "deiner" Liste der erlaubten Ports. Aber kannst du nicht einfach "FW_PROTECT_FROM_INTERNAL" auf "no" setzen, so dass intern alle Ports benutzt werden können. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Andreas, Am Montag, 28. Februar 2005 23:26 schrieb Andreas Koenecke:
Hallo Andreas.
(...)
(Erscheint beim Verbindungsaufbau noch die Meldung >>... QUICKMODE for device(s) " ppp+" plus masquerading<<?)
Nein. Soviel ich sehe nicht.
Der PocketPC (192.168.1.3) versucht zum Router (192.168.1.2) eine Verbindung zu Port 7438 aufzubauen. Dieser Port ist aber nicht in "deiner" Liste der erlaubten Ports. Aber kannst du nicht einfach "FW_PROTECT_FROM_INTERNAL" auf "no" setzen, so dass intern alle Ports benutzt werden können.
Das steht und stand auch vorher so ("no"). Ich habe jetzt auch noch einmal in die TCP_INT-Variable 7438 als weiteres Protokoll eingetragen. Ergebnis in /var/log/messages ist leider das gleiche. Gruß Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
Hallo Andreas. * Dienstag, 01. März 2005 um 17:20 (+0100) schrieb Andreas Mantke:
Am Montag, 28. Februar 2005 23:26 schrieb Andreas Koenecke:
(Erscheint beim Verbindungsaufbau noch die Meldung >>... QUICKMODE for device(s) " ppp+" plus masquerading<<?)
Nein. Soviel ich sehe nicht.
Ja, kann auch nicht... (s.u.)
Aber kannst du nicht einfach "FW_PROTECT_FROM_INTERNAL" auf "no" setzen, so dass intern alle Ports benutzt werden können.
Das steht und stand auch vorher so ("no"). Ich habe jetzt auch noch einmal in die TCP_INT-Variable 7438 als weiteres Protokoll eingetragen. Ergebnis in /var/log/messages ist leider das gleiche.
Ja, vermutlich mein Fehler: Durch die Veränderung in "/etc/ppp/ip-up" wird die (bzw. ein Teil der) SuSE-Firewall bei einer Verbindung mit "ppp1" nicht mehr gestartet und so werden vermutlich bestimmte Regeln nicht gesetzt. (Das Starten der Firewall in "ip-up" hat mir noch nie gefallen.) Hm, eine richtig saubere Lösung mit der SuSE-Firewall fällt mir nicht ein. Für einen ersten Versuch würde ich die Änderung in "/etc/ppp/ip-up" wieder rückgängig machen, also die Zeile "ppp0)" wieder durch "ppp*)" ersetzen. Die Fehlermeldung bezüglich "poll.tcpip" musst du dann (erst einmal) ignorieren. Probleme können auch auftreten, wenn du beide PPP-Verbindungen (synce und DSL) gleichzeitig nutzt, da dann die SuSE-Firewall zweimal gestartet wird, was auch "lustig" werden könnte... Aber probiere es ruhig erst einmal mit der Änderung in "ip-up", mal sehen, ob das überhaupt das Problem ist. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Andreas, Am Dienstag, 1. März 2005 19:46 schrieb Andreas Koenecke:
Hallo Andreas. (...)
Ja, vermutlich mein Fehler: Durch die Veränderung in "/etc/ppp/ip-up" wird die (bzw. ein Teil der) SuSE-Firewall bei einer Verbindung mit "ppp1" nicht mehr gestartet und so werden vermutlich bestimmte Regeln nicht gesetzt. (Das Starten der Firewall in "ip-up" hat mir noch nie gefallen.)
Ist wieder zurückgesetzt.
Hm, eine richtig saubere Lösung mit der SuSE-Firewall fällt mir nicht ein. Für einen ersten Versuch würde ich die Änderung in "/etc/ppp/ip-up" wieder rückgängig machen, also die Zeile "ppp0)" wieder durch "ppp*)" ersetzen. Die Fehlermeldung bezüglich "poll.tcpip" musst du dann (erst einmal) ignorieren. Probleme können auch auftreten, wenn du beide PPP-Verbindungen (synce und DSL) gleichzeitig nutzt, da dann die SuSE-Firewall zweimal gestartet wird, was auch "lustig" werden könnte...
Aber probiere es ruhig erst einmal mit der Änderung in "ip-up", mal sehen, ob das überhaupt das Problem ist.
So wie es aussieht, geht das nicht mit der SuSEFirewall2. Nachdem ich sie mit rcSuSEFirewall stop deaktiviert habe, kam ich auf den PocketPC ;-(( Einzige Alternative wäre scheinbar noch, wieder ein angepaßtes Script zu erstellen, mit dem eine Custom-Regel gesetzt wird. Ich verstehe nicht, daß SuSE das bisher nicht hinbekommen hat, obwohl sie mit Version 9.1 und 9.2 SynCE ausliefern. Schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
Hallo Andreas. * Dienstag, 01. März 2005 um 21:27 (+0100) schrieb Andreas Mantke:
So wie es aussieht, geht das nicht mit der SuSEFirewall2.
Ja, den Eindruck habe ich auch.
Nachdem ich sie mit rcSuSEFirewall stop deaktiviert habe, kam ich auf den PocketPC ;-(( Einzige Alternative wäre scheinbar noch, wieder ein angepaßtes Script zu erstellen, mit dem eine Custom-Regel gesetzt wird.
Ich sehe auch keine andere Möglichkeit, aber -- wie gesagt -- ich kenne mich mit der SuSEFirewall auch nicht aus...
Ich verstehe nicht, daß SuSE das bisher nicht hinbekommen hat, obwohl sie mit Version 9.1 und 9.2 SynCE ausliefern.
Das Problem müsste IMHO jeder haben, der "intern" ein PPP-Interface verwendet, z.B. ein VPN mit 'pptp'. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
participants (3)
-
Andreas Koenecke -
Andreas Mantke -
Jan Ritzerfeld