проблемы в связке squid + TSO + windows 98

From

Alex Semenyaka (2:461/640.640)

To

Alexander Kolesnikoff

Date

2007-01-15T20:47:18Z

Area

RU.UNIX.BSD

Hello Alexander!

15 Jan 07 20:07, you wrote to me:

 >> >> А что с ней не так? Специально не изучал, но в случаях, когда такое
 >> >> наблюдалось - отправитель честно переставал передавать данные.
 >> AK>    Всё так, только вот если и дальше окно не открывать, сессия
 >> AK> стоит мертвая.
 >> Ну слава богу, так и должно быть. Я был бы неприятно удивлён, если бы
 >> я закрыл окно, а отправитель продолжал мне что-то передавать.
 >> AK> В отличии от фряхи, у виндюка таймауты гораздо меньше и сессию
 >> AK> она завершает раньше (в моём случае это был телнет). Кстати, не
 >> AK> помню
 >> AK> сейчас, отвалился ли сам вообще в этом тесте телнет на фряхе.
 >> Если фришка ничего не пыталась послать - то и не должен был
 >> отвалиться. А по каким признакам он это может сделать, пардон?
 AK>    Приложение, разумеется, должно оборвать сессию по таймауту. А ядру -
 AK> пофигу. Оно может и до "страшного суда" держать такую сессию. ;-)

Приложение? Оно тоже вовсе не должно ничего обрывать по таймауту. С какого
перепугу? Чтобы сделать persistent connection невозможными и жизнь испортить,
или зачем? :)

Кстати, если приложение сессию порвало, то ядро этого хоста должно эту сессию
прибить.

 >> Он должен отвалиться либо если keepalive не прошёл (а был включён ли?
 >> да и таймауты на нём немалые), не смогли в после многих попыток пакет
 >> послать или с той стороны RST пришёл. В противном случае (ничего не
 >> отсылаем и ждём) - он и будет висеть, потому что kern_telepat.c не
 >> написан :)
 AK>   И не надо ничего дописывать лишнего. Здесь нет неопределённости. ;-)

Ну да. Только непонятно, что тебе не нравится. Всё работает правильно, ровно
как должно :)

 >> >> Подождём от Дениса результата двух экспериментов, которые я
 >> >> описал...
 >> AK>   В связи с вновь открывшимися обстоятельствами (pf) всё ясно.
 >> AK> Только
 >> Я ещё не видел этих обстоятельств :) Не дошло, видимо, пока письмо.

Уже увидел. И чем synproxy кому мешает?

 >> AK> ... Понятно, что это сделано было не специально. Полагаю, надо эту
 >> AK> фичу выключить. Может и проблема с клиентами win98 решиться.
 >> Нет, может быть, конечно. Но это какое-то гадание на кофейной гуще...
 >> Из серии "у меня было ещё много интересных идей".
 AK>   И всё-таки ты сам же и соглашаешься, что "может быть". ;-)


К сожалению, я много чего видел в жизни. Но пробовать идеи из серии "а вдруг" я
привык только после того, как все другие пути решения абсолютно исчерпаны. А
тут ещё изучать и изучать проблему, и, скорее всего, можно разобраться, что
именно не срабатывает и почему. Что намного лучше, чем получить результат
шаманством - потому что от шаманства ни опыта никакого не получаешь, ни
воспроизводимости никакой не гарантируется...

 AK>  Ну да, это танцы с бубном. А какие ещё могут быть рекомендации
 AK> здесь? Человек же не зря сказал, что заставить всех клиентов
 AK> поменять опер - лучше застрелится. Значит на своей стороне надо
 AK> что-то делать. Остаюсь при своём мнении: этот sys-proxy - абсолютно
 AK> лишняя фича в данной ситуации.
 AK> (*)

Было предложено зайти на машину клиента удалённо - после чего там поставить
ethereal и снять сессию с той стороны. Возможно, там будет что-то яснее.
Кроме того, я бы ещё проверил, что с промежуточными MTU - есть ли проблема?
Если есть, то начиная с какого размера пакета она начинается?

После этого уже бы анализировал информацию и думал, что делать дальше.

Можно, конечно, превентивно отключить synproxy и посмотреть на результат. Но,
думаю, ничего не поменяется. Не мешает же synproxy, когда MTU большой.

Alex

--- IMHO в последней инстанции
 * Origin: ...можжевеловых... (2:461/640.640)
SEEN-BY: 50/12 400/814 450/159 1024 452/35 461/43 132 640 1024 469/999 4616/3
SEEN-BY: 4625/8 4641/444 5000/76 5000 5006/1 5007/1 5010/70 5011/13 5012/46
SEEN-BY: 5015/28 5019/26 5020/18 175 194 400 545 982 1057 1909 1922 2238 2395
SEEN-BY: 5020/2871 4441 5021/29 5025/3 5026/14 45 5027/12 5030/1080 1957
SEEN-BY: 5034/10 13 5035/38 5036/1 5045/7 5049/1 5051/12 15 5054/1 4 8 9 11 28
SEEN-BY: 5054/35 36 37 45 66 67 70 75 84 85 5059/9 5060/88 5061/15 5062/10
SEEN-BY: 5063/3 5064/7 5066/18 5075/5 5076/1 5077/70 5084/9 5085/13 5095/20
SEEN-BY: 5096/18 6001/10

PATH: 461/640 5020/400 545 5054/1 37