PPP-Connect 1.8 zu asynchron?
Fidel-Sebastian Hunrichse-Lara
seit ich iFusion v1.0 habe, habe ich mich mal daran gemacht, nach den
Ursachen zu einer Unschönheit von ICONNECT zu forschen, die mich
bislang nicht weiter gestört hatte.
Gegeben ist: Eine Quadra840av mit MM 6.1.5 mit Sockets for MagiC v1.80
+ MacTCP-Connect (Auto STip v1.0 & MacSTip v0.9d), welche für Trarari-
Verhältnisse IMHO recht stabil & schnell vor sich hin nuckelt. ;-)
Die ICONF-Einstellungen sind AFAIR wie folgt händisch frisiert worden:
MTU=1492, TTL=119, DNS-Cache=256 KByte - es könnten aber auch noch
mehr sein, ist nämlich schon eine Weile her...
Die SMC 7004 Router-IP ist im DNS-IP-Feld fest vorgegeben, ebenso die
lokale IP-Adresse. Der DHCP-Server vergibt nämlich die IPs auf Ewig.
Mein Problem: Die DNS-Auflösung der pop-, smtp-, nntp- & ntp-IPs ist
leicht zerwürfelt, soll besagen: Die IPs stimmen idR schon, nur die
Zuordnung zu den besagten Diensten ist definitiv flasch - man könnte
direkt meinen, ICONNECT verteilt sie schlicht nach dem Zufallsprinzip!
Mein 1ster Ansatz war natürlich in ICONF.PRG die IPs fest vorzugeben,
was aber leider nur dazu führt, daß (laut CON_INFO) die Auflösung für
obige Dienste überhaupt nicht mehr funktioniert. :-/
Mein 2ter Ansatz war etwas subtiler, ich habe nämlicht schlicht die
HOST-Datei im ETC-Ordner (dessen Zuordnung unter ICONF.PRG ebenfalls
fest vorgegeben ist) editiert & dort die IPs + Hostname eingegeben.
Sie schaut also wie folgt aus:
--------------------- </hier abknabbern> --------------------
# The form of each entry is:
#<internet address> <official hostname> <aliases>
#
#Note: The entries cannot be preceded by a space
#
127.0.0.1 localhost loopback
38.113.3.21 pop.hotpop.com
38.113.3.80 smtp.hotpop.com
213.203.238.82 a.ntp.madduck.net
--------------------- </hier abknabbern> --------------------
Das ist aber offensichtlich zu subtil - ICONNECT ignoriert's schlicht!
Also habe etwas via Google Groups recherchiert, bin aber nicht recht
fündisch geworden... aber diese Passage brachte mich auf eine Spur:
--------------------- <hier abknabbern> ---------------------
- Die Service-Einträge werden bei der Einwahl jetzt asynchron
erfragt, d.h. es entstehen keine Wartezeiten mehr.
--------------------- </hier abknabbern> --------------------
© PPP_HIST.TXT
Die asynchrone Abfrageroutine könnte also (warum auch immer) für die
zerwürfelte Zuordnung verantwortlich sein. Hat sonst jemand eine
halbwegs intelligente Erklärung hierfür? Ich würde allerdings nur
höchst ungern downgraden - PPP-Connect 1.7 war AFAIR eigentlich nie
wirklich schnell & es reicht IMHO völlig, daß CrAB so elendig langsam
ist; ich stehe also konstruktiven Vorschlägen sehr offen gegenüber...
BTW: Bei meiner Recherche bin ich auf <200003211...@f.maus.de>
(M.C.A.Software) von Jens Hatlak gestoßen, daß brachte mich auf die
Idee, ob's wohl möglich sein könnte, daß man evtl via Scripter
ICONNECT mit den richtigen IPs füttern könnte? Allerdings
konnte ich besagten ISCRIPT.TXT nirgendwo finden...
M.f.G.
--
*"Wenn dies eine Diktatur wäre, dann würde dies wahnsinnig viel*
*einfacher sein, solange ich der Diktator wäre."* George W. Bush
<http://www.brunnenvergifter.de> #Recherchen zwischen Ratio & Paranoia#
Gerhard Stoll
FSHL> ICONNECT mit den richtigen IPs füttern könnte? Allerdings konnte
FSHL> ich besagten ISCRIPT.TXT nirgendwo finden...
Nö, das geht nicht. Du kannst nur Setups, welche mit ICONF.PRG erstellt wurden,
per GEMScript aufrufen.
Hier mal ein Beispiel:
-------------------------------cut-------------------------------
// Script zum automatischen Abholen von Mail bei zwei
// POP-Servern
// Version 0.1 20.05.2000
// Gerhard Stoll @ LU
proc main()
{
err=iconnect.set_service_setup("Setup 1"); // erstes Setup
// auswählen
while((err=iconnect.sync_resolve())==0) // Warte auf Verbindung.
wait(200);
emailer.mail_exchange(1,0,0); // nur persönliche Mails
// öffentliche Mails
err=iconnect.set_service_setup("Setup 2"); // zweitens Setup
while(!iconnect.sync_resolve()) // Warte auf Resolver...
wait(200);
emailer.mail_exchange(1,1,0); // Persönliche +
// öffentliche Mails
exitScripter();
}
-------------------------------cut-------------------------------
Es gibt noch die Befehle:
set_dial_setup("Name"). Damit wählt man im Offline-Betrieb ein Setup aus.
dial_in() starten des Verbindungsaufbau.
hang_up() beendet die bestehende Verbindung
sync_online()
Mit diesem Kommando kann man nach dial_in() auf den Verbindungsaufbau
warten.
Hast Du mal den alten RSDAEMON versucht?
Gerhard
Fidel-Sebastian Hunrichse-Lara
> Keine Ahnung was Du wirklich willst. ;-)
Das die DNS-Auflösung der pop-, smtp-, nntp- & ntp-Adressen korrekt
abläuft? Also das CON_INFO folgendes ausspuckt:
POP-Server: 38.113.3.21
SMTP-Server: 38.113.3.80
News-Server: 194.97.5.8 [1]
Time-Server: 213.203.238.82
Just spuckt er nämlich folgendes aus:
POP-Server: -unbekannt-
SMTP-Server: 194.97.5.8
News-Server: 213.203.238.82
Time-Server: 213.203.238.82
Immerhin 1 Treffer! Gebe ich dagegen die korrekten IPs direkt in ICONF
ein, dann erhalte ich grundsätzlich folgendes:
POP-Server: -unbekannt-
SMTP-Server: -unbekannt-
News-Server: -unbekannt-
Time-Server: -unbekannt-
Wie gesagt, dieses Fehlverhalten von ICONNECT ist mir früher deshalb
nie aufgefallen, weil ich bis Dezember 2006 in ICONF dort sowieso
nichts eingetragen hatte...
> > ICONNECT mit den richtigen IPs füttern könnte?
>
> Nö, das geht nicht.
Schade! Was gäbe's sonst für Möglichkeiten? Mac OS 8.1 bzw dessen
TCP/IP-Einstellungen ebenfalls mit eine HOST-Datei beglücken?
> Hast Du mal den alten RSDAEMON versucht?
Also nur den alten RSDAEMON? Nö, aber 1 Versuch kann ja nicht
schaden... <später>Mac OS: Ein schwerer Fehler ist unter MagiC
aufgetreten. (Exception #3, PC: $03C0F680) Danach die übliche -69
Meldung von MagiC & ICONNECT ward nicht mehr gesehen. Da MM sich ab da
extrem zäh anfühlte, habe ich's prophylaktisch rebootet.</später>
Weitere (evtl weniger bombig durchschlagende) Vorschläge? 8-)
M.f.G.
[1] Kann aber variiren, news.freenet.de benutzt LoadBalancer...
Gerhard Stoll
FSHL> Datei beglücken?
Keine Ahnung, kenn mich mit Mac OS nicht aus.
FSHL> Also nur den alten RSDAEMON?
Ja, nur den. Hat hier die größe 3971 Bytes. Der neu hat 5835.
Gerhard
Fidel-Sebastian Hunrichse-Lara
> > Mac OS 8.1 bzw dessen TCP/IP-Einstellungen ebenfalls mit eine
> > HOST-Datei beglücken?
>
> Keine Ahnung, kenn mich mit Mac OS nicht aus.
Habe ich getestet, brachte keine Änderung...
> Ja, nur den. Hat hier die größe 3971 Bytes. Der neu hat 5835.
Bestätigt! Teste ich später nochmals, allerdings reboote ich MM
diesmal - MM scheint's nicht zu mögen, wenn etwas an PPP ändert,
wenn's bereits in Betrieb war...
M.f.G.