× Hier geht es um die Modelle ST 510, ST 546, ST 585, ST 608, TG 585v7 und TG 787. Fragen zu moderneren Geräten von Thomson/Technicolor bzw. zu Pirelli/ADB bitte in der entsprechenden Sektion stellen.

normal Frage Thomson TG585 v7 > Firewall, NAT deaktivieren

Mehr
30 Dez 2009 21:34 - 30 Dez 2009 21:56 #12917 von kernei1
Hallo Zid,

hab jetzt ein 510er auftreiben können.

Infos dazu:
Speedtouch 510 (wahrscheinlich v4 da mit grauem Streifen)
FW: 4.2.7.16.0 > dürfte die neueste sein

Hab gleich mal einen hard reset durchgeführt

Bin das ganze Procedere noch mal durchgegangen:
Einwahl von WinXP PC funktioniert einwandfrei und Tunnel auch stabil

Bei der Endian FW wieder folgendes:
Dec 30 20:04:04 kernel: eth1 link up 
Dec 30 20:04:05 pppd[10208] pppd 2.4.4 started by root, uid 0 
Dec 30 20:04:05 pppd[10208] Using interface ppp0 
Dec 30 20:04:05 pppd[10208] Connect: ppp0 <--> /dev/pts/0 
Dec 30 20:04:05 pptp[10232]: pptp log[main:pptp.c:267] The synchronous pptp option is activated 
Dec 30 20:04:05 pptp[10249]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 1 'Start-Control-Connection-Request' 
Dec 30 20:04:05 pptp[10249]: pptp log[ctrlp_disp:pptp_ctrl.c:732] Received Start Control Connection Reply 
Dec 30 20:04:05 pptp[10249]: pptp log[ctrlp_disp:pptp_ctrl.c:766] Client connection established. 
Dec 30 20:04:06 pptp[10249]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 7 'Outgoing-Call-Request' 
Dec 30 20:04:06 pptp[10249]: pptp log[ctrlp_disp:pptp_ctrl.c:851] Received Outgoing Call Reply. 
Dec 30 20:04:06 pptp[10249]: pptp log[ctrlp_disp:pptp_ctrl.c:890] Outgoing call established (call ID 0, peer's call ID 0). 
Dec 30 20:04:07 pppd[10208] PAP authentication succeeded 
Dec 30 20:04:07 pppd[10208] local IP address 91.114.xxx.xx 
Dec 30 20:04:07 pppd[10208] remote IP address 62.47.95.239 
Dec 30 20:04:07 pppd[10208] primary DNS address 195.3.96.67 
Dec 30 20:04:07 pppd[10208] secondary DNS address 213.33.98.136 
Dec 30 20:05:06 pptp[10249]: pptp log[logecho:pptp_ctrl.c:670] Echo Request received. 
Dec 30 20:05:06 pptp[10249]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 6 'Echo-Reply' 
Dec 30 20:05:26 pptp[10249]: pptp log[ctrlp_disp:pptp_ctrl.c:781] Received Stop Control Connection Request. 
Dec 30 20:05:26 pptp[10249]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 4 'Stop-Control-Connection-Reply' 
Dec 30 20:05:26 pptp[10249]: pptp log[callmgr_main:pptp_callmgr.c:253] Closing connection 
Dec 30 20:05:26 pptp[10249]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 12 'Call-Clear-Request' 
Dec 30 20:05:26 pptp[10249]: pptp log[pptp_read_some:pptp_ctrl.c:537] read returned zero, peer has closed 
Dec 30 20:05:26 pptp[10249]: pptp log[pptp_read_some:pptp_ctrl.c:537] read returned zero, peer has closed 
Dec 30 20:05:26 pppd[10250] Modem hangup 
Dec 30 20:05:26 pppd[10250] Connect time 1.4 minutes. 
Dec 30 20:05:26 pppd[10250] Sent 1767606952 bytes, received 52 bytes. 
Dec 30 20:05:26 pppd[10250] Connection terminated. 
Dec 30 20:05:28 pptp[10249]: pptp log[pptp_read_some:pptp_ctrl.c:537] read returned zero, peer has closed 
Dec 30 20:05:30 pptp[10249]: pptp log[call_callback:pptp_callmgr.c:77] Closing connection 
Dec 30 20:05:31 pppd[10250] Exit. 

Dass dürfte der endgültige Beweis sein dass es an Endian liegt.

Noch eine Frage zum ST 510:
Wenn ich es als Router konfiguriere ist dann auch NAT, FW und anderes Zeugs aktiv bzw. wenn ja wie kann mans abschalten?


btw.:
computer-asyl.de/blog/?p=6
old.nabble.com/Tips-on-running-Endian-on-CF--td18609321.html

fg kernei1
Letzte Änderung: 30 Dez 2009 21:56 von kernei1.

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
31 Dez 2009 16:12 - 31 Dez 2009 16:14 #12962 von zid
hallo kernei,

ein paar sachen sind in deinen meldungen auffallend:
Dec 30 20:05:06 pptp[10249]: pptp log[logecho:pptp_ctrl.c:670] Echo Request received. 
Dec 30 20:05:06 pptp[10249]: pptp log[ctrlp_rep:pptp_ctrl.c:251] Sent control packet type is 6 'Echo-Reply' 
Dec 30 20:05:26 pptp[10249]: pptp log[ctrlp_disp:pptp_ctrl.c:781] Received Stop Control Connection Request.
es kommt ein pptp echo request (control type 5) vom server rein, der client schickt die pptp echo reply (control type 6) retour und 20s später bricht der server ab. damit drängt sich die frage auf, ob die reply auch tatsächlich rausgeht. du könntest das mit dem tg untersuchen, indem einen kontrollrechner mit wireshark an den ethport1 und die efw an ethport2 hängst. dann
- ethport2 -> ethport1 spiegeln
www.dieschmids.at/Fragen-zur-Konfiguration/611-DHCP-Problem-ST546v5-als-MU-mit-AP-Linksys-WAP54G/Page-3.html#626
- wireshark starten
- mit der efw einwählen und gesamten traffic aufzeichnen.
wenn du dich bei den traces nicht auskennst, dann die pcap hier (als zip bitte) posten oder mir schicken, zid at dieschmids dot at.

weiters interessant ist das:
Dec 30 20:05:26 pppd[10250] Sent 1767606952 bytes, received 52 bytes.
hmmm? ziemlich viel sent in 1,4 min...

>"...Wenn ich es als Router konfiguriere ist dann auch NAT, FW und anderes Zeugs aktiv bzw. wenn ja wie kann mans abschalten?..."
die firewall könntest du deaktivieren, nat jedoch nicht. und damit ist die efw arbeitslos, weil das nat-modul des st/tg alles rausfiltert.
www.dieschmids.at/Speedtouch-Firmware/10031-TG585-v7-Firewalleinstllung-standard-vs.-transp.html

danke für die links.

lg
zid
Letzte Änderung: 31 Dez 2009 16:14 von zid.

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
02 Jan 2010 16:16 #13003 von kernei1
Hallo zid,

hab jetzt die Verbindung mit WireShark mitgeschnitten.
Hab dir das EndianLog + das Capturefile via Mail geschickt.

Vielleicht kannst du das was rauslesen.


fg
Kernei1

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
02 Jan 2010 17:45 #13007 von zid
ich sags ja immer, ein zartes tracerl is durch nix zu ersetzen...:D

hallo kernei,

ich hatte recht mit meiner vermutung, die pptp echo-reply wird lt. logs anscheinend generiert, geht aber zumindest nicht raus -> tödlich:

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.



in den traces siehst du den ersten echo-req vom st/tg (paket 72), der nicht beantwortet wird. dann gibts noch 3 retransmissions dieses reqs (pak. 74-76), die ebenfalls nicht beantwortet werden. somit ist für das st/tg die sache klar -> der tunnel ist down, es geht ein stop-control-connection-request raus -> fin.
damit ist einmal das prob sonnenklar.

die ursachen leider net ganz so:
1. falsche logs, die reply wird gar nicht generiert, obwohls in den logs schwarz auf weiß steht -> bug
2. probs beim connection tracking -> bug.
3. eine fehlkonfiguration der firewall am wan-port schließ ich jetzt mal aus, weil sonst start-control-connection-req -> start-control-connection-rep -> outgoing-call-req -> outgoing-call-rep nicht klappen würden. die tcp-seq-/tcp-ack-numbers für pptp sind ok!

was kannst du tun:
du mußt jetzt nur noch pkt. 1 & 2 von oben differenzieren.
setze deshalb in den firewall rules einen undedingten accept für dst-port tcp/1723 und src-intf wan-port. achtung, der wan-port ist *nicht* "red", "red" ist der ppp-link.
wenns damit haut, dann ist es ein prob des conn trackings, hauts noch immer nicht, dann liegt das prob tiefer und du solltest einen bug melden mit:
- deinen logs
- der pcap, die du mir geschickt hast
- einen kommentar, der sich z.b. an meine bemerkungen von hier anlehnen könnte.

als übergangslösung könntest du das komische dhcp spoofing verwenden, das ich schon erwähnt hab, betonung liegt wirklich auf "übergangslösung".

lg
zid

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
03 Jan 2010 13:50 #13051 von kernei1
Hallo zid,

danke für deine Hilfe.

Leider hat sich deine Vermutung bestätigt:
Hier der Auszug aus dem Firewall Log:

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.



Hab jetzt unter Firewall > Portweiterleitung/ NAT > Eingehender gerouteter Datenverkehr mal folgende Regeln erstellt:

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.

Dieses Bild ist für Gäste verborgen.
Bitte anmelden oder registrieren um das Bild zu sehen.



Hab ich da was falsch gemacht?


Nach erneuter Einwahl wieder das gleiche - hab dann mal neu gestartet - und siehe da - keine Einträge mehr im Firewalllog - jedoch hat die Einwahl trotzdem nicht geklappt.


mhm - werd mal auf den Mailinglisten schaun und dann den Bug reporten.


Danke für deine Hilfe Zid!

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Mehr
04 Jan 2010 13:30 #13075 von zid
hallo kernei,

deine regel stimmt nicht. die pptp-pakete vom st/tg haben src-port tcp/1723, dst-port ist irgendein hi-port. nimm den port aus der regel.
wenns dann noch immer nicht haut, dann expliziten accept für rausgehenden traffic setzen:
src-ip: 10.0.0.140
dst-ip: 10.0.0.138
dst-port: tcp/1723
action: accept

lg
zid

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Moderatoren: andifrm1912enjoyherby68benderrwhomegeko
Ladezeit der Seite: 0.198 Sekunden
Powered by Kunena Forum