Каморка

Извините за глупый вопрос ниже, но RFC просто нет времени взглянуть, сейчас самому.

Проблема:
C циски (ip = 213.x.y.z) по rsh сливается "ip accounting checkpoint" на BSD (ip = 213.x.y.z).
(srv# rsh -l root 213.x.y.z show ip accounting checkpoint)

Некоторое время это работало.
Решил "учшить" старый ACL на циске, где для коллектора было (и ясен пень, всё работало):

permit tcp host 217.x.y.z host 213.x.y.z

"Улучшил", где для коллектора на циске разрешил только shell/cmd (tcp, port 514):

permit tcp host 217.x.y.z host 213.x.y.z eq 514

После "улучшения" перестало работать. В логах BSD denied пакеты на цискин TCP порт 1023:
Aug 4 13:23:46 213.x.y.z 4275: 17:21:49: %SEC-6-IPACCESSLOGP: list LAN-IN> denied tcp 217.x.y.z(1011) -> 213.x.y.z(1023), 1 packet

Добавляю этот идиотизм в пермит, в ACL на циске:

permit tcp host 217.x.y.z host 213.x.y.z eq 514
permit tcp host 217.x.y.z host 213.x.y.z eq 1023

Работает !!!
Немного рихтую:

permit tcp host 217.x.y.z host 213.x.y.z eq 514
permit tcp host 217.x.y.z host 213.x.y.z eq established

Снова РАБОТАЕТ!

Вот я и думаю.... Почему циске недостаточно одной пары сокетов, с одним серверным портом 514?
Это что, норма для rsh? Зачем 1023 порт на циске?

Спасибо. Извините за ленивость. Вернее сейчас времени не осталось разбираться самому с RFC rsh.

Разобрались. Вот ссылка, что дали.

Нестандартизированный протокол rsh требует вторичного канала TCP, инициируемого сервером для отображения сообщений об ошибках:

http://www.private.org.il/mini-tcpip.faq.html

Теперь ясно что для вторичного сокета на клиенте BSD не обойтись без того, что выше в ACL на циске было найдено опытным путём:

! для первичного соединения клиента с циской
!
permit tcp host 217.x.y.z host 213.x.y.z eq 514
!
! для вторичного соединения циски с клиентом
! это только ACK ответы клиента на PUSH от циски к клиенту для вторичного потока "... to be used as standard error..."
!
permit tcp host 217.x.y.z host 213.x.y.z eq established
!
Когда понятно, что происходит - жизнь веселее