Совсем не могу расшарить интернет

[dr.Faust]

Ну если выбрать этот параметр на обоих машинах, то ноут подключается с адресом 10.42.43.1 а большой комп подключается и тут же рвет соединение и снова подключается, а когда подключается, то с адресом ... 10.42.43.1, но тут же рвет соединеение и тут же подключается и рвёт...

[Mam(O)n]

Не понял, как это так "также" настроил, что ноут рвёт... На клиенте тоже Ubuntu?

[dr.Faust]

Да - на клиетне тоже Ubuntu и очень давно.
А рвёт соединение шлюз, а не ноут...

[dr.Faust]

Углубленноё изучение вопроса дало следующие результаты:
Адрес на интерфейсе смотрящем в инет пингуется, а вот адрес шлюза провайдера (P-t-P) уже нет.
При этом судя по трассировке  пакеты уходят в правильном направлении, а судя по статистике, ещё и возвращаются на головную машину-шлюз.
Я в тупике...
Пользователь решил продолжить мысль 10 Мая 2010, 15:01:57:Пришлось поставить WS вот картина пинга на интерфейсах wlan0 для ноута (2) и для шлюза (1) - как видно пакеты идут вроде бы правильно и даже доходят до 192.168.8.1 (я поменял подсеть на , но такое ощущение, что не попадают в юзерспэйс, при этом в ЭТОЙ же сети, но когда шлюз win7 - всё нормально.
wlan0-2 (на ноутбуке)

(Нажмите, чтобы показать/скрыть)

wlan0-1 (на шлюзе)

(Нажмите, чтобы показать/скрыть)

ppp0-1

(Нажмите, чтобы показать/скрыть)

То есть что-то происходит с пакетами на шлюзе такое, что они потом не воспринимаются ноутом. iptable на ноуте девственно чист. NAT вроде бы не виноват..

[Mam(O)n]

Сразу незаметил:

Ну если выбрать этот параметр на обоих машинах

"Общий с другими компьютерами" нужно выбирать только на сервере! На клиентах надо выбирать "Автоматически", т.е. включать DHCP-клиента.
Пользователь решил продолжить мысль 11 Мая 2010, 11:29:04:

То есть что-то происходит с пакетами на шлюзе такое, что они потом не воспринимаются ноутом.

Что то мне кажется, что подглючивает воздушный линк... Шнурком проверить нет возможности?

[dr.Faust]

Сетевухи нет второй...
Но ведь на wlan0 ноута видно Wireshark'ом что пакеты на него идут...

[dr.Faust]

Вобщем пинганул я яндекс и проследил пакет по всем интерфейсам...
Результата:

pppoe - пакет нормальный
-->
wlan0 (шлюз) - пакет нормальный
-->
wlan0 (yноут) - пакет повреждён - в данных (Data) не совпадает длинна - 54 байта вместо 56 (как было на других интерфейсах). Естественно не бьётся и checksumma...

TCP пакеты тоже проходят нормально, кроме последнего интерфейса где они уже - Short segment. Segment/fragment does not contain a full TCP header (might be NMAP or someone else deliberately sending unusual packets)

С первого взгляда вроде MTU, но я менял его для wlan0 на 1532 и даже на 1572 - не помогло. MTU для ppp0 вобще не меняется где его не прописывай. Пытался делать как написано здесь: http://www.opennet.ru/base/net/pppoe_mtu.txt.html - тоже не помогло. Да и ICMP пакеты тоже повреждаются, а на них MTU вроде бы влиять не должно. Так же?

И чего делать?

[Mam(O)n]

MTU - Maximum Transmit Unit. Если пакет не влезает в это ограничение, то он и послан не будет. Да, и MTU действенен на все протоколы, MTU определяет размер Ethernet кадра, не считая MAC заголовки.

Тут ловить багу в wifi дровах надо, скорее всего на передающей стороне. Система 64 или 32 бита?
Пользователь решил продолжить мысль 14 Мая 2010, 10:36:05:

в данных (Data) не совпадает длинна - 54 байта вместо 56 (как было на других интерфейсах). Естественно не бьётся и checksumma...

Кроме длинны, содержимое нормальное, не битое? Т.е. просто режется 2 последних байта?

[dr.Faust]

Дело в том, что пакеты-то отсылаются и доходят, но поврежденными и поэтому выбрасываются ядром.
Про дрова я думал уже - если бы трабла была в них, то были повреждены бы ВСЕ пакеты, а повреждаются только пакеты пришедшие с внешки, с ppp0.
У них 2 отличая от ходящих внутри сети - они пришли по интерфейсу с другим MTU и с ними поработал NAT. Видимо тут и бага, так как через дрова wifi проходят ВСЕ пакеты.

Содержимое вроде не битое - только два последних байта отрезаны.

Вот архив - в нём 4 файла -  - единственный пинг из под убунты и винды (на шлюзе имеется ввиду) - пакеты и полные данные для каждого варианта.

[Mam(O)n]

пакеты и полные данные для каждого варианта.

Чёта wireshark не хочет открывать эти xml файлы... Лучше в формате libpcap сохраняй, они универсальны.
Пользователь решил продолжить мысль 14 Мая 2010, 11:03:21:

Видимо тут и бага, так как через дрова wifi проходят ВСЕ пакеты.

Попробую объяснить, как я думаю. Wireshark ведь нормально показывает на шлюзе. Значит NAT и т.п. отработали нормально. Далее идёт связка дрова - адаптер - эфир - адаптер - дрова. В этой связке дрова самое более вероятное проблемное место.

[dr.Faust]

Чёта wireshark не хочет открывать эти xml файлы... Лучше в формате libpcap сохраняй, они универсальны.

А я гедитом смотрю...

Попробую объяснить, как я думаю. Wireshark ведь нормально показывает на шлюзе. Значит NAT и т.п. отработали нормально. Далее идёт связка дрова - адаптер - эфир - адаптер - дрова. В этой связке дрова самое более вероятное проблемное место.

Хм. Логично. На шлюзе на влан0 пакеты уходят целыми - значит NAT ни при чём...
Но я не знаю как объяснить тогда  целостность остальных пакетов, если виновны дрова.
Значит MTU?

[Mam(O)n]

Значит MTU?

Точно нет. Выше писал. Да и к тому же MTU на другом уровне обрабатывается. Были баги в некоторых eth-дровах для sis на 64-битах, когда резались большие пакеты, по определённой длине, но у тебя вроде как все пакеты режутся по 2 крайних байта при любой длине.
Пользователь решил продолжить мысль 14 Мая 2010, 11:39:50:Вообще есть одна очень досадная особенность, при портировании на 64-х битную систему. Структуры выравниваются по-другому при копмиляции. И там, где на 32-битах годами работало нормально, на 64 битах могут возникать проблемы.

Так какая у тебя там и там система?

[dr.Faust]

32 битки обе. А вот Вин7 - 64 бита. Но есть ещё XP - она 32 битная и там тоже всё работало.

[Mam(O)n]

Тогда остается лопатить инет по модели адаптера.