Re: AP jako odbiornik.

"nom" idaabi$np8$1@pippin.nask.net.pl

>>> A wady? Wszystko co rozsyła jakikolwiek komputer w sieci LAN będzie
>>> szło także po wifi, a więc zabiera pasmo wifi pomiędzy Roterem a APekiem.

>> Może jaśniej i konkretniej?

> W sieciach LAN opartych na Ethernecie wykorzystuje się protokół CSMA/CD
> (ang. Carrier Sense Multiple Access / with Collision Detection). Niemniej
> jednak teraz są "inteligentne" przełączniki, ktore kierują pakiety tylko
> do tych komputerów, do których potrzeba (na podstawie adresu MAC). Jak
> przełącznik nie mają tego adresu MAC w tablicy adresów MAC i nie wie do
> którego portu jest podłaczony komputer, wtedy wysyłają pakiety do całej
> sieci LAN. Tak samo jak pakiety typu Broadcast (rozgłoszeniowe). Wszytsko
> było skrótem myślowym, oznaczało, wszystkie pakiety, ktorych adres MAC nie
> jest zdefiniowany w tablicy danego router z punktem AP, będą przesyłane do
> wszystkich portów danego routera w tym do portu wifi. :-)

I ,,przeźroczysty'' APek nie jest inteligentny podczas gdy ,,nieprzeźroczysty'' jest?

Rozumiem, że to, co taki ,,przeźroczysty'' APek dostanie z ,,zewnątrz'' roześle
po wszystkich swoich portach RJ (nie licząc portu ,,zewnętrznego'') oraz po WiFi,
podczas gdy ,,nieprzeźroczysty'' pośle to coś tylko pod wskazany adres RJ, do
którego podczepiona została konkretna karta (z konkretnym MAC) wcześniej
zdefiniowana jako adekwatna konkretnemu pseudo-IP? (pseudo-IP -- czyli
temu IP ,,wewnętrznej'' sieci, stojącemu za NATkiem)

Innymi słowy -- czy chodzi Ci o to, że ,,przeźroczysty'' APek spełnia rolę
prymitywnego HUBa podczas gdy ,,nieprzeźroczysty'' może być ,,inteligentnym''
swiczem/przełącznikiem gdyż zna adresy MAC podczepione do swoich portów RJ?

Jeśli tak -- APek to APek i jest przeznaczony przede wszystkim do WiFi a tam
inteligencji wielkiej chyba nie ma -- trzeba słać wszędzie. licząc na to, że
tylko wskazana karta to odbierze. :) (ograniczenie słania tylko na północny
wschód raczej odpada)

-=-

Wracając do wady NATków -- po drodze chyba może być tego (NATkowania) tak
dużo, że nie warto nad tym zastanawiać się. Próba zapanowania nad NATkwaniem
(nad translatowaniem ;) adresów z podsieciowych na inne podsieciowe) chyba musi
zakończyć się fiaskiem. Poza tym ponoć ;) od jakiegoś czasu ludzkość przechodzi
na dłuższe adresy IP, co ma doprowadzić do rezygnacji z NATKowania...

Dobrze myślę?

Ja dostaję dla swego APCka podsieciowe IP od kogoś (nie wiem, od kogo) nadaję
nowe IP APkowi (chyba na sztywno) a ten APek rozdaje kolejne adresy komputerom
podpiętym po WiFi -- tu z cała pewnością bez DHCP. :) (bo DHCP potrafi zawodzić;
akurat tu nie zawodzi, ale zawiodło w innym miejscu, więc tu nadałem IP sztywne)

Też nie tak -- bp temu APCkowi ja nadaję IP.

-==-

I tutaj jest ,,problem'' -- to nieprawda, że co APek to inna sieć z jej własnymi numerami.
I nie dlatego, że nie mogę konfigurować przekierowań portowych, ale dlatego, że widzę
z ,,ostatniego'' komputera wszystkie adresy urządzeń 0,1,2,3 -- gdzie 0 to ten ostatni
komputer, a 3 to nieznany mi APek, z którym widzi się mój APCek (2) do którego podpięty
jest APek (1) poprzez drut/RJ_45.

-=-

Moja konfiguracja jest skomplikowana a nie chcę teraz rozgryzać co i jak.
Jest skomplikowana nie dlatego, że tutaj coś źle chodziło, ale dlatego, że
chodziło źle coś w innym miejsca a tutaj chciałem ustrzec się tamtych błędów.

Ale raczej ukrytego NATkowania tu nie ma.

--
  ^  750                                      749      ^c 440      12 łyknąłem już Ventolin        438
  |  740 brak         .  14      18        23 739     F|l 430                 14      18      22   431
  |  730  Telfexo    12 .    1617   .20       729     E|i 420   070809 . .   .    16      20       416
 P|l 720          .                      22   719     V|t 410         10  12    15      19  21  23 410
 E|/ 710   07       .                         709      |r 400               13                     399
 F|m 700     08091011 *13  15     *19 *21     690     1|y 390           11          17             395