ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Eugene Grosbein                      2:5006/1       01 Apr 2005  17:42:05
 To : Eugene B. Berdnikov
 Subject : Re: arp
 -------------------------------------------------------------------------------- 
 

 31 мар 2005, четверг, в 23:08 KRAST, Eugene B. Berdnikov написал(а):
 
  EG>> Hесомненно, только что потом делать с binary file 'kmem' matches? :-)
  EBB>  Посмотреть "grep -c -a". Вопрос возникнет, если оно окажется не 1.
  EBB>  Тогда, наверное, тащить ящик пива АК, чтобы научил пользоваться ядрёным
  EBB>  дебаггером, или хотя бы ласково пнул в нужном направлении. :)
  EBB>  Возможно, проще написать програмку на Си, чтобы искала по словам
  EBB>  (afair, адреса ipv4 выравниваются на long) и выдавала смещение.
 
 Hе смешно.
 
  EG>> 22:53:22.850462 0:c:f1:b8:ce:86 0:3:47:32:f0:9a 0806 60: arp reply
  EG>> x.x.64.3 is-at 0:c:f1:b8:ce:86
  EG>> 
  EG>> То есть, запросы как шли так и продолжают идти и кроме них других
 
  EBB>  Да, нелётная нынче погода для крокодилов, :) но линукс должен видеть
  EBB>  эти ответы. Это частичная проверка линуксового tcpdump'а, хотя пользы
  EBB>  от этой информации практически никакой.
 
 Линукс видит ответы. Более того, при добавлении алиаса на FreeBSD
 она (без всякого arping) сама один раз посылает такой arp-request
 для обновления кеша соседей и Linux его видит:
 
 tcpdump -e -n -i eth0 arp
 tcpdump: listening on eth0
 18:31:46.460580 0:c:f1:b8:ce:86 Broadcast arp 60: arp who-has 213.184.64.3
 tell 213.184.64.3
 18:31:46.460600 0:c:f1:b8:ce:86 0:3:47:32:f0:9a arp 60: arp reply
 213.184.64.3 is-at 0:c:f1:b8:ce:86
 18:31:46.867541 0:c:f1:b8:ce:86 0:3:47:32:f0:9a arp 60: arp reply
 213.184.64.3 is-at 0:c:f1:b8:ce:86
 18:31:48.861133 0:c:f1:b8:ce:86 0:3:47:32:f0:9a arp 60: arp reply
 213.184.64.3 is-at 0:c:f1:b8:ce:86
 
 После этого он видит arp reply на собственные запросы, которых он не видит.
 
  EG>> пакетов нет (тут был фильтр not host 192.168.0.2). Кстати, запросы
  EG>> идут не раз в секунду, как я сначала говорил, а раз в две секунды -
  EG>> внимания особого на тайминги не обращал.
  EBB>  Весьма интересно: интервал в две секунды - это тоже HЕ ядро линукса.
 
  EBB>  У линукса первые посылки идут с интервалом в секунду, регулируется,
  EBB>  по-моему, в neigh.<if>.retrans_time (в jiffies).
 
 net.ipv4.neigh.eth0.retrans_time = 100
 
  EBB> Кстати, нормальный-то
  EBB>  arp с этого линукса идёт со стандартными интервалами, без единиц в THA?
  EBB>  Вдруг там ядро невесть кем и как патченное. :)
 
 Удалил 192.168.0.2 из кеша на фре, чтобы она перезапросила:
 
 18:38:57.601211 0:c:f1:b8:ce:86 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
 192.168.0.2 tell 192.168.0.1
 18:38:57.601362 0:3:47:32:f0:9a 0:c:f1:b8:ce:86 0806 60: arp reply
 192.168.0.2 is-at 0:3:47:32:f0:9a
 18:38:59.137619 0:3:47:32:f0:9a ff:ff:ff:ff:ff:ff 0806 60: arp who-has
 213.184.64.3 (ff:ff:ff:ff:ff:ff) tell 213.184.64.3
 
  EBB>  Можно привести весь sysctl -a | grep eth0.
 
 net.ipv4.conf.eth0.arp_filter = 0
 net.ipv4.conf.eth0.tag = 0
 net.ipv4.conf.eth0.log_martians = 0
 net.ipv4.conf.eth0.bootp_relay = 0
 net.ipv4.conf.eth0.medium_id = 0
 net.ipv4.conf.eth0.proxy_arp = 0
 net.ipv4.conf.eth0.accept_source_route = 1
 net.ipv4.conf.eth0.send_redirects = 1
 net.ipv4.conf.eth0.rp_filter = 1
 net.ipv4.conf.eth0.shared_media = 1
 net.ipv4.conf.eth0.secure_redirects = 1
 net.ipv4.conf.eth0.accept_redirects = 1
 net.ipv4.conf.eth0.mc_forwarding = 0
 net.ipv4.conf.eth0.forwarding = 0
 net.ipv4.neigh.eth0.locktime = 100
 net.ipv4.neigh.eth0.proxy_delay = 80
 net.ipv4.neigh.eth0.anycast_delay = 100
 net.ipv4.neigh.eth0.proxy_qlen = 64
 net.ipv4.neigh.eth0.unres_qlen = 3
 net.ipv4.neigh.eth0.gc_stale_time = 60
 net.ipv4.neigh.eth0.delay_first_probe_time = 5
 net.ipv4.neigh.eth0.base_reachable_time = 30
 net.ipv4.neigh.eth0.retrans_time = 100
 net.ipv4.neigh.eth0.app_solicit = 0
 net.ipv4.neigh.eth0.ucast_solicit = 3
 net.ipv4.neigh.eth0.mcast_solicit = 3
 
  EBB>  Hа ядерный баг как-то не похоже, но для очистки совести можно ещё
  EBB>  поставить
  EBB>  везде log_martians=1 (по всем интерфейсам), и посмотреть, нет ли чего
  EBB>  подозрительного в логе на уровне kern.debug.
 
 log_martians какой эффект имеет?
 
  EBB>  В общем, если баг сидит не в ядре + userspace (=kmem), то в адаптере.
  EBB>  Я бы последовал совету А.Мельникова ребутнуть машину - кто знает, что
  EBB>  там
  EBB>  могло залипнуть в железке, если это действительно адаптер.
 
 Ребутнули, не помогло.
 
 Eugene
 --- slrn/0.9.8.0 (FreeBSD)
  * Origin: Svyaz Service JSC (2:5006/1@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор