Re: FreeBSD & ISDN & dynamic ip's

Hellmuth Michaelis writes:
>> From the keyboard of Greg Lehey:
>
>>> Sicher braucht jede p2p-Verbindung zwei Adressen.
>>
>> Warum?
>
> Das haben Dir schon sehr viele Leute offensichtlich erfolglos in diversen
> Diskussionen zu diesem Thema erklaert.
>
> Bevor diese Diskussion nun zum wiederholten mal gefuehrt wird, bitte ich
> darum, sich vorher die diesbezueglichen Mailarchive anzuschauen, den
> (bzw. die) Stevens zu lesen und in die Sourcen zu gucken.

Dann solltest Du aber eine Seitennummer angeben.
Point-to-Point-Verbindungen hat's schon lange gegeben, bevor man
Netzwerke erfunden hat. Sie hatten zu den Zeiten nie Adressen. Das
Verlangen nach einer Adresse des anderen Endes ist aus reinem
Formalismus entstanden. Den eigentlichen Zweck (Erreichen der Adresse
am anderen Ende) erfüllen sie nicht, sondern bieten nur eine
Möglichkeit, Routing-Einträge zu definieren.

Experiment: Ändere mal nach Verbindungsaufbau die Adresse des anderen
Endes einer PPP-Verbindung willkürlich ab und ändere den Route-Eintrag
entsprechendermaßen. Das Ding läuft trotzdem. Hier ein Beispiel:
Meine PPP-Verbindung geht zwischen gregl1.lnk.telstra.net (von Telstra
zugeordnet, genauso bedeutungslos wie das andere Ende) und
Cont0.way3.Adelaide.telstra.net:

+ === root(at)freebie (/dev/ttyp6) ~ 140 -> ifconfig tun0
+ tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
+ inet 139.130.136.133 --> 139.130.136.129 netmask 0xffffffc0

So. Jetzt ändere ich die Adresse ab:

+ === root(at)freebie (/dev/ttyp6) ~ 141 -> ifconfig tun0 139.130.136.133 204.216.27.18
+ === root(at)freebie (/dev/ttyp6) ~ 142 -> ifconfig tun0
+ tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
+ inet 139.130.136.133 --> 204.216.27.18 netmask 0xffff0000

Das Routing steht noch bei der alten Adresse:

+ === root(at)freebie (/dev/ttyp6) ~ 143 -> netstat -rn
+ Routing tables
+
+ Internet:
+ Destination Gateway Flags Refs Use Netif Expire
+ default 139.130.136.129 UGSc 4 4 tun0
+ 127.0.0.1 127.0.0.1 UH 0 735 lo0
+ 192.109.197 link#2 UC 0 0
+ 192.109.197.134 link#2 UHLW 1 120
+ 192.109.197.137 0:a0:24:37:d:2b UHLW 1 13715 lo0
+ 192.109.197.159 link#2 UHLW 6 9264
+ 192.109.197.255 ff:ff:ff:ff:ff:ff UHLWb 1 1042 ep0
+ 204.216.27.18 139.130.136.133 UH 0 0 tun0

Aber das Ding läuft. Ich kann hub pingen:

+ === root(at)freebie (/dev/ttyp6) ~ 144 -> ping hub
+ PING hub.lemis.com (204.216.27.18): 56 data bytes
+ 64 bytes from 204.216.27.18: icmp_seq=0 ttl=244 time=419.819 ms
+ 64 bytes from 204.216.27.18: icmp_seq=1 ttl=244 time=490.287 ms
+ ^C
+ --- hub.lemis.com ping statistics ---
+ 2 packets transmitted, 2 packets received, 0% packet loss
+ round-trip min/avg/max/stddev = 419.819/455.053/490.287/35.234 ms

Ich kann Dich pingen:

+ === root(at)freebie (/dev/ttyp6) ~ 145 -> ping hcshh.hcs.de
+ PING hcshh.hcs.de (194.49.17.1): 56 data bytes
+ 64 bytes from 194.49.17.1: icmp_seq=0 ttl=233 time=751.258 ms
+ 64 bytes from 194.49.17.1: icmp_seq=1 ttl=233 time=700.318 ms
+ ^C
+ --- hcshh.hcs.de ping statistics ---
+ 3 packets transmitted, 2 packets received, 33% packet loss
+ round-trip min/avg/max/stddev = 700.318/725.788/751.258/25.470 ms

Ich kann sogar das andere Ende pingen:

+ === root(at)freebie (/dev/ttyp6) ~ 146 -> ping 139.130.136.129
+ PING 139.130.136.129 (139.130.136.129): 56 data bytes
+ 64 bytes from 139.130.136.129: icmp_seq=0 ttl=255 time=262.384 ms
+ ^C
+ --- 139.130.136.129 ping statistics ---
+ 1 packets transmitted, 1 packets received, 0% packet loss
+ round-trip min/avg/max/stddev = 262.384/262.384/262.384/0.000 ms
+ === root(at)freebie (/dev/ttyp6) ~ 147 ->

Verstehst Du jetzt, warum Ihr erfolglos wart? Ihr habt Unrecht. Ich
bin es Leid, die Sache in großem Detail zu erklären, aber es muß doch
einleuchten, wenn Du (Ihr) die einzelnen Mechanismen überleg(s)t, die
zum Weiterreichen eines Datagramms über eine PPP-Leitungen benötigt
werden: Die Gegenadresse wird nie benutzt.

Greg
Received on Fri 01 Aug 1997 - 11:29:34 CEST