Linux-Networking Digest #419, Volume #11 Sat, 5 Jun 99 14:13:30 EDT
Contents:
How I can use HSP-Modem with Linux? ("Ju")
ISDN Dial on demand and setting own MSN number (Henning Schroeder)
Re: Can't connect to my ISP yet, here's the pppd-output... (Monte Phillips)
PPP nightmare - HELP ("Socrates Charalambous")
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Andre Beck)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Gert Doering)
Viewing IpChains (Dzerdecki)
Re: Question:BUG?SPEC?/Directed Broadcast on kernel 2.0.36 (Malware)
Re: DialIN & Required hardware ("Tais M. Hansen")
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Gert Doering)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Gert Doering)
Re: ISDN Dial on demand and setting own MSN number (Andrzej Filip)
Re: IP redirecting, please help! (Wilson Lam)
Re: telnet as root (Malware)
Re: 3c905b problem with 2.0.36 (Monte Phillips)
----------------------------------------------------------------------------
From: "Ju" <[EMAIL PROTECTED]>
Subject: How I can use HSP-Modem with Linux?
Date: Sat, 5 Jun 1999 22:30:23 +0700
I just buy new Modem with V.90 support internal. But it's a HSP-Modem that
Modem-HOWTO told me linux 's not support this type of Modem coz linux's not
support HSP. Is there anyway to setup linux to work with this type of Modem?
Thanks
Ju"
------------------------------
From: [EMAIL PROTECTED] (Henning Schroeder)
Subject: ISDN Dial on demand and setting own MSN number
Date: Sat, 05 Jun 1999 16:18:29 GMT
Hi everybody,
i have a Linux ISDN server (kernel 2.0.36, SuSE Linux 6.0) running
that connects a few computers in my house to the internet using an
ISDN dial-up line with IP masquerading.
Is ist possible to set my own (MSN) number to a different value,
depending upon which computer the packet that caused the outdial came
from?
The reason for that is that i would like to have the the telephone
charges split, so that it is easy to see how much everybody has to
pay.
Does anybody have an idea how to accomplish that? I would appreciate
help very much.
Bye
Henning
------------------------------
From: [EMAIL PROTECTED] (Monte Phillips)
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.x
Subject: Re: Can't connect to my ISP yet, here's the pppd-output...
Date: Sat, 05 Jun 1999 15:14:40 GMT
Just get a copy of eznet try www.linuxberg.com software or some such
it is fast no tech stuff needed not even DNS just your name password
ISP name and phone number it does the rest. READ THE SMALL TXT FILE!
>In <7j92tv$p8h$[EMAIL PROTECTED]> "Melle" <[EMAIL PROTECTED]> writes:
>]Hi,
>]it's me again and the problem is still alive ... I can't connect to my ISP
>]running RH5.2.
------------------------------
From: "Socrates Charalambous" <[EMAIL PROTECTED]>
Subject: PPP nightmare - HELP
Date: Sat, 5 Jun 1999 18:25:14 +0300
I have serious problem with my ppp connection.
I connect to my ISP with minicom, I get out of minicom without reseting the
line and start pppd.
It stays connected for about 20 seconds and then the connection terminates.
This is what pppd logs in the /usr/log/debug
Jun 5 03:21:56 seaquest pppd[137]: sent [LCP ConfReq id=0x1]
Jun 5 03:22:15 seaquest last message repeated 6 times
Jun 5 03:25:26 seaquest pppd[153]: sent [LCP ConfReq id=0x1]
Jun 5 03:25:47 seaquest last message repeated 7 times
Jun 5 03:27:40 seaquest pppd[172]: sent [LCP ConfReq id=0x1]
Jun 5 03:28:01 seaquest last message repeated 7 times
Jun 5 03:29:45 seaquest pppd[180]: sent [LCP ConfReq id=0x1]
Jun 5 03:30:06 seaquest last message repeated 7 times
I use kernel 2.3.0 and pppd 2.3.4
Please HELP.
------------------------------
From: Andre Beck <[EMAIL PROTECTED]>
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
Date: 05 Jun 1999 18:09:07 +0200
[EMAIL PROTECTED] (Lars Marowsky-Bree) writes:
> On 03 Jun 1999 23:03:00 +0200, Detlef Bosau
> <[EMAIL PROTECTED]> wrote:
>
> > Ist jetzt ziemlich off topic. Aber ich meine schon seit langem,
> > dass die Alternative zu einem gerouteten, paketierten, Datenverkehr
> > in einem Datenverkehr besteht, in dem Peers, die verbindungsorientierten
> > Datenverkehr moechten (und das ist IMHO doch der haeufigere Fall)
> > direkt ueber eine virtuelle Verbindung miteinander kommunizieren.
>
> Das ist durchaus nicht offtopic.
>
> Aber ich habe mal eine Frage: Inwiefern unterscheidet sich der Aufbau eines
> solchen "PVC" von einem TCP/IP connect(), und muss das Netz _unter_ dem PVC
> nicht immernoch routen/switchen/wie auch immer?
Reden wir mal lieber �ber SVCs. PVCs sind vorkonfigurierte, immer
vorhandene virtual circuits, der Vergleich den Du heranziehst ist
eher auf SVCs zutreffend, wobei letztlich nat�rlich nur ein ent-
scheidender Unterschied zwischen ihnen besteht, die Frage ob es
eine W�hl- oder Festverbindung "simuliert".
> Kann auch sein, das ich Tomaten auf den Augen habe, aber das die Pakete dann
> einfach irgendwie an die Gegenstelle beamen ohne das da jemand forwarded
> erscheint mir recht schwierig ;-)
Der Witz ist das dies wesentlich weiter unten und mit Konzepten
passiert, die wesentlich simpler und daher performanter in Hard-
ware realisierbar sind als Routing auf L3, sei es IP oder sonst-
was. Wenn bei ATM ein SVC aufgebaut wird, dann signalisiert der
Caller seinem Switch das Gesuch. Der Switch "routet" das Gesuch
zum n�chsten Switch auf dem Weg zum Ziel. So geht das weiter,
bis zum Callee. Der Akzeptiert den SVC und schickt die Indication
zur�ck. Die Switchkette gibt die Indication jetzt sukzessive
bis zum Caller. Dabei wird zwischen jeweils Beteiligten ein f�r
die jeweilige PTP-Verbindung ausgefa�tes VPI/VCI-Tupel ausge-
handelt, die Switche m�ssen sich zus�tzlich merken, welches
VPI/VCI sie auf welches VPI/VCI switchen m�ssen, d.h.
1) Wenn Zellen mit diesem VPI/VCI reinkommen, welchen VPI/VCI
kriegen die dann reingedr�ckt
2) Auf welchem Port werden die nach VPI/VCI-Patch wieder raus
gefeuert
Sobald der SVC etabliert ist bedarf es also keines Routings mehr,
alles was gemacht wird ist "switching". Die feste Gr��e der
Zellen und der beschr�nkte Wertebereich der VPI/VCI "switching
tags" erlaubt, sowas komplett in Hardware abzuwickeln. Und
genau deswegen wird es extrem schnell. Das man die so gewonnene
Performance gut wieder verheizen kann, indem man dann LANE da
drauf macht steht auf einem anderen Blatt ;)
BTW, die Idee ist nicht neu, praktisch alle �lteren Telcolastigen
WAN-Protokolle (X.25, FR) verwenden �hnliche Mechaniken, da sie
in L1 oder L2 verbindungsorientiert sind. Am deutlichsten ist
es bei ISDN, das in L1 verbindungsorientiert ist - nachdem ein
B-Kanal in der PDH aufbebaut worden ist, ist auf dem Weg vom
Caller bis zu Callee zwischen allen Peers klar, in welchen Time-
slot der jeweiligen S0/E1/E3... die Bytes jeweils gestopft
werden m�ssen und bis zum Verbindungsabbau bleibt es dabei, das
hei�t man macht L1-Switching. Der Nachteil der PDH ist der hohe
Aufwand f�r die Mux/Demux-Technik und da� man sie immer kom-
plett braucht, auch wenn man nur einen B-Kanal aus einer E3
rausfriemeln w�llte. Mit ATM hat man versucht sich in der Mitte
zu treffen.
BTW^2, IPv6 hat einen switch tag vorgesehen, der im Prinzip f�r
genau den selben Zweck herhalten k�nnte. Man wartet nat�rlich
erstmal wann bzw. ob �berhaupt IPv6 massive Verbreitung erf�hrt,
bevor man an eine Verwendung geht.
> Ich w�rde annehmen, das die heutigen Modelle darauf auch ganz schlecht
> skalieren, wenn pl�tzlich nicht 10 PVCs zwischen den Backboneknoten, sondern
> einige Tausend/Millionen zwischen den Kommunikationspartnern aufgebaut werden.
> Da k�nnen wir dann nochmal bei den Telcos klauen. ;-)
Genau daf�r ist ATM aber ausgelegt und es kann sehr gut mit einer
riesigen Anzahl SVCs leben. Schlie�lich l��t es schon deren
Aufbau nur zu, wenn die Kapazit�tsreserven das hergeben. Oder halt
ABR gemacht wird.
--
"the big bang: the ultimate hero of low frequency;
the divine intergalactical bassdrum" -- Yello, "solar driftwood"
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) AB10-RIPE Xlink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
------------------------------
Crossposted-To: de.comm.internet.routing
From: [EMAIL PROTECTED] (Gert Doering)
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
Date: Sat, 5 Jun 1999 16:22:14 GMT
[EMAIL PROTECTED] (Detlef Bosau) writes:
>Aber zum NetBEUI. Das Problem ist nicht nur die Last. Das Problem ist
>einfach die Stabilitaet. Die Regeln, nach denen Masterbrowser werden,
[..]
>Ich wuerde normalerweise, wenn das vom IP Design her sinnvoll gehen
>wuerde, am liebsten jeden NT-Rechner in ein isoliertes IP-Segment stellen.
>Dann kann er wenigstens niemand anderem Schaden zufuegen.
>Aber solange das zu teuer ist, werde ich die NT-Katastrophenareas
>so klein wie moeglich halten.
Das ist das Problem: Windows und NT. Dein Problem sind nicht "zu grosse
Broadcast-Areas", Dein Problem ist "zu undurchsichtiges Windows" - daraus
aber zu schlussfolgern, dass alle groesseren Netze nicht mehr wartbar und
damit "schlecht" sind, ist gewagt.
Ich hab' hier einige nette Netze, wo primaer Unix-Rechner drinstehen,
gebridged (ueber eine 100Mbit-Ethernet-Strecke von COLT) ueber zwei
Gebaeude, und es laeuft einfach, dass es eine Freude ist. Obwohl zwei
oder drei NT-Server drin sind (aber die werden offensichtlich von
Leuten gewartet, die wissen, wie man die Dinger dazu bringt, das zu tun,
was sie sollen - ich weiss es nicht, und will es auch nicht wissen).
gert
--
Yield to temptation ... it may not pass your way again! -- Lazarus Long
//www.muc.de/~gert
Gert Doering - Munich, Germany [EMAIL PROTECTED]
fax: +49-89-3243328 [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Dzerdecki)
Subject: Viewing IpChains
Date: 5 Jun 1999 16:36:21 GMT
How do you view all your IpChains?
Thanks.
Drew
------------------------------
From: Malware <[EMAIL PROTECTED]>
Subject: Re: Question:BUG?SPEC?/Directed Broadcast on kernel 2.0.36
Date: Sat, 05 Jun 1999 18:35:01 +0200
Hi Mikito,
you wrote:
> FYI:Configuration of my environment is as follows.
> A: Linux-1
> {
> Kernel:
> 2.0.36 (comes with RedHat 5.2)
> NIC:
> 3Com 3C905 (for 1st Try)
> NIC: Intel EtherExpress Pro 100 (for 2nd Try)
>
> Host IP address:
> 10.1.1.10 (netmask 255.255.255.0)
> Address used for Direct Broadcast:
> 10.255.255.255
> Result:
> A packet was sent to default router but was not broadcasted to local
> net.
> }
10.255.255.255 is not the directed broadcast. But 10.1.1.255 is.
> C: Sun
> {
> OS:
> SunOS 5.6
> Host IP address:
> 10.1.1.11 (netmask 255.255.255.0)
> Address used for Direct Broadcast:
> 10.255.255.255
> Result:
> Broadcast packet(Dest-Mac-address=0xFFFFFFFFFFFF) was sent to local
> network.
> }
SunOS seems to ignore the netmask and calculates the directed broadcast
classfull. This sheme should be dead since years.
Malware
------------------------------
From: "Tais M. Hansen" <[EMAIL PROTECTED]>
Subject: Re: DialIN & Required hardware
Date: Sat, 05 Jun 1999 16:18:25 +0200
Reply-To: [EMAIL PROTECTED]
Thanks, but it only describes a dialin server using serialports and
modems... I need something bigger! :)
Matt Graham wrote:
> Look at this URL...
>
> http://www.swcp.com/~jgentry/pers.html
>
> Tais M. Hansen wrote in message <[EMAIL PROTECTED]>...
> >Does anyone have a detailed guide on making a dialin server including
> >descriptions on the hardware needed?
------------------------------
Crossposted-To: de.comm.internet.routing
From: [EMAIL PROTECTED] (Gert Doering)
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
Date: Sat, 5 Jun 1999 16:55:19 GMT
[EMAIL PROTECTED] (Andreas Klemm) writes:
>In nur Cisco Umgebungen und bei nicht zu gro�en Netzwerken ist
>Cisco's EIGRP sicherlich nicht �bel, in gr��eren Netzwerken
>soll IS-IS EIGRP gegen�ber Vorz�ge haben (H�rensagen).
Ich hoff' ja immer noch, dass mir mal jemand erklaert, warum IS-IS toll
ist. Ich hoere immer wieder, dass es das sei, aber mir fehlen total die
Entscheidungs-Argumente...
gert
--
[EMAIL PROTECTED]
18 24 61 B 17 17 4
------------------------------
Crossposted-To: de.comm.internet.routing
From: [EMAIL PROTECTED] (Gert Doering)
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
Date: Sat, 5 Jun 1999 16:54:05 GMT
[EMAIL PROTECTED] (Detlef Bosau) writes:
>> Letztlich ist das doch genauso "Routing". Ich "route" halt nicht
>> anhand von IP-Adressen, sondern anhand von FR- oder
>> ATM-Zieladressen, die vorher (beim VC-Verbindungsaufbau)
>> ausgehandelt wurden.
>Und zwar _vollstaendig_ ausgehandelt wurden. Ich rechne nicht paketweise
>die Routingtabelle durch.
Letztlich musst Du auch pro Zelle "routen" - anhand der vorher bestimmten
Ziel-Pfade, wenn man so will, aber es ist trotzdem ein Table-Lookup.
Wo ist der grundlegend qualitative Unterschied zu einem Route-Cache oder
Netflow-Caching?
>> Der Vorteil davon ist doch nur, dass die "Routingtabelle" schoen
>> klein ist, und die Geraete damit mit wenig Hardware-Aufwand schnell
>> darin suchen koennen.
>Und auch nicht rechnen muessen. Genauer: Ueberhaupt nicht rechnen muessen.
>Noch genauer: Der Prozessor schreibt die DLCI in das Adressregister
>und holt sich den Eintrag fuer die Folge-DLCI und den Outgoing Port.
>Und wenn Du, wie bei ATM, konstante Zellenlaenge hast, hast
>Du als Registerbreite die Zellenlaenge und schreibst genau
>eine Zelle in Dein Zellenregister, machst anschliessend einen
>Zugriff im Speicher, und schiebst das Ding wieder raus.
... solange die Anzahl der parallelen Verbindungen nicht zu gross ist.
Dann kollabiert das System, Du brauchst wieder eine Verwaltung ueber
Hashes, etc. - und bist da, wo wir jetzt auch sind. So einfach ist es
nicht, jede beliebige Weitverkehrs-Verbindung (vulgo TCP) auf eine
separate VC zu mappen.
[..]
>> Macht "Netflow-Switching" auch so, ist eine nette Idee, skaliert
>> leider ueberhaupt nicht, wenn man Netze wie das *Internet*
>> betrachtet, wo mehr als nur "ein paar 1000" Flows / SVCs parallel
>> ueber einen groesseren Knoten laufen.
>Gibt es dazu Info? Das kenne ich leider nicht!
s. anderes Posting - hier noch ein paar mehr Zahlen:
Protocol Total Flows Packets Bytes Packets Active(Sec)
Idle(Sec)
======== Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 124234 0.0 68 110 2.9 32.0 12.6
TCP-FTP 1012855 0.3 10 67 3.7 6.6 10.5
TCP-FTPD 1147511 0.4 58 618 23.2 10.3 7.8
TCP-WWW 161830714 56.5 10 422 596.2 4.4 7.5
das sind die Flows eines unserer Router - 56 *neue* Flows pro Sekunde.
Dafuer ist jeweils eine neue VC aufzubauen und wieder abzubauen...
Die Gesamtzahl der momentan aktiven Flows war 1374, insgesamt im
Flow-Cache waren 64162. Samstag Nachmittag bei strahlendem Sonnenschein.
>Aber das obige skaliert wunderbar.
Bis wieviele parallele VCs skaliert es denn? Bitte nenn' doch mal Zahlen.
(Netflow-Caching von Ciscos skaliert bei uns auch noch wunderbar, aber auf
den Core-Routern des WiN skaliert es nicht mehr, weil dort die Zahl der
Flows einfach noch viel groesser ist, und *paeng*).
>> - was macht ATM/FR, wenn eine Zelle verloren geht? Dumm schauen,
>> weil man dafuer eine Verbindungsssicherung *braucht*.
>Das ist ein wichtiger Einwand, und darueber wird man nachdenken
>muessen. Ich habe ja nicht gesagt, dass ich alles fertig habe.
>Eine Verbindungssicherung braucht man.
Eben.
>Der Layer 3 wuerde aber voll entfallen.
Letztlich nur, weil Du L2 und L3 einfach in einen *uniformen*
Transport-Layer zusammengefasst hast. Unter diesen Voraussetzungen
braeuchte tatsaechlich niemand die Trennung L2/L3, aber wenn man
Weitverkehr ueber verschiedene Medien machen will - was man muss,
sonst ist man nicht interoperabel - kommt man nicht darum herum.
Letztlich hast Du aber immer noch einen Layer 3 - dessen Adressen
werden zwar nur noch beim Verbindungsaufbau gebraucht, danach wird auf
"Layer 2" geswitched, wenn man so will, aber um globale Identifier (das
Kennzeichen von L3) und lokale Identifier (L2) kommst Du nicht herum.
> Und die Verbindungssicherung
>kann sinnvoller laufen als der klassische Layer 4. Die ist naemlich
>gar nicht mal so gut, wenn Du das in der Realitaet siehst.
Hmmm? Es funktioniert (TCP). Modulo RFC-nichtkonforme Implementationen
- aber daraus kann ich keine Schluesse auf das grundlegende Protokoll
ziehen - wenn ich einen kaputten ATM-Switch baue, ist deshalb nicht gleich
ATM "gar nicht mal so gut".
>Im uebrigen gibt es Protokolle wie IPX und aufliegende, in denen Verbindungs-
>_sicherung_ im Sinne von Fehlerpruefung nicht stattfindet. Wenn
>dort auf dem Medium ein Fehler auftritt, hast Du eine Katastrophe.
>(Und die habe ich mehrfach erlebt und ich kann nur jedem raten,
>von IPX/SPX over Frame Relay die Finger zu lassen, wie ich
>im Posting zu Lars geschrieben habe.)
Naja, was lernen wir daraus? Kaputt designte Protokolle fueren zu
Problemen. Fehler koennen in jedem Medium auftreten, auch Ethernet und
ARCnet.
[..]
>Der Layer 2 heisst im Amerikanischen: Logical Link Layer.
>Schau mal in die Deutsche Literatur, da heisst der _immer_
>Daten_sicherungs_schicht. Die ganze X.25 Welt geht davon
>aus, dass die Daten_integritaet_ auf Layer 2 sichergestellt wird,
>waehrend der Transport Layer nur noch die Aufteilung von
>Datenstroemen in Pakete macht.
Hmmm. Der Tanenbaum nennt das in der deutschen Uebersetzung auch
"Sicherungsschicht", der Text dazu erlaeutert das aber auch entsprechend -
so, wie es dort beschrieben ist, ist X.25 ein "Layer 2", die ueblicher-
weise als "L2" beschriebenen Medien allesamt nicht.
"... und die vom Empfaenger erzeugten Bestaetigungsrahmen (Acknowledgment
Frames) verarbeitet".
Hmmm. Was lernen wir daraus?
IP-Netzwerke haben nur entfernt was mit OSI zu tun.
>Und ich merke das zur Zeit sehr schmerzlich, dass eben hier
>die Datenintegritaet _nicht_ befriedigend ist und von TCP dann
>mit Aufwand und sehr ineffizient hergestellt wird.
Du gewinnst dadurch eine unglaubliche Flexibilitaet im Design Deines
Netzwerkes - stelle eine beliebige Strecke mit hinreichend kleiner
Bitfehlerrate zur Verfuegung und TCP/IP wird funktionieren. Das kannst
Du mit anderen Techniken nicht erreichen.
Ein ganz wichtiger Punkt, es so zu machen, wie TCP/IP das macht, ist der
Ausfall eines Knotenrechners. Das Endgeraet MUSS eine End-zu-End-
Datenintegritaet sicherstellen, um bei einem solchen Ausfall ueber
entsprechende Ersatzstrecken sicherzustellen, dass die Daten korrekt sind.
Durch eine reine L2-point-to-point-Fehlersicherung kannst Du das nicht
garantieren (next-hop-Router schickt ein ACK weg, crashed. Sender denkt
sich "schoen, Daten sind unterwegs", aber der endgueltige Empfaenger
wird das Paket nie erhalten).
Insofern wieder mein Argument: point-to-point-Fehlerkorrektur ist nett,
aber nicht ausreichend. Du brauchst *zwingend* eine End-zu-End-Korrektur,
vulgo TCP oder SPX.
>> - was macht man bei so einem Protokoll mit Daten, die zu gross
>> fuer eine einzelne Zelle sind - man muss "fragmentieren" und die
>> Datenpakete am Ende wieder zu einem Stream zusammensetzen.
>Das kommt nicht vor, weil der Client die Daten zellgerecht
>bereitstellt. Der SAR (Segmentation and Reassembly Sublayer)
>ist klar dem Endgeraet zugeordnet.
Aeh, und? Im einen Fall habe ich einen TCP-Stream, den ich in
IP verpacken muss, im anderen Fall einen Datenstrom, den ich in ATM-Zellen
verpacken muss.
Gewinn: nil.
[..]
>Bei TCP/IP moppelst Du hier uebrigens oft doppelt. Sofern Du
>nicht fuer jede Verbindung die Transport MTU bestimmst (was Du
>natuerlich brav immer tust ;-)) sondern die MTU gemaess Deiner
>LAN-Architektur nimmst, paketierst Du einmal nach LAN MTU,
>und die arme Sau von Router, die von Token Ring nach Ethernet
>muss, weiss auf einmal, was Packet Queues sind ;-)
Was ein klares Fehldesign von IPv4 ist. IPv6 fragmentiert nicht mehr.
[..]
>> Von der Notwendigkeit fuer "Verbindungen" mit minmalem Overhead,
>> z.B. fuer DNS-Abfragen, mal abgesehen. Eine neue VC fuer eine
>> DNS-Anfrage zu schalten, grenzt an Wahnsinn (und einfach mal alle
>> VCs, die man zum DNS-Server hat, offenzuhalten, auch).
>Wieso grenzt letzteres an Wahnsinn? Wenn stoert ein Management-SVC
>zum DNS?
>Niemanden.
Aeh. Es skaliert nicht.
Unsere Nameserver beantworten taeglich Requests von etwa 50.000 - 100.000
verschiedenen Clients, vermutlich sogar mehr.
Wenn diese Clients alle ihre "Management-SVC" offenlassen wuerden, wuerde
das ganz *immens* stoeren.
[..]
>> Fehlerkorrektur zwischen Knotenrechnern ist eine nette Idee, aber
>> relativ sinnlos - wenn ein Knotenrechner absemmelt, und der hat
>> gerade irgendwelche Daten im RAM, sind diese weg. Ergo designed
... irgendwie wiederhole ich mich.
>Das ist richtig. Es geht hier bei der Fehlerkorrektur darum,
>dass die Daten, die _ankommen_ auch _korrekt_ sein muessen.
Was zwar ein nettes Goodie ist, aber durch Checksummen in Levels weiter
oben voellig abgedeckt werden kann, ohne dass man irgendwas verschenkt
(modulo seltene Retransmits ueber laengere Strecken als nur die
fehlerhafte Strecke). Es ist nett, aber nicht zwingend. Wenn das
IP-Paket kaputt ist, wirft TCP es weg (und UDP auch, nachdem es keine
Systeme ohne UDP-Checksumming mehr gibt).
>> man den Protokollstapel so, dass ein "best effort"-Transport
>> voellig ausreicht, und faehrt gut damit.
>Ich fahre damit ueberhaupt nicht gut, genauer sogar saubeschissen.
>Best Effort Delivery ist zwar eine Bankrotterklaerung der 60er Jahre.
>Aber ich habe _taeglich_ Diskussionen mit Kunden, die eben
>nicht laenger bereit sind, Best Effort Delivery hinzunehmen.
Du mischt die Layer. Kunden sind Layer 8, 9 und 10 - und TCP sorgt auf
Layer 4 dafuer, dass "oben" eben - Leitungsverfuegbarkeit vorausgesetzt -
nicht mehr "Best Effort" ankommt. Dafuer ist es da.
gert
--
Yield to temptation ... it may not pass your way again! -- Lazarus Long
//www.muc.de/~gert
Gert Doering - Munich, Germany [EMAIL PROTECTED]
fax: +49-89-3243328 [EMAIL PROTECTED]
------------------------------
From: Andrzej Filip <[EMAIL PROTECTED]>
Subject: Re: ISDN Dial on demand and setting own MSN number
Date: Sat, 05 Jun 1999 19:08:12 +0200
Henning Schroeder wrote:
> i have a Linux ISDN server (kernel 2.0.36, SuSE Linux 6.0) running
> that connects a few computers in my house to the internet using an
> ISDN dial-up line with IP masquerading.
>
> Is ist possible to set my own (MSN) number to a different value,
> depending upon which computer the packet that caused the outdial came
> from?
>
> The reason for that is that i would like to have the the telephone
> charges split, so that it is easy to see how much everybody has to
> pay.
>
> Does anybody have an idea how to accomplish that? I would appreciate
> help very much.
Have you considered the following scenario:
user A wants to receive his/her email (1 minute call)
but during this time user B starts download of
full redhat 6.0 - (hours)
Based on your scheme user A is going to be charged for
user B generated traffic.
--
Andrzej (Andrew) A. Filip
http://www.bigfoot.com/~anfi
E-mail: [EMAIL PROTECTED]
I NO LONGER USE [EMAIL PROTECTED]
Posting history (all addresses):
http://www.dejanews.com/profile.xp?author=Andrzej%20Filip&ST=PS
------------------------------
Date: Sat, 05 Jun 1999 13:53:25 +0800
From: Wilson Lam <[EMAIL PROTECTED]>
Subject: Re: IP redirecting, please help!
Try Rinetd which I am using:http://www.boutell.com/rinetd/
urgrue wrote:
> short version:
> how can i redirect information from one interface to another, instead of having
> it automatically forwarded to the "normal" destination?
>
> longer version:
> i have a linux box (2.0.36) with a small network on one side (1.0.8.0 on eth0)
> and a larger one (1.0.0.0 on eth1) on the other. the linux box has an ethernet
> connection to the internet, and so does the larger network. people from 1.0.8.0
> need to be able to access 1.0.0.0 and, through it, the internet (NOT through my
> linux box).
> for now i just had a ipfwadm rule allowing all from 1.0.8.0 to 1.0.0.0, but how
> can i tell linux to forward _everything_ from 1.0.8.0 to 1.0.0.0's router,
> 1.0.0.162?
>
> please help!
> freddie
> [EMAIL PROTECTED]
------------------------------
From: Malware <[EMAIL PROTECTED]>
Subject: Re: telnet as root
Date: Sat, 05 Jun 1999 18:45:03 +0200
Hallo Marten,
you wrote:
> How can I make a telnet session to a linux computer in my little network
> as "root", so that I don't need a graphic card and a monitor in this
> computer ?
1. Telnet in as normal user and warp to root with "su".
or
2. Edit /etc/login.defs to allow root logins on ttyp0, ttyp1 and so on.
Malware
------------------------------
From: [EMAIL PROTECTED] (Monte Phillips)
Subject: Re: 3c905b problem with 2.0.36
Date: Sat, 05 Jun 1999 15:08:17 GMT
first get dos setup prog for the card and set it to IRQ 10 or 11, but
get it OFF of 15. Also disable PnP. then let Linux look for it.
g'Luk
On Fri, 04 Jun 1999 17:42:33 -0700, bill goodacre
<[EMAIL PROTECTED]> wrote:
>I need advice.
>
>I had a working RH 4.2 with a NE2000 ISA card configured at irq 10
>address 0x300. I then replaced it with a 3com 3c905b 100 base Tx PCI
>card. The system would not find the new card. I upgraded to RH 5.2 at
>this point. The new os won't find the card either. I have the most
>recent (just a few days old) Ethernet HOW-TO and have read it. I
>downloaded what I hoped would be the fix from Mr. Becker's NASA site. I
>compiled the program using the suggested compiler options. The message I
>get from insmod is "value for symbol io not found". This is the same
>message I get in the boot sequence. Coincidentally, I was installing
>Sybase on this machine (which went fine BTW) and it did a scan of my
>hardware and told me I had a 3c905b configured at IRQ 15 and 0x6500.
>I've tried passing parameters to the kernel at boot time using the LILO
>prompt, to wit "linux ether=" and so on, giving IRQ15 and 0x6500. no go.
>Now I've downloaded a two disk set from 3com's ftp site which are said
>to be DOS configuration utilities. I would like to boot from floppy into
>a DOS environment, then use the configuration utility to set the card at
>IRQ10 and 0x300. Then I hope the boot code will find the damn thing and
>give me a working network link. I now find I don't have any actual DOS
>system left, just Win 95. Well I don't see what else to do so tonight I
>will boot w95 from floppy then try to run the configuration utilities.
>If anyone wants to take pity on me I will be much obliged.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
