Autor: Michal Zalewski (lcamtuf_at_dione.ids.pl)
Data: Sat 12 Aug 2000 - 22:54:28 MET DST
On Sat, 12 Aug 2000, Michal Zalewski wrote:
> poprawnosci danych przeciskanych przez modem odpowiadaja protokoly
> realizowane na poziomie sprzetu - wszystkie MNP itp (nie chce zmyslac ani
> szukac numerka w specyfikacji).
A moze to nie MNP odpowiadala za sumy kontrolne i korekcja, nie wazne
[zabezpieczam sie na wypadek linczu, bo to nie bylo ze tak powiem sensem
mojej wypowiedzi] ;) W kazdym razie takie funkcje sa (powinny byc)
realizowane na poziomie sprzetu, o ile sie nie myle. Ewentualnie sa
dublowane potem na poziomie protokolu programowego, ktory chodzi po tym
(ppp). I wlaczenie kompresji ppp (bo od tego chyba sie dyskusja zaczela?;)
nie spowoduje zadnego problemu. Nie oznacza dokladania nowych chipow, nie
powinno wydluzyc czasu potrzebnego na resynchronizacje polaczenia po tym,
jak poleci kilka bledow, nie ma tez nic wspolnego z tym, co wyciagali
tutaj ludzie, czyli predkoscia modem / terminal <-> port szeregowy (bo
kompresja na poziomie ppp pozwala wcisnac wiecej danych w strumien
sprzetowy o przepustowosci 115200). Trywialne algorytmy kompresji (typu
deflate) nie powinny tez byc szczegolnym wyzwaniem dla oprogramowania po
stronie serwera obslugujacego ppp w centrali.
A tak wracajac do podstaw - czy ktos wlasciwie wie (w 100%) czy ppp
chodzace po HISach w koncu wspiera kompresje (a tylko czlowiek pytajacy
na poczatku nie wiedzial, jak ja wlaczyc), czy nie?:>
_______________________________________________________
Michal Zalewski [lcamtuf_at_tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:35:49 MET DST