Re: [suse-isdn] autom. wählen erst ab 2.Versuch
On Thu, Jul 12, 2001 at 07:11:33PM +0200, Thomas Klopf wrote:
Karsten Keil wrote:
On Thu, Jul 12, 2001 at 01:52:18PM +0200, Sascha Brechenmacher wrote:
Hallo, ich hab einen Suse 7.2 PC mit einer AVM B1 Karte. Den Wahlmodus hab ich auf automatisch gestellt.
...
Wie kann ich also einstellen dass es wirklich ein autom. wählen ist dass auch beim ersten mal klappt?
...
Abhilfen: 1. Einen festen nameserver verwenden und die automatische Nameserveranpassung ausschalten und den nameserver 2* eintragen.
2. ip-resend ist ein Paket auf der 7.2, aber leider noch nicht voll integriert, d.h. scripte usw. muessen von Hand angepasst werden. Meine Tests waren aber sehr vielversprechend, es hat immer funktioniert.
Dazu habe ich dann die Frage, wie zu verfahren ist, wenn man einen lokalen caching dns für ein lokales Netz auf dem Auswahlrechner laufen hat. Bleibt dann nur Abhilfe 2 übrig ? Ein doppelter Eintrag des lokalen dns in /etc/resolv.conf gemäß Abhilfe 1. funktioniert leider nicht. Auch ein doppelter Eintrag eines zu befragenden Nameservers in den "forwarders" in der /etc/named.conf funktioniert bei dns Anfragen für Adressen außerhalb des lokalen Netzes meistens (90%) nicht.
Wichtig ist hier in jedem Fall das ms-get-dns aus ist (nach der Anwahl kontrollieren ob die /etc/resolv.conf noch stimmt). Die beste Loesung ist hier ip-resend. Kurzanleitung (7.2): ip_resend installieren (serie network oder von Hand) rpm -ivh /cdrom/suse/n2/ip_resend.rpm in /etc/rc.config START_IP_RESEND="yes" eintragen Folgenden patch fuer /etc/ppp/ip-up einspielen. Es waer nicht schlecht, wenn es dazu etwas feedback gibt. -- Karsten Keil SuSE Labs ISDN development
Karsten Keil wrote:
On Thu, Jul 12, 2001 at 07:11:33PM +0200, Thomas Klopf wrote:
...
Dazu habe ich dann die Frage, wie zu verfahren ist, wenn man einen lokalen caching dns für ein lokales Netz auf dem Auswahlrechner laufen hat. Bleibt dann nur Abhilfe 2 übrig ? Ein doppelter Eintrag des lokalen dns in /etc/resolv.conf gemäß Abhilfe 1. funktioniert leider nicht. Auch ein doppelter Eintrag eines zu befragenden Nameservers in den "forwarders" in der /etc/named.conf funktioniert bei dns Anfragen für Adressen außerhalb des lokalen Netzes meistens (90%) nicht.
Wichtig ist hier in jedem Fall das ms-get-dns aus ist (nach der Anwahl kontrollieren ob die /etc/resolv.conf noch stimmt). Ist aus.
Die beste Loesung ist hier ip-resend. Ok.
Kurzanleitung (7.2): Mhm. Ich habe hier 7.1 mit Kernel. 2.2.19
ip_resend installieren (serie network oder von Hand) rpm -ivh /cdrom/suse/n2/ip_resend.rpm
Anfang Mai (also vor 7.2) hatte ich mir das Source RPM schon mal
gezogen.
Für eine erfolgreiche Übersetzung musste in ip_resend.c noch ein
"#include
in /etc/rc.config START_IP_RESEND="yes" eintragen
Ich gehe mal davon aus, dass das i4l von 7.1 und 7.2 unterschiedlich ist. Mit anderen Worten im 7.1er i4l wird START_IP_RESEND nicht ausgewertet bzw. ist nicht drin. Korrekt ? Deswegen habe ich in i4l nach dem Start der ipppd Prozesse ein "ip_resend -o $NETDEV -w 15 &" eingetragen. Das "-w 15" hat sich aus den ersten Tests im Mai/Juni ergeben.
Folgenden patch fuer /etc/ppp/ip-up einspielen.
Die beiden Aufrufe für ip_resend habe ich von Hand nachgetragen. Also: "/usr/sbin/ip_resend_wakeup -m $LOCALIP -o $INTERFACE" und "/usr/sbin/ip_resend -o $INTERFACE -w 15"
Es waer nicht schlecht, wenn es dazu etwas feedback gibt.
Es scheint im Gegensatz zu den ersten Tests besser zu funktionieren. Insbesondere klappen auch pings aus dem lokalen Netz ins Internet ohne Paketverluste bzw. doppelte Pakete. Im Nameserver-Log ist im Moment nur das folgende auffällig: datagram from [x.x.x.x].1026, fd 22, len 29 req: nlookup(www.suse.de) id 13604 type=1 class=1 req: found 'www.suse.de' as 'www.suse.de' (cname=0) req: found 'www.suse.de' as 'www.suse.de' (cname=0) evSetTimer(ctx 0x80e6e40, func 0x805d880, uap 0, due 995014551.000000000, inter 0.000000000) forw: forw -> [n.n.n.n].53 ds=5 nsid=58759 id=13604 1053ms retry 4sec datagram from [n.n.n.n].53, fd 5, len 218 send_msg -> [x.x.x.x].1026 (UDP 22) id=13604 datagram from [n.n.n.n].53, fd 5, len 218 DUP? dropped (id 58759) Hierbei ist x.x.x.x ein Rechner im lokalen Netz und n.n.n.n der vom caching only dns befragte Nameserver. Wieso kommt ein "DUP? dropped (id 58759)" ? Ein snort-Log auf dem ippp Interface zeigt nur 1 Antwortpaket vom befragten Nameserver. Könnte das 2., vom lokalen Nameserver angemeckerte, Paket von ip_resend stammen ? Bis dann, Thomas Klopf
On Fri, Jul 13, 2001 at 11:11:17AM +0200, Thomas Klopf wrote:
Karsten Keil wrote: Ok.
Kurzanleitung (7.2): Mhm. Ich habe hier 7.1 mit Kernel. 2.2.19
OK, da ist dann etwas mehr Handarbeit von noeten.
ip_resend installieren (serie network oder von Hand) rpm -ivh /cdrom/suse/n2/ip_resend.rpm
Anfang Mai (also vor 7.2) hatte ich mir das Source RPM schon mal gezogen. Für eine erfolgreiche Übersetzung musste in ip_resend.c noch ein "#include
" eingefügt werden.
Hmm das ist aber im ip_resend von mir drin, von wo hattest Du die sourcen ?
Ich habe das orginal Packet von Henner (den ich gut kenne) soweit angepasst
das
1. es compiliert (z.b:#include
Es hat sich aber zur Version der 7.2 CD nichts am Quelltext geändert. Das (bin)rpm der 7.2 habe ich mal so, wie angegeben, installiert.
in /etc/rc.config START_IP_RESEND="yes" eintragen
Ich gehe mal davon aus, dass das i4l von 7.1 und 7.2 unterschiedlich ist. Mit anderen Worten im 7.1er i4l wird START_IP_RESEND nicht ausgewertet bzw. ist nicht drin. Korrekt ? Ja. im i4l startscript ist folgendes dafuer drin (hinter # bind features ...):
# ip_resend hook test "$START_IP_RESEND" = "yes" && \ test -x $SBIN/ip_resend && \ $SBIN/ip_resend -o $NETDEV
Deswegen habe ich in i4l nach dem Start der ipppd Prozesse ein "ip_resend -o $NETDEV -w 15 &" eingetragen. Das "-w 15" hat sich aus den ersten Tests im Mai/Juni ergeben.
15 sek ist arg lang, aber OK.
Folgenden patch fuer /etc/ppp/ip-up einspielen.
Die beiden Aufrufe für ip_resend habe ich von Hand nachgetragen. Also: "/usr/sbin/ip_resend_wakeup -m $LOCALIP -o $INTERFACE" und "/usr/sbin/ip_resend -o $INTERFACE -w 15"
Richtig.
Es waer nicht schlecht, wenn es dazu etwas feedback gibt.
Es scheint im Gegensatz zu den ersten Tests besser zu funktionieren. Insbesondere klappen auch pings aus dem lokalen Netz ins Internet ohne Paketverluste bzw. doppelte Pakete.
Eventuell lag es daran, das Du die nicht "daemonisierende" Variante hattest.
Im Nameserver-Log ist im Moment nur das folgende auffällig:
datagram from [x.x.x.x].1026, fd 22, len 29 req: nlookup(www.suse.de) id 13604 type=1 class=1 req: found 'www.suse.de' as 'www.suse.de' (cname=0) req: found 'www.suse.de' as 'www.suse.de' (cname=0) evSetTimer(ctx 0x80e6e40, func 0x805d880, uap 0, due 995014551.000000000, inter 0.000000000) forw: forw -> [n.n.n.n].53 ds=5 nsid=58759 id=13604 1053ms retry 4sec datagram from [n.n.n.n].53, fd 5, len 218 send_msg -> [x.x.x.x].1026 (UDP 22) id=13604 datagram from [n.n.n.n].53, fd 5, len 218 DUP? dropped (id 58759)
Hierbei ist x.x.x.x ein Rechner im lokalen Netz und n.n.n.n der vom caching only dns befragte Nameserver. Wieso kommt ein "DUP? dropped (id 58759)" ? Ein snort-Log auf dem ippp Interface zeigt nur 1 Antwortpaket vom befragten Nameserver. Könnte das 2., vom lokalen Nameserver angemeckerte, Paket von ip_resend stammen ?
Ja, koennte von der Rueckuebersetzung des ersten Paketes stammen, das wird ueber das loopback device "injected". Hast Du dynamische IPs oder eine feste ? mal mit zusaetzlich -r 15 oder -R 0 probieren. Die man page ist ziemlich ausfuehrlich. -- Karsten Keil SuSE Labs ISDN development
Karsten Keil wrote: ...
Mhm. Ich habe hier 7.1 mit Kernel. 2.2.19
OK, da ist dann etwas mehr Handarbeit von noeten. Es hält sich in Grenzen.
ip_resend installieren (serie network oder von Hand) rpm -ivh /cdrom/suse/n2/ip_resend.rpm
Anfang Mai (also vor 7.2) hatte ich mir das Source RPM schon mal gezogen. Für eine erfolgreiche Übersetzung musste in ip_resend.c noch ein "#include
" eingefügt werden. Hmm das ist aber im ip_resend von mir drin, von wo hattest Du die sourcen ? Von: http://www.suse.de/~kkeil/i4ldevel Gezogen am 05.05.01
Ich habe das orginal Packet von Henner (den ich gut kenne) soweit angepasst das
1. es compiliert (z.b:#include
) 2. es zum daemon wird, Henners orginal hat z.b: ip_down blockiert, Die Aenderungen sind im ip_resend-0.3.diff und Henner wollte die auch irgendwann mal fest einbauen ... Manchmal ist man einfach zu blöd.... :-( Ich hatte wohl offensichtlich vergessen die Änderungen zu patchen.
...
Es waer nicht schlecht, wenn es dazu etwas feedback gibt.
Es scheint im Gegensatz zu den ersten Tests besser zu funktionieren. Insbesondere klappen auch pings aus dem lokalen Netz ins Internet ohne Paketverluste bzw. doppelte Pakete.
Eventuell lag es daran, das Du die nicht "daemonisierende" Variante hattest. Die hatte ich mit Sicherheit nicht, da Deine Änderungen nicht mit drin waren.
Im Nameserver-Log ist im Moment nur das folgende auffällig: ... Könnte das 2., vom lokalen Nameserver angemeckerte, Paket von ip_resend stammen ?
Ja, koennte von der Rueckuebersetzung des ersten Paketes stammen, das wird ueber das loopback device "injected". Hast Du dynamische IPs oder eine feste ? Dynamische IPs.
mal mit zusaetzlich -r 15 oder -R 0 probieren. Mit der Option" -R 0" in ip-up bzw. i4l funktioniert es jetzt auch ohne "DUP?" im Nameserver log. Das "-w15" habe ich wieder raus genommen. Mal schauen, ob die default Wartezeit von 10 s ausreicht.
Die man page ist ziemlich ausfuehrlich. Stimmt.
Vielen Dank für die Hilfe. Bis dann, Thomas Klopf
Hallo erstmal, hab gerade mitbekommen, daß mein named-Problem mit dem hier geschilderten zusammenhängt; dachte mir mal, daß die genannte Lösung für den caching-DNS auch für pppoed gilt, also hab' ich das mal skrupelloser Weise in meine 7.1er eingepatcht... (Hab' die Quellen von Karsten Keils HP && mit dem diff gepatcht.) Ja, funktioniert laut ip_resend -d 3 auch wunderbar, nur *effektiv* halt nicht... Vielleicht sieht ja jmd. meinen Denkfehler oder kennt einen Fallstrick... Ciao Robert PPPOED-START called (if=ppp0) ip_resend: index of ppp0 is 34 ip_resend -s ppp0: waiting for outgoing packet ip_resend forked as 2543 @IP-UP called (ip=217.80.25.139;if=ppp0) ip_resend_wakeup -c /var/ip_resend/ppp0: done #ip_resend: index of ppp0 is 34 ip_resend -s ppp0: waiting for outgoing packet received packet type 4, proto 8 ip_resend -s ppp0: outgoing IP packet from 217.0.31.241 to 145.253.2.75, proto 1: 45 00 00 54 00 00 40 00 3f 01 ae 6f d9 00 1f f1 91 fd 02 4b 08 00 2e 51 f1 f2 00 00 3b 50 ab 91 00 03 05 d4 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ip_resend -o ppp0: awaiting re-send notification from /var/ip_resend/ppp0 within 10.000 seconds. ip_resend: index of ppp0 is 34 ip_resend -o ppp0: received new address 217.80.25.139 old csum is 28590 ip-version 4 len 5 ip_resend -o ppp0: new csum is 34232 45 00 00 54 00 00 40 00 3b 01 b8 85 d9 50 19 8b 91 fd 02 4b 08 00 2e 51 f1 f2 00 00 3b 50 ab 91 00 03 05 d4 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ip_resend -o ppp0: re-sending with new source address 217.80.25.139 after 4.632s ip_resend -o ppp0: awaiting response packet within 10.000 seconds received packet type 0, proto 8 ip_resend -o ppp0: response from 145.253.2.75 to 217.80.25.139, proto 1 after 4.711s: 45 00 00 54 75 b8 40 00 f2 01 8b cc 91 fd 02 4b d9 50 19 8b 00 00 36 51 f1 f2 00 00 3b 50 ab 91 00 03 05 d4 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ip_resend: index of lo is 1 45 00 00 54 75 b8 40 00 f2 01 85 b6 91 fd 02 4b d9 00 1f f1 00 00 36 51 f1 f2 00 00 3b 50 ab 91 00 03 05 d4 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ip_resend -o ppp0: re-input translated response packet via lo IP-DOWN called (if=ppp0) ip_resend: index of ppp0 is 34 ip_resend -s ppp0: waiting for outgoing packet ip_resend forked as 2597
Ach ja, ich hab' ganz vergessen: ip_resend funktioniert lokal sehr gut (mit ping probiert, das erste Paket braucht zwar manchmal 40 Sek., aber es kommt zurück :-)); alle masqueraded connections funktionieren allerdings nicht. Ich vermute mal, das meine Masquerading-Einstellungen falsch / an der falschen Stelle sind (einfaches "ipchains -A forward --jump MASQ" beim booten). Bin für Hilfe sehr dankbar, Robert
Hallo Robert, Robert wrote:
...
alle masqueraded connections funktionieren allerdings nicht. Ich vermute mal, das meine Masquerading-Einstellungen falsch / an der falschen Stelle sind (einfaches "ipchains -A forward --jump MASQ" beim booten).
Ich habe hier bei mir in /etc/init.d/boot.local ein eigenes Script für das Masquerading eingetragen. Paketfilterung mache ich zur Zeit noch nicht. Das Masquerading funktioniert hier mit: ipchains -P forward DENY ipchains -A forward -s x.x.x.x/24 -j MASQ ipchains -M -S 0 0 20 x.x.x.x ist mit einer Class C IP-Adresse zu ersetzen.
Bin für Hilfe sehr dankbar, Ich hoffe es hilft.
Bis dann, Thomas
Hallo nochmal, Thomas Klopf wrote: [...]
Das Masquerading funktioniert hier mit:
ipchains -P forward DENY ipchains -A forward -s x.x.x.x/24 -j MASQ ipchains -M -S 0 0 20 [...] Thomas
das war's nicht, ich schätze, wenn meine -zugegebenermaßen *primitive*- rule völlig falsch ist, wäre gar kein Paket durchgekommen; ich habe aber Probleme mit den Paketen, die mit Hilfe von ip_resend wiederholt werden sollen. Vielen Dank trotzdem! Hmm, nächster Gedanke: ist es möglich, daß ip_resend mit masquerading überhaupt nicht geht (technikbedingt - ich weiß z.B. nicht, wie ein Paket vom lo interface jemals wieder ins lokale Netz gelangen soll...)??? Tschüß, Robert
participants (3)
-
Karsten Keil -
Robert -
Thomas Klopf