LINUX.ORG.RU
решено ФорумAdmin

[ppp][adsl][чудеса] Странности в сети

 , ,


0

1

Есть домашний комп с линуксом (homehost), которым я раздаю инет на еще один комп и иногда на нетбук. Интерфейс eth0 смотрит на dlink-2540U, в который воткнута вся домашняя локалка (еще один комп). Длинк настроен бриджом, ppp0 подымается через этот бридж на компе и смотрит в WAN белым IPом. Скорость соединения PPP - 1 мегабит.

Есть сервер (srv1) в интернете с белым IPом и 10мегабитами интернетов.

Поднимаю на домашнем компе веб-сервер, захожу на srv1 по ссаш, пишу wget скачать с домашнего компа файлик. Файлик начинает качаться, и спустя несколько секунд пинги от homehost до кого-либо (в том числе и в локалку) возрастают до 2 секунд.

Ниже привожу листинг как я пинговал d-link (включая и отключая закачку в соседнем терминале)

01:11:32 [nixtrian@arch64 ~]$ ping -i 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.597 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.426 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.398 ms #Примерно сейчас я начал закачку
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.407 ms 
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=240 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1532 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=2569 ms #Мое сердце не выдержало и закачку я прервал
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1268 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=0.381 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=0.424 ms

Если попробовать передать файлик на srv1 при помощи scp/sftp происходит то же самое. Что-то мне подсказывает, что так дело будет обстоять с любым tcp. При этом в остальном соединение ведет себя адекватно.

В чем тут могла порыться та злосчастная собака?

Как может загрузка интерфейса ppp0 (с пропускной способностью 1мбит) влиять на отправку/прием пакетов через eth0 (с пропускной способностью 100мбит)?

Да, если не прерывать закачку, то пинги возрастают до 4-6 секунд, после чего ppp рвется, и пинги нормализуются, до тех пор, пока не будет установлена новая ppp-сессия, а в ней новая tcp.

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

обнови свой dlink-2540U до последней прошивки.
2.Выруби все фичи на своем dlinke(то есть QoS и тд и тп).
3.Посмотри как там у тя mtu
4.Нагрузки системы посмотри(может там route лист кривой,хотя это маловероятно)

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

прошивку только что залил последнюю — не помогло

все фичи были вырублены

мту пробовал уменьшать до 1312 безрезультатно

роутлист выглядит адекватно

nixtrian
() автор топика

Поставь пингам приоритет повыше и всё.

AnDoR ★★★★★
()
Ответ на: комментарий от nixtrian

>мту пробовал уменьшать до 1312 безрезультатно

Увеличивать пробовал?

2.У тя ppp0 чем обоспечивается?
3.По хорошему надо дамп pcap сделать с этим эффектом и выложить.Чтобы понять что да как
4.Нагрузка на самом роутере(в консоли) какая?может там что то тормозит?
5.посмотри нагрузку на других узлах тоже

pinachet ★★★★★
()

Это Линукс так на компе работает с сетевым соединением по PPP. Модем тут ни при чём.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

вот мне тоже с самого начала казалось, что можем тут ни при чем, раз PPP на самом компе поднят.

Не совсем понял, то есть это нормально? так ВСЕ линуксы работают? (=

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

Замечена еще одна странность. Если передачу в инет производить с другого компа из локалки, то аномалии не наблюдаются. То есть транзитный трафик не вызывает проблем.

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

весь кусок в выложи.

Замечена еще одна странность. Если передачу в инет производить с другого компа из локалки, то аномалии не наблюдаются. То есть транзитный трафик не вызывает проблем.


У тя какой дистр?
И свой конфиг ppp выложи.
Возможно у те демон падает

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

дистр арч. демон не падает.

#/etc/ppp/options 
asyncmap 0
auth
crtscts
lock
hide-password
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx
#/etc/ppp/peers/provider 
 
 plugin rp-pppoe.so
 # rp_pppoe_ac 'your ac name'
 # rp_pppoe_service 'your service name'
  
  # network interface
  eth0
  # login name
  name "dsl_XXXXXX"
  usepeerdns
  persist
  # Uncomment this if you want to enable dial on demand
  demand
  idle 180
  defaultroute
  noauth
  mtu 1440
  debug
  kdebug 9
#/etc/ppp/pppoe.conf 
ETH=eth0
USER=dsl_XXXXXX
DEMAND=no
DNSTYPE=SERVER
PEERDNS=yes
DNS1=
DNS2=
DEFAULTROUTE=yes
CONNECT_TIMEOUT=30
CONNECT_POLL=2
ACNAME=
SERVICENAME=
PING="."
CF_BASE=`basename $CONFIG`
PIDFILE="/var/run/$CF_BASE-pppoe.pid"
SYNCHRONOUS=no
CLAMPMSS=1412
LCP_INTERVAL=20
LCP_FAILURE=3
PPPOE_TIMEOUT=80
FIREWALL=NONE
LINUX_PLUGIN=/etc/ppp/plugins/rp-pppoe.so
PPPOE_EXTRA=""
PPPD_EXTRA=""
nixtrian
() автор топика
Ответ на: комментарий от nixtrian

Хм..Я не сильный знаток внутриностей pppoe.
Ты попробуй загрузить live дистром типа knoppix , и оттуда настрой pppoe соединение .
Я думаю траблы с Atch ppp демоном.

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

сегодня попробовал грузить арч на кучке хлама и уже оттуда ппп-сессию инициировать, а затем инициировать передачу чего-либо в инет по ппп-интерфейсу. Проблема не наблюдалась.

тем самым исключены такие вероятные причины как

а) руки (конфиг тот же самый брался)

б) роутер

в) арч

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

значит у тебя траблы с сетевухой,или с другой железкой.
1.свой lspci выложи.
2.Попробуй другую сетевуху воткнуть

pinachet ★★★★★
()
Ответ на: комментарий от pinachet
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
nixtrian
() автор топика
Ответ на: комментарий от nixtrian

>после чего ppp рвется

Я думаю, что можно это выделить в отдельную проблему. То есть с вашего компа нельзя передать/получить большой файл по ppp? Смотрите dmesg, может там есть сообщения от сетёвки. Посмотрите статистику интерфейса --- кол-во битых пакетов.

mky ★★★★★
()
Ответ на: комментарий от mky

в dmesg от сетевухи никаких посланий нет.

при инициации проблемы никаких пакетов не побилось.

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

И да. сетевуха скорее всего глючная (на сто процентов можно будет убедиться, всунувши другую)

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

>И да. сетевуха скорее всего глючная (на сто процентов можно будет убедиться, всунувши другую)

Да походу -так.Но может она сильно перегреваеться.Ты под нагрузкой посмотри ее температуру.

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

Всунувши другую сетевуху (FastEthernet), я возрадовался решению проблемы. Выключил пока встроенную гигабитную сетевуху в биосе. а потом, когда будет куплен гигабитный свитч для дома, буду использовать внешнюю сетевуху для ппп (как сейчас), а встроенную воткну в свитч (=

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

еще мне почему-то кажется, что виноват не сам чип сетевухи, а сборщики материнской платы недопаяли что-то там.

nixtrian
() автор топика
Ответ на: комментарий от nixtrian

Ок поздравляю.Теперь ставь проблему решенной.
Насчет материнок - да такое редко бывает.

pinachet ★★★★★
()
23 января 2012 г.

За время использования сетевушки наткнулся еще на одну проблему: dhcpcd получает IP только со второго раза.

есть тема про модуль ядра http://www.linux.org.ru/forum/linux-hardware/5334405 похоже что все проблемы решаются установкой другого модуля.

nixtrian
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.