Изпечатай

[Gogo_SZ]

Или аз нещо не вдявам идеята или наистина има някакъв бъг. Ситуацията е следната:

Ползвам разни локални мрежи като всичките раздават адреси по DHCP. Проблема е, че при някои от тях MTU Size е зададен от доставчика (обикновенно Виваком, но не винаги) и "естествено" периодично този доставчик променя MTU Size (1500, 1492, 1456.....дори и 1292 ми снесоха веднъж от една от кабеларките).

В такъв момент Win машините захващат правилния MTU Size и продължават да работят, докато Linux-ите (Mandriva 2010.2, Mageia2, Ubuntu) не успяват и се налага да им се въвежда ръчно, въпреки, че в NetworkManager или NetworkCenter си има чавка за Автоматичен MTU Size (и к'во?! не работи)
Един и същи компютър го рестартирам под Вин - всичко работи, Линукс = нямя никой....

Имате ли идея как се оправя тоя проблем - да захваща АВТОМАТИЧНО верния MTU?

[petar258]

пробвай с тази команда, и си смени eth1 с интерфейса който при теб е външен

iptables -t mangle -A FORWARD -o eth1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

[10101]

Или аз нещо не вдявам идеята или наистина има някакъв бъг. Ситуацията е следната:

Ползвам разни локални мрежи като всичките раздават адреси по DHCP. Проблема е, че при някои от тях MTU Size е зададен от доставчика (обикновенно Виваком, но не винаги) и "естествено" периодично този доставчик променя MTU Size (1500, 1492, 1456.....дори и 1292 ми снесоха веднъж от една от кабеларките).

От какъв зор ще се сменя MTU-то при dhcp?! По - скоро се сменя при тунелите. Освен ако нямаш някакви комбинации.

С клампинг-а заобикаляш проблема, освен ако не държиш твърдо на auto mtu.

[Gogo_SZ]

Ами да де DHCP и тунел. Извън София навсякъде е само така:
Виваком - ADSL(тунел) модем раздава дресите на локалните по DHCP.
Всички ТВ - Кабелен модем(тунел) ти дава адреса по DHCP
Селска кабеларка- PPPoE(тунел) и твоят адрес пак по DHCP.....
И цялата тая пасмина като гламави чаткат по разни параметри кой както му падне и без да разбира нищо....

И като ти се налага по няколко пъти на ден да се закачаш на различни места и ти омръзва живота

[10101]

Може и да си прав.
Знам, че на тунела MTU-to е различно от 1500.
Като се вдигне тунел примерно PPPoE имаш MTU на тунела което е Х, но на физическия интерфайс MTU-то си остава 1500.

Пада тунела пада Х mtu-то. отново си имаш 1500 на картата.

Не съм срещал твоя проблем.
И/или  не го разбирам.

Виваком - ADSL(тунел) модем раздава дресите на локалните по DHCP. -- Виваком бяха /са на  pppoe до модема и трябва да има грижата bras-a им.

Селска кабеларка- PPPoE(тунел) и твоят адрес пак по DHCP..... тука ми се губи логиката да има dhcp ако предоставят услугата на pppoe. Te си знаят.

Всички ТВ - Кабелен модем(тунел) ти дава адреса по DHCP -- чудесно.. тук какво те бърка мту-то?

[geroy]

Принципно не е никакъв проблем MTU-то, а това че е станало практика (чудя се защо???) да се режат icmp пакетите защото може да те "хакнат"...

[10101]

Принципно не е никакъв проблем MTU-то, а това че е станало практика (чудя се защо???) да се режат icmp пакетите защото може да те "хакнат"...

Хем не е проблем хем е.
Ако не не се клампва MSS специално на pppoe, някой сайтове не се отварят- wrong pmtu и т.н. Това пак е от защото някой решил...

[Gogo_SZ]

Уважаеми съворумци! Нарочно пуснах тази тема в секцията за НАПРЕДНАЛИ - просто няма секция за Експерти!

Нямам ама никаква нужда от общи приказки или съвети кой доставчик е идиот, а още по-малко от теория на IP мрежите.... Ако целта Ви е да трупате бройка постове - пишете в общите приказки, и там се брой. А ако просто идеята е администратора да разкара темата в коша щото Ви е нанагорно да разберете въпроса = ами пораснете малко!!!!

Очаквам адекватни и съответстващи на ниво поне НАПРЕДНАЛ Unix/Linux специалист.

[Neoromantic]

Проблема според мен е в Path MTU Discovery. Най вероятно има машина по пътя, която е blackhole. В случая e блокнат ICMP.

"If any of the datagrams
   are too large to be forwarded without fragmentation by some router
   along the path, that router will discard them and return ICMP
   Destination Unreachable messages with a code meaning "fragmentation
   needed and DF set" [7]."

http://www.ietf.org/rfc/rfc1191.txt

http://www.miislita.com/internet-engineering/mtu-mss-tutorial.pdf

[go_fire]

Адаш извинявам се, че така грубо и непоканен се изказвам в темата ти, още повече съм обикновен начинаещ, и най-вече защото не разбрах, и половината на половината приказки дето си хортувате. Обаче за мен не е никаква изненада nm да не работи. Учудвам се в случаите, когато работи. Стария дебил си знае мантрата. Ползвай  ifplugd/netplugd или whereami/guessnet, за да ти е мирно селото. Туй го знам от стари дебили, както рекох.

[geroy]

Автоматичния (path) MTU discovery работи само когато по трасето до дадения хост са разрешени icmp пакетите. Админите масово режат icmp пакетите защото са опасни, така са им казвали обикновенно пускат само echo request и echo reply.

Метода на mtu discovery е следния, изпращат се пакети с DF (dont fragment) опция като всеки път се увеличава големината на изпратения пакет. В момента в който пакета стане > от MTU-то се връща ICMP съобщение - packet too big, fragmentation needed. Тук идва и проблема, ако някъде по трасето се филтрират icmp пакетите този отговор няма да се получи - следвателно automtic path mtu discovery няма как да работи.

Решението на този проблем при линукс го пише в man страницата на iptables (man iptables и търсиш стринга "--clamp-mss-to-pmtu")

[kifavi8024]

Извинете за offtopic-a, но колко пъти трябва да му напишете отговора, за да се сети и да го пробва най-малкото...

[10101]

Автоматичния (path) MTU discovery работи само когато по трасето до дадения хост са разрешени icmp пакетите. Админите масово режат icmp пакетите защото са опасни, така са им казвали обикновенно пускат само echo request и echo reply.

Метода на mtu discovery е следния, изпращат се пакети с DF (dont fragment) опция като всеки път се увеличава големината на изпратения пакет. В момента в който пакета стане > от MTU-то се връща ICMP съобщение - packet too big, fragmentation needed. Тук идва и проблема, ако някъде по трасето се филтрират icmp пакетите този отговор няма да се получи - следвателно automtic path mtu discovery няма как да работи.

Решението на този проблем при линукс го пише в man страницата на iptables (man iptables и търсиш стринга "--clamp-mss-to-pmtu")

Да, така написано е правилно.

Остава обаче следното GOGO_SZ казва по - горе че работи под windows. Питам си как става тогава при следното положение" "Тук идва и проблема, ако някъде по трасето се филтрират icmp пакетите този отговор няма да се получи - следвателно automtic path mtu discovery няма как да работи."

Освен MTU-то в случая има и "нещо друго счупено".

ПОздрави.

[tolostoi]

Амиии ... работи, преди време дълбах по-темата и единственото обяснение, което поне за мен имаше логика бе, че там айпи стека е различен ... не, че ме задоволи, но все е някакъв отговор
За да съм точен, тогава ставаше въпрос за пптп тунел, въпреки, че сървъра си беше на бсд, клиенти с линукс имаха проблем, с windows - не.

[Gogo_SZ]

Няколко дни ме нямаше - затова не отговарям...
По пътя няма НИЩО - директно свързана машина към рутера/модема на доставчика.
Същата машина под бозата ХР разпознава правилно MTU, а с Linux (Mandriva 2010.2 2011 и Ubuntu 10,4) си седи на 1500 и т'ва е - никаква автоматична реакция...

NM или други менажери не влияят - и с директно писане в конфиг файловете на машина без GUI - все тая.