PDA

Bekijk de volledige versie : Проблемы с IMQ



loginrl103
04-12-2009, 06:45
Использую прошивку dd-wrt, но по вопросу на родном форуме dd-wrt мало кто смог помочь, а здесь специалистов больше )

Итак, предисловие (в прошивке олега поведение imq контролируется, в dd-wrt нет): imq не умеет обрабатывать маскадированный трафик в прероутинге, так как трафик он он ловит до нат => простым способом отловить весь трафик в прероутинге (куда попадёт и трафик для сервера) и маскадированный трафик - не получится.
Покопавшись с imq обнаружил, что поведение imq до/после на в прероутинге задаётся при сборке ядра. В dd-wrt imq собран именно со срабатыванием до нат, те в прероутинге imq не увидит маскадированный трафик.

Скачал исходники от прошивки, подправил ядро как надо, перекомпилил, получил два модуля - imq.o и ipt_imq.o.
Далее, удалил эти модули из памяти, затем на флешке создал каталог, туда скопировал все модули из /lib/modules/2.4.37,
переписал imq.o и ipt_imq.o новыми скомпиленными модулями,
перемонтировал mount -o bind /mnt/flash/module /lib/modules/

загрузил по новой эти модули (те загружаются уже новые модули) иии...ничего не изменилось - imq так и не стал отрабатывать после ната ((

Где я ошибся в расчётах?)

пс. сейчас выкручиваюсь через snat: весь маршрутизируемый трафик в зависимости от источника снатю на нужный диапозон портов, тогда в prerouting можно будет по диапазону исходяших портов определять кому идёт трафик, ну а дальше маркируем и шейпим...но всё это костыли, хочется нормальное решение через imq (

carmalius
14-02-2010, 21:12
По несколько раз в день самопроизвольно перезагружается Wl500g v2. Иногда с небольшими промежутками.
Причину не могу понять.
В syslog вижу вот такие настораживающие следы:




Feb 14 19:35:43 kernel: IMQ driver loaded.
Feb 14 19:35:43 kernel: Hooking IMQ after NAT on PREROUTING.
Feb 14 19:35:43 kernel: Hooking IMQ before NAT on POSTROUTING.
Feb 14 19:35:43 kernel: HTB init, kernel part version 3.17
Feb 14 19:35:43 kernel: HTB: quantum of class 10001 is big. Consider r2q change.
Feb 14 19:35:44 kernel: HTB: quantum of class 10021 is big. Consider r2q change.
Feb 14 19:35:44 kernel: HTB init, kernel part version 3.17
Feb 14 19:35:44 kernel: HTB: quantum of class 20001 is big. Consider r2q change.
Feb 14 19:35:44 kernel: HTB: quantum of class 20021 is big. Consider r2q change.




19:47:46 14-02-2010 (debug|kern|kernel) retrans_out leaked.
19:47:46 14-02-2010 (debug|kern|kernel) Leak r=1 3
19:47:54 14-02-2010 (debug|kern|kernel) retrans_out leaked.
19:47:54 14-02-2010 (debug|kern|kernel) Leak r=1 3

20:35:31 14-02-2010 (debug|kern|kernel) retrans_out leaked.
20:35:33 14-02-2010 (debug|kern|kernel) retrans_out leaked.
20:35:35 14-02-2010 (debug|kern|kernel) retrans_out leaked.
20:35:38 14-02-2010 (debug|kern|kernel) retrans_out leaked.
20:35:40 14-02-2010 (debug|kern|kernel) retrans_out leaked.
20:35:50 14-02-2010 (debug|kern|kernel) retrans_out leaked.
20:36:10 14-02-2010 (debug|kern|kernel) retrans_out leaked.

22:47:04 14-02-2010 (debug|kern|kernel) sending pkt_too_big (len[1500] pmtu[1460]) to self
22:47:11 14-02-2010 (debug|kern|kernel) sending pkt_too_big (len[1500] pmtu[1460]) to self
22:47:25 14-02-2010 (debug|kern|kernel) sending pkt_too_big (len[1500] pmtu[1460]) to self


Записи о retrans_out leaked часто являются последними перед порцией информации о новой загрузке.

Активно работает transmission 1.76.
Прошивка 1.9.2.7-d-r1087.
Запущен шейпер nshaper (dl и up каналы объединены в одно imq устройство).

lly
14-02-2010, 21:52
По несколько раз в день самопроизвольно перезагружается Wl500g v2. Иногда с небольшими промежутками.
Причину не могу понять.
первая часть лога нормальна - в форуме и google есть объяснения.

со второй хуже - подобного не должно быть.

Записи о retrans_out leaked часто являются последними перед порцией информации о новой загрузке.

Активно работает transmission 1.76.
Прошивка 1.9.2.7-d-r1087.
Запущен шейпер nshaper (dl и up каналы объединены в одно imq устройство).
Скорее всего, бага в драйвере IMQ. Но чтобы ёё найти, нужен посмертный дамп ядра, для чего без консоли не обойтись.

Плохо что ни у кого другого ошибка не воспроизводится...

carmalius
14-02-2010, 22:33
со второй хуже - подобного не должно быть.

Скорее всего, бага в драйвере IMQ. Но чтобы ёё найти, нужен посмертный дамп ядра, для чего без консоли не обойтись.
Что теперь только с этим делать? :)
Нужно специальное железо для отладки?

carmalius
15-02-2010, 09:56
Похоже, нашел, на какой конфигурации возникает проблема.

Как я отмечал уже в стартовом топике, я использую nshaper для шейпинга трафика. В силу особенностей провайдера (установлен общий лимит на скачивание и отдачу), мне приходится объединять входящий и исходящий трафик в одно IMQ устройство.

Для этого патчировал nshaper в соответствии с рекомендациями автора:
http://wl500g.info/showthread.php?p=172767#post172767 и далее.

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

Вернул стандартную версию nshaper - работает почти 12 часов без сбоев (в логе ни слова об утечке).

lly
15-02-2010, 10:07
Верно мыслишь, это известная бага в ядрах 2.4
http://mailman.ds9a.nl/pipermail/lartc/2002q4/005424.html

её исправили только в 2.6. Увы, бэкпорт еще и tcp стека из 2.6 мы не потянем - это огромная задача, плюс возможно она еще и нереальна из-за бинарного броадкомовского драйвера WiFi.

По поводу "sending pkt_too_big" народ советует выставить принудительно mtu на imqX интерфейсе.
http://www.freelists.org/post/slack-ru/sending-pkt-too-big-len1500,1

carmalius
15-02-2010, 11:49
А вот здесь SerGri говорит, что проблем у него не возникает:
http://wl500g.info/showpost.php?p=184188&postcount=437

Хотя также объединял канал в одно IMQ-устройство.

lly
15-02-2010, 12:14
А вот здесь SerGri говорит, что проблем у него не возникает:
http://wl500g.info/showpost.php?p=184188&postcount=437

Хотя также объединял канал в одно IMQ-устройство.
Я не знаю чёткого критерия возникновения ошибки. Если у вас получится её локализовать, можно будет что-нибудь еще поискать.
Но точно, что пререквизитом является объединение каналов.

SerGri
15-02-2010, 13:55
Я не знаю чёткого критерия возникновения ошибки. Если у вас получится её локализовать, можно будет что-нибудь еще поискать.
Но точно, что пререквизитом является объединение каналов.

Как вариант, у сarmalius скоростной канал в 100 Мбит/сек с доступом к инету в 11 Мбит/сек (не занаю что там PPTP или PPoE). Он и в шейпере задаёт:


WAN_DN_RATE=102400
WAN_UP_RATE=102400
WAN_ZONES="inet loc"
WAN_ZONES_DN_RATE="10137 92160"
WAN_ZONES_UP_RATE="10137 92160"

А предел маршрутизации с использованием шейпера -

Проверил еще раз шейпер под нагрузкой.
При отключенном скорость загрузки 4.6 Мбайт/сек.
При включенном стандартном шейпере скорость 2.9 Мбайт/сек.
При включенном шейпере с изменениями скорость 3.7 Мбайт/сек.
Т.е. скорость возрастает.
Загрузка процессора во всех случаях 92-94.
Так что может быть просто перегрев процессора и ребут.

сarmalius
У вас радиаторы охлаждения установлены на процессор и память?

carmalius
15-02-2010, 14:17
У вас радиаторы охлаждения установлены на процессор и память?

Радиаторы не установлены. Корпус просто теплый (у меня 500gp v2).
Есть ли штатные средства проследить за температурой?

Средний поток на скачку-отдачу относительно небольшой - порядка 500-600 кб/сек, а обычно и все 300. Выше 600 не поднимается - установлен лимит в transmission. В последней версии шейпера я установил лимит WAN вообще на 54 mbit. Кстати, прикладываю nshaper с модификациями, которые приводили к постоянным перезагрузкам.

lsd_wiz
15-02-2010, 22:28
На Железяке WL520gu под 1.9.2.7-d-r1000 поднят анлим с деленяем полосы проскания на iproute2( HTB) с использованием imq. Роутер явсяется клиентом по средствам PPPOE, провайдер белоруский ByFly.
Вот тут вылазит трабла, нет коннекта на некоторые адреса(ifolder.ru nix.ru
microsoft.com и тп). Причем пинг на некотрые проходит а трейс теряется. Для лечения проблеммы начал колбасить правила iptables, закончилось тем, что все политики были принудительно выставлены в ацепт. Нипомогло.
Но тут прикол. Званю в сапорт, они разводят руками, у них всё работает.
Поднимаю соеденени на модеме(без роутера ) всё педалит. Ставлю клиетном свой комп, модем бриджом, работает. Нашёл выход, решил попробывать через проксю зайти, при настроенном роутере, работает. Вопрос бана по ip отпал сразу. Так как ip динамический и адреса самые различные.
Может кто подскажет что?

PS. есчё ворос о поддержки в прошивке модуля esfq?.

SerGri
16-02-2010, 04:29
Про шейпинг трафика, приоритезацию, QoS очень много тем на этом форуме. Поищите (http://wl500g.info/search.php?searchid=4118853).

есчё ворос о поддержки в прошивке модуля esfq
Можно посмотреть отсюда (http://wl500g.info/showthread.php?p=162223#post162223)и далее по этой теме.
Начиная с прошивки 1.9.2.7-d-r655 модуль esfq включен в прошивку.

lsd_wiz
16-02-2010, 16:37
С этим как нить разберусь, но основная проблемма остаётся не решённой =(

SerGri
16-02-2010, 17:46
По основной проблеме:
1. Прокся стоит у провайдера или у Вас на роутере?
2. Что пишется в логах роутера при пропадании коннекта?
3. При пропадании коннекта сайты пингуются по IP?

lsd_wiz
16-02-2010, 18:08
Конект не проботает, его попосту нет.
Прокся рандомная (http://www.checker.freeproxy.ru/checker/last_checked_proxies.php) и от провайдера не зависит. В логах пусто.
Некотоые адреса пингуются. Некоторые нет.
Тестил сегодня еще раз напрямую с кампа, работает через роутер нет.
отключал всё по очереди.
до
$ipt -F
$ipt -X
$ipt -F -t mangle
$ipt -P FORWARD ACCEPT
$ipt -P OUTPUT ACCEPT
$ipt -P INPUT ACCEPT
Нифига!
к примеру

ping ifolder.ru
PING ifolder.ru (89.108.105.10): 56 data bytes
64 bytes from 89.108.105.10: seq=0 ttl=64 time=32.928 ms

[admin@~]traceroute ifolder.ru
traceroute to ifolder.ru (89.108.105.10), 30 hops max, 38 byte packets
1 pppoe-router13.mgts.by (93.84.80.50) 49.259 ms 18.527 ms 18.911 ms
2 mm-49-80-84-93.dynamic.pppoe.mgts.by (93.84.80.49) 19.867 ms 18.776 ms 33.362 ms
3 10.240.8.129 (10.240.8.129) 20.442 ms 23.918 ms 39.851 ms
4 93.84.122.41 (93.84.122.41) 57.500 ms 18.970 ms 19.351 ms
5 93.84.125.6 (93.84.125.6) 39.195 ms 25.683 ms 42.673 ms
6 193.232.249.76 (193.232.249.76) 28.676 ms 23.460 ms 19.315 ms
7 msk03.transtelecom.net (217.150.41.42) 31.236 ms 35.514 ms 44.750 ms
8 * * *
9 * *
[admin@~]$ ping velcom.by
PING velcom.by (212.98.171.59): 56 data bytes

--- velcom.by ping statistics ---
15 packets transmitted, 0 packets received, 100% packet loss
[admin@~]$ traceroute velcom.by
traceroute to velcom.by (212.98.171.59), 30 hops max, 38 byte packets
1 pppoe-router13.mgts.by (93.84.80.50) 18.108 ms 21.806 ms 18.490 ms
2 mm-49-80-84-93.dynamic.pppoe.mgts.by (93.84.80.49) 23.844 ms mm-49-80-84-93.dynamic.pppoe.mgts.by (93.84.80.49) 24.074 ms 19.589 ms
3 10.240.8.129 (10.240.8.129) 19.444 ms 23.930 ms 18.973 ms
4 93.84.122.41 (93.84.122.41) 24.610 ms 22.042 ms 21.862 ms
5 93.84.125.2 (93.84.125.2) 25.766 ms 23.995 ms 19.313 ms
6 192.168.255.11 (192.168.255.11) 19.678 ms 28.003 ms 23.584 ms
7 * * *
8 * *

SerGri
16-02-2010, 19:17
Прикольненько...
Где-то на форуме видел о проблеме 1.9.2.7-d-r1000 с PPPoE
с На Железяке WL520gu под 1.9.2.7-d-r1000 поднят анлим с деленяем полосы проскания на iproute2( HTB) с использованием imq. Роутер явсяется клиентом по средствам PPPOE, попробуйте обновить прошивку до 1.9.2.7-d-r1087 (http://code.google.com/p/wl500g/downloads/list).
Может быть, проблема в скрипте приоритезации трафика.
Читал в этой теме (http://wl500g.info/showthread.php?t=13609), что есть проблема с MTU при соединениях по PPtP (РРoE).
То есть через прямой коннект всё есть и практически всегда, через роутер часть сайтов отваливается, причем рандомно?
Можете запостить кусок SysLog-а роутера с момента загрузки до момента потери коннекта?
Вообще не похоже на проблему с IPTABLES.
Больше похоже на слишком длинный сегмент сети, или слабый БП роутера,
или еще как вариант, борьба провайдера с роутерами.
Попробуйте поставить между шнуркком от провайдера и роутером хаб.

lsd_wiz
16-02-2010, 20:54
На момент написания первого поста прошивку обнавил до последней. Как видно не помгло. Шейпер тоже не причём так как глючит без него. Он работает на марках iptables на виртуальных интерфейсах imq c mtu равным c интрефейсом pppoe:


[admin@~]$ ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:86.57.194.165 P-t-P:93.84.80.50 Mask:255.255.255.255
UP POINTOPOINT RUNNING MULTICAST MTU:1492 Metric:1
RX packets:2485421 errors:0 dropped:0 overruns:0 frame:0
TX packets:1964434 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1671404664 (1593.9 Mb) TX bytes:301511375 (287.5 Mb)

[admin@~]$ ifconfig imq0
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1492 Metric:1
RX packets:1924828 errors:0 dropped:0 overruns:0 frame:0
TX packets:1908427 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:301490875 (287.5 Mb) TX bytes:297318418 (283.5 Mb)

[admin@~]$ ifconfig imq1
imq1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1492 Metric:1
RX packets:2428729 errors:0 dropped:0 overruns:0 frame:0
TX packets:2379959 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:1667242981 (1590.0 Mb) TX bytes:1625468639 (1550.1 Mb)

я спрасывал таблицу mangle и все пакетышли в обход шейпер

По поводу длинного сегмета сети, не тот вариант от роутера до мадема пачкорд в полтора метра(на моей памяти линк устойчиво подымается на расстоянии до 250 метров, при условии кабель п296 а свичи на концах аккорпы, это не сказка реально работает причём стабильно с 2005г).

или еще как вариант, борьба провайдера с роутерами.
Модем ставлю в режим роутера, на нем же подымаю pppoe работает
Причём "сайты" рандомно не меняются как не работали так и не работают. =)

Попробуйте поставить между шнуркком от провайдера и роутером хаб.
а вот чем это поможет, честно признаться, понять не могу.

Пока идея одна буду шаманить с mtu.

lsd_wiz
16-02-2010, 21:06
вот бутлог


Jan 1 02:00:02 syslogd started: BusyBox v1.15.3
Jan 1 02:00:02 kernel: klogd started: BusyBox v1.15.3 (2010-01-24 20:40:42 MSK)
Jan 1 02:00:02 kernel: CPU revision is: 00029029
Jan 1 02:00:02 kernel: Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Jan 1 02:00:02 kernel: Primary data cache 16kB, 2-way, linesize 16 bytes.
Jan 1 02:00:02 kernel: Linux version 2.4.37.7 (root@localhost) (gcc version 3.4.6) #1 2010-01-24 20:44:23 MSK
Jan 1 02:00:02 kernel: Setting the PFC to its default value
Jan 1 02:00:02 kernel: Determined physical RAM map:
Jan 1 02:00:02 kernel: memory: 01000000 @ 00000000 (usable)
Jan 1 02:00:02 kernel: On node 0 totalpages: 4096
Jan 1 02:00:02 kernel: zone(0): 4096 pages.
Jan 1 02:00:02 kernel: zone(1): 0 pages.
Jan 1 02:00:02 kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jan 1 02:00:02 kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Jan 1 02:00:02 kernel: IP: routing cache hash table of 2048 buckets, 16Kbytes
Jan 1 02:00:02 kernel: TCP: Hash tables configured (established 1024 bind 2048)
Jan 1 02:00:02 kernel: Linux IP multicast router 0.06 plus PIM-SM
Jan 1 02:00:02 kernel: ip_conntrack version 2.1 (5953 buckets, 11906 max) - 328 bytes per conntrack
Jan 1 02:00:02 kernel: ip_conntrack_pptp version 1.9 loaded
Jan 1 02:00:02 kernel: ip_nat_pptp version 1.5 loaded
Jan 1 02:00:02 kernel: ip_tables: (C) 2000-2002 Netfilter core team
Jan 1 02:00:02 kernel: ipt_time loading
Jan 1 02:00:02 kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Jan 1 02:00:02 dnsmasq[67]: started, version 2.51 cachesize 512
Jan 1 02:00:02 dnsmasq[67]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-I18N DHCP no-scripts no-TFTP
Jan 1 02:00:02 dnsmasq[67]: read /etc/hosts - 2 addresses
Jan 1 02:00:02 kernel: usb.c: registered new driver usbdevfs
Jan 1 02:00:02 kernel: usb.c: registered new driver hub
Jan 1 02:00:02 kernel: usb-ohci.c: USB OHCI at membase 0xb8003000, IRQ 6
Jan 1 02:00:02 kernel: usb-ohci.c: usb-00:03.0, PCI device 14e4:471a
Jan 1 02:00:03 kernel: usb.c: new USB bus registered, assigned bus number 1
Jan 1 02:00:03 kernel: hub.c: USB hub found
Jan 1 02:00:03 kernel: hub.c: 2 ports detected
Jan 1 02:00:03 kernel: ehci_hcd 00:03.1: PCI device 14e4:471a
Jan 1 02:00:03 kernel: ehci_hcd 00:03.1: irq 6, pci mem b8003800
Jan 1 02:00:03 kernel: usb.c: new USB bus registered, assigned bus number 2
Jan 1 02:00:03 kernel: ehci_hcd 00:03.1: USB 0.0 enabled, EHCI 1.00, driver 10 Dec 2004/2.4
Jan 1 02:00:03 kernel: hub.c: USB hub found
Jan 1 02:00:03 kernel: hub.c: 2 ports detected
Jan 1 02:00:03 kernel: usb.c: registered new driver usblp
Jan 1 02:00:03 kernel: printer.c: v0.13: USB Printer Device Class driver
Jan 1 02:00:03 kernel: SCSI subsystem driver Revision: 1.00
Jan 1 02:00:03 kernel: Initializing USB Mass Storage driver...
Jan 1 02:00:03 kernel: usb.c: registered new driver usb-storage
Jan 1 02:00:03 kernel: USB Mass Storage support registered.
Jan 1 02:00:03 kernel: vlan1: Setting MAC address to 00 1b fc 60 e0 c6.
Jan 1 02:00:03 kernel: VLAN (vlan1): Underlying device (eth0) has same MAC, not checking promiscious mode.
Jan 1 02:00:04 kernel: hub.c: new USB device 00:03.1-1, assigned address 2
Jan 1 02:00:04 pppd[85]: Plugin rp-pppoe.so loaded.
Jan 1 02:00:04 pppd[85]: RP-PPPoE plugin version 3.10 compiled against pppd 2.4.5
Jan 1 02:00:04 pppd[86]: pppd 2.4.5 started by admin, uid 0
Jan 1 02:00:05 kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Jan 1 02:00:05 kernel: Vendor: JetFlash Model: Transcend 2GB Rev: 8.07
Jan 1 02:00:05 kernel: Type: Direct-Access ANSI SCSI revision: 02
Jan 1 02:00:05 kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
Jan 1 02:00:05 kernel: sda: Waiting for disc 0 to settle.
Jan 1 02:00:05 kernel: SCSI device sda: 3944446 512-byte hdwr sectors (2020 MB)
Jan 1 02:00:05 kernel: sda: Write Protect is off
Jan 1 02:00:05 kernel: Partition check:
Jan 1 02:00:05 kernel: /dev/scsi/host0/bus0/target0/lun0: p1 p2 <
Jan 1 02:00:05 dropbear[101]: Running in background
Jan 1 02:00:05 dropbear[102]: Child connection from ::ffff:192.168.2.1:47080
Jan 1 02:00:05 kernel: p5 >
Jan 1 02:00:08 dropbear[102]: password auth succeeded for 'admin' from ::ffff:192.168.2.1:47080
Jan 1 02:00:09 pppd[86]: PPP session is 5869 (0x16ed)
Jan 1 02:00:09 pppd[86]: Connected to 00:30:48:d2:7e:e9 via interface vlan1
Jan 1 02:00:09 pppd[86]: Using interface ppp0
Jan 1 02:00:09 pppd[86]: Connect: ppp0 <--> vlan1
Jan 1 02:00:10 pppd[86]: CHAP authentication succeeded
Jan 1 02:00:10 pppd[86]: CHAP authentication succeeded
Jan 1 02:00:10 pppd[86]: peer from calling number 00:30:48:D2:7E:E9 authorized
Jan 1 02:00:11 pppd[86]: local IP address 93.85.139.92
Jan 1 02:00:11 pppd[86]: remote IP address 93.84.80.50
Jan 1 02:00:11 pppd[86]: primary DNS address 82.209.240.241
Jan 1 02:00:11 pppd[86]: secondary DNS address 82.209.243.241
Jan 1 02:00:11 dnsmasq[67]: read /etc/hosts - 2 addresses
Jan 1 02:00:11 dnsmasq[67]: using nameserver 82.209.243.241#53
Jan 1 02:00:11 dnsmasq[67]: using nameserver 82.209.240.241#53
Jan 1 02:00:11 PPPoE: connected to ISP
Jan 1 02:00:15 kernel: Adding Swap: 128920k swap-space (priority -1)
Jan 1 02:00:15 e2fsck: /dev/discs/disc0/part1: recovering journal
Feb 16 21:47:31 pppd[86]: System time change detected.
Feb 16 21:47:43 e2fsck: /dev/discs/disc0/part1 has been mounted 30 times without being checked, check forced.
Feb 16 21:48:13 e2fsck: /dev/discs/disc0/part1: 12960/230400 files (0.9% non-contiguous), 107319/460776 blocks
Feb 16 21:48:13 e2fsck: /dev/discs/disc0/part1: clean, 12960/230400 files, 107319/460776 blocks
Feb 16 21:48:13 kernel: kjournald starting. Commit interval 5 seconds
Feb 16 21:48:13 kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
Feb 16 21:48:13 kernel: EXT3-fs: mounted filesystem with ordered data mode.
Feb 16 21:48:14 rc.unslung: start service /opt/etc/init.d/S08samba
Feb 16 21:48:17 rc.unslung: start service /opt/etc/init.d/S10cron
Feb 16 21:48:17 rc.unslung: start service /opt/etc/init.d/S40dbhub
Feb 16 21:48:17 /opt/sbin/cron[151]: (CRON) STARTUP (V5.0)
Feb 16 21:48:20 rc.unslung: start service /opt/etc/init.d/S50main
Feb 16 21:48:21 kernel: IMQ driver loaded.
Feb 16 21:48:21 kernel: Hooking IMQ before NAT on PREROUTING.
Feb 16 21:48:21 kernel: Hooking IMQ after NAT on POSTROUTING.
Feb 16 21:48:22 kernel: HTB init, kernel part version 3.17
Feb 16 21:48:22 kernel: HTB init, kernel part version 3.17

SerGri
16-02-2010, 21:16
На момент написания первого поста прошивку обнавил до последней. Как видно не помгло. Шейпер тоже не причём так как глючит без него. Он работает на марках iptables на виртуальных интерфейсах imq c mtu равным c интрефейсом pppoe:


[admin@~]$ ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:86.57.194.165 P-t-P:93.84.80.50 Mask:255.255.255.255
UP POINTOPOINT RUNNING MULTICAST MTU:1492 Metric:1
RX packets:2485421 errors:0 dropped:0 overruns:0 frame:0
TX packets:1964434 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1671404664 (1593.9 Mb) TX bytes:301511375 (287.5 Mb)

[admin@~]$ ifconfig imq0
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1492 Metric:1
RX packets:1924828 errors:0 dropped:0 overruns:0 frame:0
TX packets:1908427 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:301490875 (287.5 Mb) TX bytes:297318418 (283.5 Mb)

[admin@~]$ ifconfig imq1
imq1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1492 Metric:1
RX packets:2428729 errors:0 dropped:0 overruns:0 frame:0
TX packets:2379959 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:1667242981 (1590.0 Mb) TX bytes:1625468639 (1550.1 Mb)

я спрасывал таблицу mangle и все пакетышли в обход шейпер

Все красиво и логично.
А вот как на локальныx интерфейсах?- bro
Может, как раз при роутинге с br0 на vlan1 и далее на ppp0 что-то похабится.


По поводу длинного сегмета сети, не тот вариант от роутера до мадема пачкорд в полтора метра(на моей памяти линк устойчиво подымается на расстоянии до 250 метров, при условии кабель п296 а свичи на концах аккорпы, это не сказка реально работает причём стабильно с 2005г).

Согласен. Собака не тут порылась.


Модем ставлю в режим роутера, на нем же подымаю pppoe работает
Причём "сайты" рандомно не меняются как не работали так и не работают. =)
Вот то странно, что только на определённые сайты не пускает.


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

Это было к длинному сегменту сети.


Пока идея одна буду шаманить с mtu.
Еще как вариант, попробовать TCPDump-ом половить пакеты при прямом подключении (без роутера) и через роутер. Посмотреть разницу.

UPD: А какой адрес у роутера в локальной сетке?
Просто, судя по
Jan 1 02:00:05 dropbear[102]: Child connection from ::ffff:192.168.2.1:47080
, 192.168.2.1 - это адрес в Вашей внутренней сетке, Вашей машинки. Тогда какой внутренний IP у роутера?

lsd_wiz
16-02-2010, 21:49
Локальные интерфейсы


[admin@~]$ ifconfig br0
br0 Link encap:Ethernet HWaddr 00:1B:FC:60:E0:C6
inet addr:192.168.3.32 Bcast:192.168.3.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:259690 errors:0 dropped:0 overruns:0 frame:0
TX packets:274688 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:16015573 (15.2 Mb) TX bytes:305710766 (291.5 Mb)

[admin@~]$ ifconfig vlan1
vlan1 Link encap:Ethernet HWaddr 00:1B:FC:60:E0:C6
inet addr:192.168.33.1 Bcast:192.168.33.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:274287 errors:0 dropped:0 overruns:0 frame:0
TX packets:249230 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:305437213 (291.2 Mb) TX bytes:21396687 (20.4 Mb)

SerGri
16-02-2010, 22:08
Хм... Странно....
Поставьте адрес роутера 192.168.50.254(1)/255.255.255.0
И на локальных машинках 192.168.50.10-15/255.255.255.0
Возможно, глюк уйдет.

Для сравнения, у меня:
]$ ifconfig
br0 Link encap:Ethernet HWaddr 00:1D:60:AD:76:E8
inet addr:192.168.22.254 Bcast:192.168.22.255 Mask:255.255.255.0
inet6 addr: fe80::21d:60ff:fead:76e8/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:51110075 errors:0 dropped:0 overruns:0 frame:0
TX packets:34007725 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:903615095 (861.7 MiB) TX bytes:3960812030 (3.6 GiB)

eth0 Link encap:Ethernet HWaddr 00:1D:60:AD:76:E8
inet6 addr: fe80::21d:60ff:fead:76e8/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:34819021 errors:0 dropped:0 overruns:0 frame:0
TX packets:51067828 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:62529066 (59.6 MiB) TX bytes:1818737502 (1.6 GiB)
Interrupt:4 Base address:0x1000

eth1 Link encap:Ethernet HWaddr 00:1D:60:AD:76:E8
inet6 addr: fe80::21d:60ff:fead:76e8/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:51208681 errors:0 dropped:0 overruns:0 frame:100336
TX packets:34241162 errors:40 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1672822147 (1.5 GiB) TX bytes:27874856 (26.5 MiB)
Interrupt:12 Base address:0x2000

imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1500 Metric:1
RX packets:14212038 errors:0 dropped:0 overruns:0 frame:0
TX packets:14211883 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:3578844457 (3.3 GiB) TX bytes:3578756182 (3.3 GiB)

imq1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76 (76.0 B) TX bytes:76 (76.0 B)

vlan0 Link encap:Ethernet HWaddr 00:1D:60:AD:76:E8
inet6 addr: fe80::21d:60ff:fead:76e8/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:137918 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:36581240 (34.8 MiB)

vlan1 Link encap:Ethernet HWaddr 00:1D:60:AD:76:E8
inet addr:ххх.ххх.ххх.ххх Bcast:ххх.ххх.ххх.ххх Mask:255.255.255.128
inet6 addr: fe80::21d:60ff:fead:76e8/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:34819021 errors:0 dropped:0 overruns:0 frame:0
TX packets:50929906 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3730753984 (3.4 GiB) TX bytes:1782155914 (1.6 GiB)


Еще как вариант, задать ваш вопрос более опытным товарищам в этой (http://wl500g.info/showthread.php?t=17136&page=207) теме . ;)

lsd_wiz
14-01-2011, 15:39
нашёл такой баг, девайс rt-n16, прошивка RT-N16-1.9.2.7-rtn-r2470 в следующем случае:


# /opt/etc/init.d/S10firewall
....
insmod xt_recent
insmod xt_connlimit
iptables -A FORWARD -p tcp -m connlimit -i br0 -s 192.168.1.1/32 -d ! 192.168.0.0/24 -j DROP --syn --connlimit-above 400
iptables -A FORWARD -p tcp -m connlimit -i br0 -s 192.168.1.2/32 -d ! 192.168.0.0/24 -j DROP --syn --connlimit-above 400
iptables -A FORWARD -p tcp -m connlimit -i br0 -s 192.168.1.3/32 -d ! 192.168.0.0/24 -j DROP --syn --connlimit-above 400
iptables -A FORWARD -p tcp -m connlimit -i br0 -s 192.168.1.4/32 -d ! 192.168.0.0/24 -j DROP --syn --connlimit-above 400
iptables -A FORWARD -p tcp -m connlimit -i br0 -s 192.168.1.5/32 -d ! 192.168.0.0/24 -j DROP --syn --connlimit-above 400
...

система валится ceк чез 5 и уходит в ребут. Если это закаментить то всё гуд.

lly
14-01-2011, 16:05
нашёл такой баг, девайс rt-n16, прошивка RT-N16-1.9.2.7-rtn-r2470 в следующем случае:

Воспроизвести не получается, видимо есть еще какой-то фактор. Возможно снять текст kernel oops нет?
В r2274 то-же самое?

lsd_wiz
14-01-2011, 16:17
Воспроизвести не получается, видимо есть еще какой-то фактор. Возможно снять текст kernel oops нет?
В r2274 то-же самое?
ммм попробую
2274 таже шляпа, когда модули подгружал с connlimit. роутинг прекращается и ребут.
конф в аттаче, больше не чего не юзаю, кроме dhcpd, lighttpd, cron.

lly
14-01-2011, 18:33
ммм попробую
2274 таже шляпа, когда модули подгружал с connlimit. роутинг прекращается и ребут.
конф в аттаче, больше не чего не юзаю, кроме dhcpd, lighttpd, cron.
Попробую повторить, но сильно не уверен в успехе.
А если отключить шейпер на IMQ, падения есть?

lsd_wiz
14-01-2011, 19:35
Попробую повторить, но сильно не уверен в успехе.
А если отключить шейпер на IMQ, падения есть?
Так оно и есть imq и connlimit не дружат. Было подозрение, что imq косячит. Но шейпер больше года рабрал на прежнем девайсе без всяких косяков.

lly
17-01-2011, 18:59
Так оно и есть imq и connlimit не дружат. Было подозрение, что imq косячит. Но шейпер больше года рабрал на прежнем девайсе без всяких косяков.
К сожалению, даже используя приложенный конфиг, у меня баг не всплывает. Видимо не хватает какого-то сочетания превышения траффика.

На "прежнем девайсе" ядро 2.4?