lan-viper Опубликовано 6 февраля, 2012 · Жалоба Тогда забираю свои слова назад: Сделайте его (ext-burst) такимже, как burst, т.е. 768000, тогда скорость не будет задираться. т.к. в них нет смысла, если данное число не учитывается. По теме утечки памяти, промежуточный контроль accel-ppp# show stat uptime: 0.11:09:02 cpu: 0% memory: rss/virt: 101212/178472 kB arena: 98420 kB mmaped: 260 kB uordblks: 97966 kB fordblks: 453 kB core: mempool_allocated: 7060249 mempool_available: 831466 thread_count: 4 thread_active: 1 context_count: 271 context_sleeping: 0 context_pending: 0 md_handler_count: 1046 md_handler_pending: 0 timer_count: 1026 timer_pending: 0 ppp: starting: 1 active: 258 finishing: 0 pptp: starting: 0 active: 100 l2tp: starting: 0 active: 159 radius(1, 127.0.0.1): request count: 0 queue length: 0 auth sent: 949 auth lost(total/5m/1m): 0/0/0 auth avg query time(5m/1m): 1/1 ms acct sent: 1448 acct lost(total/5m/1m): 0/0/0 acct avg query time(5m/1m): 0/1 ms interim sent: 140669 interim lost(total/5m/1m): 1/0/0 interim avg query time(5m/1m): 0/0 ms Уже 100 Мб Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 6 февраля, 2012 (изменено) · Жалоба memdebug.log оказался придательски пуст после серии команд killall -35 accel-pppd; killall -36 accel-pppd; killall accel-pppd. Предварительно сбросил сессии через cli по terminate all soft, после сразуже закрыл порты посредством iptables для pptp и l2tp скриптом... и такой облом. Что не так было сделано мной? PS В core.log только упало скудное [2012-02-07 02:07:23.385]mempool: clean Изменено 6 февраля, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 февраля, 2012 · Жалоба странно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 7 февраля, 2012 (изменено) · Жалоба Собрал последнюю версию 211f028919138cd2c6e3ddfb1fd8221a1273d894. Изменения в конфиге такие: [modules] ... #pppd_compat #connlimit ... Конфигурировал перед компиляцией так: cmake -DBUILD_DRIVER=TRUE -DCMAKE_INSTALL_PREFIX=/usr .. Буду наблюдать, но уже сейчас при 150 сессиях он съел 60 Мбайт. PS Я смотрю, ни у кого больше данной проблемы нет, значит это мне так повезло, видимо какая-то хитрая комбинация софта или моих действий приводит к такому результату. Изменено 7 февраля, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KotikBSd Опубликовано 8 февраля, 2012 · Жалоба Добрый день! Мы предоставляем доступ в инет по EoIP,т.к. всё оборудование управляемое то смысла в туннлях нет. Однако есть необходимость поднятия pptp l2tp pppoe в сети, в первую очередь для ipv6, но так же для некоторых юрлиц. В качестве сервера взяли уже установленный рабочий сервер, работает он в качестве шейпера и ната, практически не нагружен. Сборка acccel-ppp прошла без проблем, за исключением что с опцией шейпера он не собирается, но это косяк в недостающих файлах в ядре, и т.к. он нам пока не нужен, при сборке мы его отключили. а теперь самое интересное, pppoe поднимается без проблем, а вот с pptp - проблемы есть. делаю modprobe pptp включаю accel, пытаюсь подключится, очень долго висит на проверке пароля, а потом говорит что порт закрыт и подключится не получится. при этом в dmesg наблюдаю следующее: [20983084.110382] ------------[ cut here ]------------ [20983084.110394] WARNING: at include/net/dst.h:117 dst_metric+0x35/0x49 [pptp]() [20983084.110398] Hardware name: PowerEdge 1850 [20983084.110401] Modules linked in: pptp ipt_NETFLOW sch_tbf sch_cbq cls_basic sch_ingress ip6table_raw ip6table_filter ip6_tables ppp_mppe ppp_async crc_ccitt pppoe pppox ppp_generic slhc xt_CLASSIFY sch_htb xt_NOTRACK iptable_raw ipt_REDIRECT iptable_nat ipt_REJECT iptable_filter xt_length iptable_mangle ipt_addrtype xt_dscp xt_string ipt_set xt_owner xt_multiport xt_iprange xt_hashlimit xt_conntrack xt_DSCP ipt_SET xt_NFQUEUE xt_mark xt_connmark ip_tables ip_set_ipmap ip_set_iphash nf_nat_pptp nf_nat_proto_gre nf_nat_proto_sctp crc32c libcrc32c nf_nat_ftp nf_nat_irc nf_nat_tftp nf_nat_h323 nf_nat_proto_dccp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_proto_sctp nf_conntrack_h323 nf_conntrack_netlink nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_irc nf_conntrack_proto_dccp ip_set nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack [last unloaded: pptp] [20983084.110486] Pid: 27566, comm: accel-pppd Tainted: G W 2.6.38-gentoo-r6 #1 [20983084.110490] Call Trace: [20983084.110501] [<ffffffff8103cde4>] ? warn_slowpath_common+0x80/0x98 [20983084.110507] [<ffffffff8103ce11>] ? warn_slowpath_null+0x15/0x17 [20983084.110513] [<ffffffffa0176355>] ? dst_metric+0x35/0x49 [pptp] [20983084.110520] [<ffffffffa01766f8>] ? pptp_xmit+0x38f/0x41f [pptp] [20983084.110528] [<ffffffffa015c5a3>] ? ppp_channel_push+0x42/0xa6 [ppp_generic] [20983084.110536] [<ffffffffa015c6c1>] ? ppp_write+0xba/0xc6 [ppp_generic] [20983084.110543] [<ffffffff810e414c>] ? vfs_write+0xa9/0x105 [20983084.110551] [<ffffffff811117cc>] ? ep_ptable_queue_proc+0x0/0x92 [20983084.110556] [<ffffffff810e4261>] ? sys_write+0x45/0x6c [20983084.110564] [<ffffffff8100293b>] ? system_call_fastpath+0x16/0x1b [20983084.110568] ---[ end trace 310eecc556dcd3b8 ]--- Система - Linux deathstar1 2.6.38-gentoo-r6 #1 SMP Fri Jun 10 13:40:39 MSD 2011 x86_64 Intel® Xeon CPU 2.80GHz GenuineIntel GNU/Linux accel - accel-ppp-1.5.0 Есть мысли как с таким бороться ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 8 февраля, 2012 · Жалоба ядро надо обновить до 3.1-3.2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 февраля, 2012 · Жалоба Xeb как то решить проблему хотелось бы по новому шейперу, сервер стоит на Debian Squeeze работает стабильно, версия из гита 1.5.0, настройки нового шейпера стандартные через htb, но скорость входящая режеться а исходящая нет, даже на тарифе 5Мбит/с, или может модули надо подгрузить, для новой версии какие модули надо подгружать? И в новой версии так и не смог подключиться к консоле сервера? Вот настройки [modules] #path=/usr/local/lib/accel-ppp log_file #log_syslog #log_tcp #log_pgsql pptp l2tp #pppoe auth_mschap_v2 #auth_mschap_v1 #auth_chap_md5 #auth_pap radius #ippool sigchld #pppd_compat shaper #shaper_tbf (obsolete) #chap-secrets #net-snmp #logwtmp #connlimit #ipv6_nd #ipv6_dhcp #ipv6pool [pppd-compat] #ip-pre-up=/etc/ppp/ip-pre-up #ip-up=/etc/ppp/ip-up #ip-down=/etc/ppp/ip-down #ip-change=/etc/ppp/ip-change #radattr-prefix=/var/run/radattr #verbose=1 [shaper] vendor=Cisco attr=Cisco-AVPair time-range=1,09:00-23:59 time-range=2,00:00-08:59 #attr=Filter-Id #down-burst-factor=0.1 #up-burst-factor=10.0 #latency=50 #mpu=0 up-limiter=htb down-limiter=htb ifb=ifb0 r2q=10 quantum=1500 verbose=1 #tbf is obsolete, use shaper module #[tbf] #attr=Filter-Id #down-burst-factor=0.1 #up-burst-factor=1.0 #latency=50 [cli] telnet=127.0.0.1:2000 #tcp=127.0.0.1:2001 password=123 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 8 февраля, 2012 · Жалоба для новой версии какие модули надо подгружать? ничего не нужно, только ifb, но он автоматом подгружается И в новой версии так и не смог подключиться к консоле сервера? всмысле по телнету не подключается ? Xeb как то решить проблему хотелось бы по новому шейперу ну давай всё проверим, скинь сюда при поднятом коннекте:tc qdisc show dev pppX tc -s class show dev pppX tc filter show dev pppX parent ffff: tc filter show dev ifb0 tc qdisc show dev ifb0 tc-s class show dev ifb0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 февраля, 2012 · Жалоба для новой версии какие модули надо подгружать? ничего не нужно, только ifb, но он автоматом подгружается И в новой версии так и не смог подключиться к консоле сервера? всмысле по телнету не подключается ? Xeb как то решить проблему хотелось бы по новому шейперу ну давай всё проверим, скинь сюда при поднятом коннекте:tc qdisc show dev pppX tc -s class show dev pppX tc filter show dev pppX parent ffff: tc filter show dev ifb0 tc qdisc show dev ifb0 tc-s class show dev ifb0 да по телнету не подключается вот скидываю вывод команд root@debdns:~# tc qdisc show dev ppp0 qdisc htb 1: root refcnt 2 r2q 10 default 1 direct_packets_stat 0 qdisc ingress ffff: parent ffff:fff1 ---------------- root@debdns:~# tc -s class show dev ppp0 class htb 1:1 root prio 0 rate 5512Kbit ceil 5512Kbit burst 1033500b cburst 1033500b Sent 3459 bytes 47 pkt (dropped 0, overlimits 0 requeues 0) rate 960bit 2pps backlog 0b 0p requeues 0 lended: 47 borrowed: 0 giants: 0 tokens: 23436063 ctokens: 23436063 root@debdns:~# tc filter show dev ppp0 parent ffff: filter protocol ip pref 1 u32 filter protocol ip pref 1 u32 fh 800: ht divisor 1 filter protocol ip pref 1 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid :1 match 00000000/00000000 at 0 action order 1: skbedit priority :1 action order 2: mirred (Egress Redirect to device ifb0) stolen index 5 ref 1 bind 1 root@debdns:~# tc filter show dev ifb0 filter parent 1: protocol ip pref 1 flow filter parent 1: protocol ip pref 1 flow handle 0x1 map keys priority baseclass 1:1 root@debdns:~# tc qdisc show dev ifb0 qdisc htb 1: root refcnt 2 r2q 10 default 0 direct_packets_stat 0 root@debdns:~# tc -s class show dev ifb0 class htb 1:2 root prio 0 rate 5512Kbit ceil 5512Kbit burst 1033500b cburst 1033500b Sent 2016 bytes 16 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 16 borrowed: 0 giants: 0 tokens: 23435157 ctokens: 23435157 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 8 февраля, 2012 · Жалоба выглядит ок, не знаю почему не шейпит корректно, оффлоады на сетевых картах отключены ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 февраля, 2012 (изменено) · Жалоба Некорректно шейпить может запросто из-за больших значений burst, делайте меньше. Возьмите к примеру такую формулу: rate(Kbit) * 1000 / 16 = burst(bit) class htb 1:1 root prio 0 rate 5512Kbit ceil 5512Kbit burst 1033500b cburst 1033500b А то у Вас целый мегабит барста для 5-ти мегабитного канала - много. Тестируйте разными мерилками: http://speedtest.net/, http://internet.yandex.ru/, http://speed.yorest.ru/, http://speed.yoip.ru/ Изменено 8 февраля, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 февраля, 2012 (изменено) · Жалоба выглядит ок, не знаю почему не шейпит корректно, оффлоады на сетевых картах отключены ? офлоады точно сейчас не скажу, autonegotiation отключено, сетевые intel igb драйвера, так дело в том что и с обычными сетевыми такой же результат. Интерно еще подключаюсь под VPN логином 15МБ тарифом тест скачок до 20МБ потом снижается на 15МБ исходящая 10МБ, подключаюсь на 5МБ тест 5МБ чисто исходящая 7МБ. На speedtest.net всегда и меряем до провайдера, всегда норм резалось на простом tc шейпере. Изменено 8 февраля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 февраля, 2012 · Жалоба Некорректно шейпить может запросто из-за больших значений burst, делайте меньше. Возьмите к примеру такую формулу: rate(Kbit) * 1000 / 16 = burst(bit) class htb 1:1 root prio 0 rate 5512Kbit ceil 5512Kbit burst 1033500b cburst 1033500b А то у Вас целый мегабит барста для 5-ти мегабитного канала - много. Тестируйте разными мерилками: http://speedtest.net/, http://internet.yandex.ru/, http://speed.yorest.ru/, http://speed.yoip.ru/ может ты и прав завтра проверю Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 февраля, 2012 (изменено) · Жалоба О! мы уже на ты?, не заметил... UPD Что-бы сообщение не показалось офтопом, напишу ещё вот про что - замерять для продакшена точность нарезки полосы только одним speedtest.net неправильно. iperf надобно гонять, а спидтесты часто муть, далёкую от реальности показывают. Изменено 8 февраля, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 9 февраля, 2012 · Жалоба О! мы уже на ты?, не заметил... UPD Что-бы сообщение не показалось офтопом, напишу ещё вот про что - замерять для продакшена точность нарезки полосы только одним speedtest.net неправильно. iperf надобно гонять, а спидтесты часто муть, далёкую от реальности показывают. Перерасчитал burst, значения уменьшали, нет не какого толку, скорость меряем не только speedtest, но и на Cisco коммутаторе, а так же на спидтесте провайдера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 9 февраля, 2012 · Жалоба ну а tbf/police тоже не корректно режет ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 9 февраля, 2012 (изменено) · Жалоба ну а tbf/police тоже не корректно режет ? пробывал разные типы варианты, с входящёй нормально, а исходящая не как, может возможно в шейпер встроить новые правила, например стандартного шейпера, ##### speed server->client if [ "$UPSPEED" != "0" ] ; then # /sbin/tc qdisc add dev $1 root handle 1: htb default 20 r2q 1 /sbin/tc qdisc add dev $1 root handle 1: htb default 20 /sbin/tc class add dev $1 parent 1: classid 1:1 htb rate ${UPSPEED}kbit burst 4k /sbin/tc class add dev $1 parent 1:1 classid 1:10 htb rate ${UPSPEED}kbit burst 4k prio 1 /sbin/tc class add dev $1 parent 1:1 classid 1:20 htb rate ${UPSPEED}kbit burst 4k prio 2 /sbin/tc qdisc add dev $1 parent 1:10 handle 10: sfq perturb 10 quantum 1500 /sbin/tc qdisc add dev $1 parent 1:20 handle 20: sfq perturb 10 quantum 1500 /sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10 /sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10 /sbin/tc filter add dev $1 parent 1: protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u160x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10 fi ##### speed client->server if [ "$DOWNSPEED" != "0" ] ; then /sbin/tc qdisc add dev $1 handle ffff: ingress /sbin/tc filter add dev $1 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${DOWNSPEED}kbit burst 12k drop flowid :1 fi Изменено 9 февраля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 февраля, 2012 · Жалоба Некорректно шейпить может запросто из-за больших значений burst Ни разу проблем не было. Из-за cburst - да, были непонятности. У нас на шейперах burst стоит 1 мбайт, cburst - дефолтный минимум. может возможно в шейпер встроить новые правила А скрипты юзать, коли сильно хочется - религия не позволяет? :) К слову, в приведенном скрипте есть грубая ошибка, дающая при определенных условиях двойную скорость на даунлоад... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 9 февраля, 2012 · Жалоба В версии 1.5 c sourceforge.net и с git начались проблемы,и аномалию выявить сложно. Сервер пока не в работе. Подробнее о проблеме: Перестают бегать пакеты по тонелю, причём это было замечено при нагруженном канале, не важно торентом или проверкой канала спидтестами или iperf. После чего сессия отваливается через 60 секунд. Возникало и при pptp и при l2tp. Тестировалось на 2 машинах. Одна Debian другая Windows 7 pro. О сервере: root@pppd:~# uname -a Linux pppd 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux CPU Intel® Core i7 CPU 920 @ 2.67GHz NET Ethernet controller: Intel Corporation 82576 Gigabit Network Connection, в бондинге. Драйвера от Intel root@pppd:~# modinfo igb version: 2.1.9 accel-pppd компилировался следующим образом cmake -DBUILD_DRIVER=TRUE -DKDIR=/usr/src/linux -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Release -DLOG_PGSQL=FALSE -DSHAPER=FALSE -DRADIUS=TRUE -DNETSNMP=FALSE .. root@pppd:~# cat /etc/accel-pppd.conf [modules] log_file pptp l2tp auth_mschap_v2 auth_mschap_v1 auth_pap radius sigchld pppd_compat [core] log-error=/var/log/accel-ppp/core.log thread-count=8 [ppp] verbose=1 min-mtu=1280 mtu=1400 mru=1400 ccp=0 mppe=deny ipv4=require ipv6=deny [lcp] echo-interval=30 echo-failure=3 [pptp] echo-interval=30 verbose=1 [l2tp] dictionary=/usr/local/share/accel-ppp/l2tp/dictionary hello-interval=60 timeout=60 rtimeout=5 retransmit=5 host-name=accel-ppp dir300_quirk=1 verbose=1 [dns] dns1=*.*.*.* dns2=*.*.*.* [radius] nas-identifier=ppp nas-ip-address=10.0.0.1 gw-ip-address=10.0.0.2 server=10.0.0.150,******* acct-timeout=0 verbose=1 [client-ip-range] 10.0.0.0/8 192.168.0.0/16 [log] log-file=/var/log/accel-ppp/accel-ppp.log log-emerg=/var/log/accel-ppp/emerg.log copy=1 level=5 [pppd-compat] #ip-pre-up=/etc/ppp/ip-pre-up ip-up=/etc/ppp/ip-up ip-down=/etc/ppp/ip-down ip-change=/etc/ppp/ip-change radattr-prefix=/var/run/radattr verbose=1 [cli] telnet=127.0.0.1:2000 tcp=127.0.0.1:2001 Логирование 5 уровня только поставил. Шейпер использую dummynet так как аплоад police и htb реализовать не смог, но проблема возникала и до установки шейпера Вот что последнее сервер ответил при лог левэле 3 [2012-02-09 14:42:29]: info: ppp2: send [RADIUS(1) Accounting-Request id=20 <User-Name "user"> <NAS-Identifier "pptp"> <NAS-IP-Address 10.0.0.1> <NAS-Port 2> <NAS- Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.6.94"> <Called-Station-Id "10.0.0.1"> <Class > <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f5355639c"> <Acct-Session-Time 17220> <Acct-Input-Octets 514605052> <Acct-Output-Octets 1749391149> <Acct-Input-Packets 1207806> <Acct-Output-Packets 1534887> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address *.*.*.*> <Acct-Terminate-Cause User-Request>] [2012-02-09 14:42:29]: info: ppp2: recv [RADIUS(1) Accounting-Response id=20] [2012-02-09 14:42:32]: info: ppp2: disconnected Параметры сетевых карт rx-checksumming: off tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off rx-checksumming: on generic-receive-offload: on пробовал делать и так Подскажите в чём может быть причина разрыва соединения в тунеле? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 9 февраля, 2012 · Жалоба Подскажите в чём может быть причина разрыва соединения в тунеле? жду подробных логов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 9 февраля, 2012 · Жалоба Некорректно шейпить может запросто из-за больших значений burst Ни разу проблем не было. Из-за cburst - да, были непонятности. У нас на шейперах burst стоит 1 мбайт, cburst - дефолтный минимум. Ну тут имелось ввиду то, что неизвестно, как устроен тот же speedtest.net от ookla, фиг его знает, как он результаты насчитывает? Иной раз было - накрутил burst побольше, а он мне под конец измерения делает выброс до 30 - 50 Мбит и всё портит. Стоит уменьшить значение burst, становится гладенько. А так и у меня нормально, но IMHO, на тарифах выше 5 - 10 Мбит выкручивать burst уже нет смысла, т.к. это было актуально при скоростях меньше мегабита. Тогда создавалось впечатление, что странички грузятся быстрее )). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 февраля, 2012 · Жалоба Иной раз было - накрутил burst побольше, а он мне под конец измерения делает выброс до 30 - 50 Мбит и всё портит Как-то не замечал такого... Разве что если тестируемый сервер перегружен, то такое возможно. Ну а по целесообразности - да, у нас оно со времен макс. пакетов в пару мегабит было. Сейчас - пока не трогаем, пускай живет, хоть более 80% пользуются 20 мбитами и выше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 9 февраля, 2012 · Жалоба debug: ppp0: ppp_terminate [2012-02-09 16:53:20]: info: ppp0: send [RADIUS(1) Accounting-Request id=6d <User-Name "user"> <NAS-Identifier "pptp-5"> <NAS-IP-Address 10.5.5.1> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.6.94"> <Called-Station-Id "10.5.5.1"> <Class > <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53556379"> <Acct-Session-Time 6480> <Acct-Input-Octets 1634441567> <Acct-Output-Octets 1924324572> <Acct-Input-Packets 8792274> <Acct-Output-Packets 14598102> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 4> <Framed-IP-Address *.*.*.*> <Acct-Terminate-Cause User-Request>] [2012-02-09 16:53:20]: info: ppp0: recv [RADIUS(1) Accounting-Response id=6d] [2012-02-09 16:53:20]: debug: ppp0: lcp_layer_finish [2012-02-09 16:53:20]: debug: ppp0: auth_layer_finish [2012-02-09 16:53:20]: debug: ppp0: auth_layer_finished [2012-02-09 16:53:20]: debug: ppp0: ccp_layer_finish [2012-02-09 16:53:20]: debug: ppp0: ccp_layer_finished [2012-02-09 16:53:20]: debug: ppp0: ipcp_layer_finish [2012-02-09 16:53:20]: debug: ppp0: ipcp_layer_finished [2012-02-09 16:53:20]: debug: ppp0: ipv6cp_layer_finish [2012-02-09 16:53:20]: debug: ppp0: ipv6cp_layer_finished [2012-02-09 16:53:21]: debug: ppp3: send [PPTP Echo-Request <Identifier 56167394>] [2012-02-09 16:53:21]: debug: ppp3: recv [PPTP Echo-Reply <Identifier 56167394>] [2012-02-09 16:53:21]: debug: ppp3: send [LCP EchoReq id=ce <magic 5577f8e1>] [2012-02-09 16:53:21]: debug: ppp3: recv [LCP EchoRep id=ce <magic d1a4940d>] [2012-02-09 16:53:23]: debug: ppp0: fsm timeout [2012-02-09 16:53:23]: debug: ppp0: lcp_layer_finished [2012-02-09 16:53:23]: debug: ppp0: lcp_layer_free [2012-02-09 16:53:23]: debug: ppp0: auth_layer_free [2012-02-09 16:53:23]: debug: ppp0: ccp_layer_free [2012-02-09 16:53:23]: debug: ppp0: ipcp_layer_free [2012-02-09 16:53:23]: debug: ppp0: ipv6cp_layer_free [2012-02-09 16:53:23]: debug: ppp0: ppp destablished [2012-02-09 16:53:23]: info: ppp0: pppd_compat: ip-down started (pid 7847) [2012-02-09 16:53:23]: info: ppp0: pppd_compat: ip-down finished (0) [2012-02-09 16:53:23]: debug: ppp0: pptp: ppp finished [2012-02-09 16:53:23]: info: ppp0: send [PPTP Call-Disconnect-Notify <Call-ID 0> <Result 3> <Error 0> <Cause 0>] [2012-02-09 16:53:23]: info: ppp0: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>] [2012-02-09 16:53:23]: info: ppp0: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>] [2012-02-09 16:53:23]: debug: ppp0: pptp: disconnect [2012-02-09 16:53:23]: info: ppp0: disconnected Вот раннее когда уже перестали бегать пакеты на внешние ресурсы root@pppd5:~# tail -f /var/log/accel-ppp/accel-ppp.log [2012-02-09 16:51:19]: debug: ppp5: recv [LCP EchoRep id=8 <magic f1f2fe0c>] [2012-02-09 16:51:20]: debug: ppp0: send [PPTP Echo-Request <Identifier 3a541011>] [2012-02-09 16:51:20]: debug: ppp0: recv [PPTP Echo-Reply <Identifier 3a541011>] [2012-02-09 16:51:20]: debug: ppp0: send [LCP EchoReq id=d3 <magic 333ab105>] [2012-02-09 16:51:20]: debug: ppp0: recv [LCP EchoReq id=d4 <magic b4d2ae3e>] [2012-02-09 16:51:20]: debug: ppp0: send [LCP EchoRep id=d4 <magic 5b13a33>] [2012-02-09 16:51:21]: debug: ppp3: send [PPTP Echo-Request <Identifier 4423c777>] [2012-02-09 16:51:21]: debug: ppp3: recv [PPTP Echo-Reply <Identifier 4423c777>] [2012-02-09 16:51:21]: debug: ppp3: send [LCP EchoReq id=ca <magic 5577f8e1>] [2012-02-09 16:51:21]: debug: ppp3: recv [LCP EchoRep id=ca <magic d1a4940d>] [2012-02-09 16:51:33]: debug: ppp1: send [PPTP Echo-Request <Identifier 5f5c6e4d>] [2012-02-09 16:51:33]: debug: ppp1: recv [PPTP Echo-Reply <Identifier 5f5c6e4d>] [2012-02-09 16:51:33]: debug: ppp1: send [LCP EchoReq id=cc <magic 6ceaf087>] [2012-02-09 16:51:33]: debug: ppp1: recv [LCP EchoRep id=cc <magic f48b58d3>] [2012-02-09 16:51:36]: debug: ppp2: send [PPTP Echo-Request <Identifier 7c2a56cd>] [2012-02-09 16:51:36]: debug: ppp2: recv [PPTP Echo-Reply <Identifier 7c2a56cd>] [2012-02-09 16:51:36]: debug: ppp2: send [LCP EchoReq id=d2 <magic 79838cb2>] [2012-02-09 16:51:36]: debug: ppp2: recv [LCP EchoRep id=d2 <magic ea105f7b>] [2012-02-09 16:51:41]: debug: ppp4: send [PPTP Echo-Request <Identifier 7ab86ee1>] [2012-02-09 16:51:41]: debug: ppp4: recv [PPTP Echo-Reply <Identifier 7ab86ee1>] [2012-02-09 16:51:41]: debug: ppp4: send [LCP EchoReq id=a9 <magic 555c55b5>] [2012-02-09 16:51:41]: debug: ppp4: recv [LCP EchoRep id=a9 <magic bd00073d>] [2012-02-09 16:51:46]: debug: ppp5: send [PPTP Echo-Request <Identifier b54e53b>] [2012-02-09 16:51:46]: debug: ppp5: recv [PPTP Echo-Reply <Identifier b54e53b>] [2012-02-09 16:51:49]: debug: ppp5: send [LCP EchoReq id=9 <magic bf783f>] [2012-02-09 16:51:49]: debug: ppp5: recv [LCP EchoRep id=9 <magic f1f2fe0c>] [2012-02-09 16:51:50]: debug: ppp0: send [PPTP Echo-Request <Identifier 2a00487>] [2012-02-09 16:51:50]: debug: ppp0: recv [PPTP Echo-Reply <Identifier 2a00487>] [2012-02-09 16:51:50]: debug: ppp0: send [LCP EchoReq id=d3 <magic 333ab105>] [2012-02-09 16:51:50]: debug: ppp0: recv [LCP EchoReq id=d5 <magic b4d2ae3e>] [2012-02-09 16:51:50]: debug: ppp0: send [LCP EchoRep id=d5 <magic 5b13a33>] [2012-02-09 16:51:51]: debug: ppp3: send [PPTP Echo-Request <Identifier 6cb1b60>] [2012-02-09 16:51:51]: debug: ppp3: recv [PPTP Echo-Reply <Identifier 6cb1b60>] [2012-02-09 16:51:51]: debug: ppp3: send [LCP EchoReq id=cb <magic 5577f8e1>] [2012-02-09 16:51:51]: debug: ppp3: recv [LCP EchoRep id=cb <magic d1a4940d>] [2012-02-09 16:52:03]: debug: ppp1: send [PPTP Echo-Request <Identifier 72edd574>] [2012-02-09 16:52:03]: debug: ppp1: recv [PPTP Echo-Reply <Identifier 72edd574>] [2012-02-09 16:52:03]: debug: ppp1: send [LCP EchoReq id=cd <magic 6ceaf087>] [2012-02-09 16:52:03]: debug: ppp1: recv [LCP EchoRep id=cd <magic f48b58d3>] [2012-02-09 16:52:06]: debug: ppp2: send [PPTP Echo-Request <Identifier 7323808a>] [2012-02-09 16:52:06]: debug: ppp2: recv [PPTP Echo-Reply <Identifier 7323808a>] [2012-02-09 16:52:06]: debug: ppp2: send [LCP EchoReq id=d3 <magic 79838cb2>] [2012-02-09 16:52:06]: debug: ppp2: recv [LCP EchoRep id=d3 <magic ea105f7b>] [2012-02-09 16:52:11]: debug: ppp4: send [PPTP Echo-Request <Identifier 5157276>] [2012-02-09 16:52:11]: debug: ppp4: recv [PPTP Echo-Reply <Identifier 5157276>] [2012-02-09 16:52:11]: debug: ppp4: send [LCP EchoReq id=aa <magic 555c55b5>] [2012-02-09 16:52:11]: debug: ppp4: recv [LCP EchoRep id=aa <magic bd00073d>] [2012-02-09 16:52:16]: debug: ppp5: send [PPTP Echo-Request <Identifier 35a681db>] [2012-02-09 16:52:16]: debug: ppp5: recv [PPTP Echo-Reply <Identifier 35a681db>] [2012-02-09 16:52:19]: debug: ppp5: send [LCP EchoReq id=a <magic bf783f>] [2012-02-09 16:52:19]: debug: ppp5: recv [LCP EchoRep id=a <magic f1f2fe0c>] [2012-02-09 16:52:20]: debug: ppp0: send [PPTP Echo-Request <Identifier 1786c974>] [2012-02-09 16:52:20]: debug: ppp0: recv [PPTP Echo-Reply <Identifier 1786c974>] [2012-02-09 16:52:20]: debug: ppp0: send [LCP EchoReq id=d3 <magic 333ab105>] [2012-02-09 16:52:20]: debug: ppp0: recv [LCP EchoReq id=d6 <magic b4d2ae3e>] [2012-02-09 16:52:20]: debug: ppp0: send [LCP EchoRep id=d6 <magic 5b13a33>] [2012-02-09 16:52:21]: debug: ppp3: send [PPTP Echo-Request <Identifier 1c2427a1>] [2012-02-09 16:52:21]: debug: ppp3: recv [PPTP Echo-Reply <Identifier 1c2427a1>] [2012-02-09 16:52:21]: debug: ppp3: send [LCP EchoReq id=cc <magic 5577f8e1>] [2012-02-09 16:52:21]: debug: ppp3: recv [LCP EchoRep id=cc <magic d1a4940d>] [2012-02-09 16:52:33]: debug: ppp1: send [PPTP Echo-Request <Identifier 63a24d68>] [2012-02-09 16:52:33]: debug: ppp1: recv [PPTP Echo-Reply <Identifier 63a24d68>] [2012-02-09 16:52:33]: debug: ppp1: send [LCP EchoReq id=ce <magic 6ceaf087>] [2012-02-09 16:52:33]: debug: ppp1: recv [LCP EchoRep id=ce <magic f48b58d3>] [2012-02-09 16:52:36]: debug: ppp2: send [PPTP Echo-Request <Identifier 4fb7a02a>] [2012-02-09 16:52:36]: debug: ppp2: recv [PPTP Echo-Reply <Identifier 4fb7a02a>] [2012-02-09 16:52:36]: debug: ppp2: send [LCP EchoReq id=d4 <magic 79838cb2>] [2012-02-09 16:52:36]: debug: ppp2: recv [LCP EchoRep id=d4 <magic ea105f7b>] [2012-02-09 16:52:41]: debug: ppp4: send [PPTP Echo-Request <Identifier 96cf728>] [2012-02-09 16:52:41]: debug: ppp4: recv [PPTP Echo-Reply <Identifier 96cf728>] [2012-02-09 16:52:41]: debug: ppp4: send [LCP EchoReq id=ab <magic 555c55b5>] [2012-02-09 16:52:41]: debug: ppp4: recv [LCP EchoRep id=ab <magic bd00073d>] [2012-02-09 16:52:46]: debug: ppp5: send [PPTP Echo-Request <Identifier 3b121183>] [2012-02-09 16:52:46]: debug: ppp5: recv [PPTP Echo-Reply <Identifier 3b121183>] [2012-02-09 16:52:49]: debug: ppp5: send [LCP EchoReq id=b <magic bf783f>] [2012-02-09 16:52:49]: debug: ppp5: recv [LCP EchoRep id=b <magic f1f2fe0c>] [2012-02-09 16:52:50]: debug: ppp0: send [PPTP Echo-Request <Identifier 3459648f>] [2012-02-09 16:52:50]: debug: ppp0: recv [PPTP Echo-Reply <Identifier 3459648f>] [2012-02-09 16:52:50]: debug: ppp0: send [LCP EchoReq id=d3 <magic 333ab105>] [2012-02-09 16:52:50]: debug: ppp0: recv [LCP EchoReq id=d7 <magic b4d2ae3e>] [2012-02-09 16:52:50]: debug: ppp0: send [LCP EchoRep id=d7 <magic 5b13a33>] [2012-02-09 16:52:51]: debug: ppp3: send [PPTP Echo-Request <Identifier 3adf331d>] [2012-02-09 16:52:51]: debug: ppp3: recv [PPTP Echo-Reply <Identifier 3adf331d>] [2012-02-09 16:52:51]: debug: ppp3: send [LCP EchoReq id=cd <magic 5577f8e1>] [2012-02-09 16:52:51]: debug: ppp3: recv [LCP EchoRep id=cd <magic d1a4940d>] [2012-02-09 16:53:03]: debug: ppp1: send [PPTP Echo-Request <Identifier 4d08a9e4>] [2012-02-09 16:53:03]: debug: ppp1: recv [PPTP Echo-Reply <Identifier 4d08a9e4>] [2012-02-09 16:53:03]: debug: ppp1: send [LCP EchoReq id=cf <magic 6ceaf087>] [2012-02-09 16:53:03]: debug: ppp1: recv [LCP EchoRep id=cf <magic f48b58d3>] [2012-02-09 16:53:06]: debug: ppp2: send [PPTP Echo-Request <Identifier 6af2bb3a>] [2012-02-09 16:53:06]: debug: ppp2: recv [PPTP Echo-Reply <Identifier 6af2bb3a>] [2012-02-09 16:53:06]: debug: ppp2: send [LCP EchoReq id=d5 <magic 79838cb2>] [2012-02-09 16:53:06]: debug: ppp2: recv [LCP EchoRep id=d5 <magic ea105f7b>] [2012-02-09 16:53:11]: debug: ppp4: send [PPTP Echo-Request <Identifier 481b1739>] [2012-02-09 16:53:11]: debug: ppp4: recv [PPTP Echo-Reply <Identifier 481b1739>] [2012-02-09 16:53:11]: debug: ppp4: send [LCP EchoReq id=ac <magic 555c55b5>] [2012-02-09 16:53:11]: debug: ppp4: recv [LCP EchoRep id=ac <magic bd00073d>] [2012-02-09 16:53:16]: debug: ppp5: send [PPTP Echo-Request <Identifier 19e2bfcc>] [2012-02-09 16:53:16]: debug: ppp5: recv [PPTP Echo-Reply <Identifier 19e2bfcc>] [2012-02-09 16:53:19]: debug: ppp5: send [LCP EchoReq id=c <magic bf783f>] [2012-02-09 16:53:19]: debug: ppp5: recv [LCP EchoRep id=c <magic f1f2fe0c>] [2012-02-09 16:53:20]: debug: ppp0: send [PPTP Echo-Request <Identifier 66d021ca>] [2012-02-09 16:53:20]: debug: ppp0: recv [PPTP Echo-Reply <Identifier 66d021ca>] [2012-02-09 16:53:20]: debug: ppp0: send [LCP EchoReq id=d3 <magic 333ab105>] [2012-02-09 16:53:20]: info: ppp0: recv [LCP TermReq id=3] [2012-02-09 16:53:20]: info: ppp0: send [LCP TermAck id=3] Перестали бегать пакеты примерно в 16:49 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KotikBSd Опубликовано 10 февраля, 2012 (изменено) · Жалоба обновил ядро - Linux deathstar1 3.2.1-gentoo-r2 #1 SMP Fri Feb 10 11:17:04 MSK 2012 x86_64 Intel® Xeon CPU 2.80GHz GenuineIntel GNU/Linux Однако сразу-же проблема - не собирается accel, а точнее модуль pptp :( Я вырезал из вывода MAKE те строчки которые не вызывали варнингов и ошибок, да бы не разрушать всем зрение ))) # git clone git://accel-ppp.git.sourceforge.net/gitroot/accel-ppp/accel-ppp /root/accel-ppp-GIT/ # cd accel-ppp-build/ # cmake -DBUILD_DRIVER=TRUE -DKDIR=/usr/src/linux -DCMAKE_INSTALL_PREFIX=/usr/local/accel-ppp/ -DCMAKE_BUILD_TYPE=Release -DLOG_PGSQL=FALSE -DSHAPER=FALSE -DRADIUS=TRUE -DNETSNMP=TRUE ../accel-ppp-GIT/ -- The C compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Looking for timerfd_create -- Looking for timerfd_create - found -- Configuring done -- Generating done -- Build files have been written to: /root/accel-ppp-build deathstar1 accel-ppp-build # make [ 3%] Building C object accel-pppd/triton/CMakeFiles/triton.dir/triton.c.o /root/accel-ppp-GIT/accel-pppd/triton/triton.c: In function 'ctx_thread': /root/accel-ppp-GIT/accel-pppd/triton/triton.c:206: warning: ignoring return value of 'read', declared with attribute warn_unused_result [ 10%] Building C object accel-pppd/CMakeFiles/accel-pppd.dir/ppp/ppp.c.o /root/accel-ppp-GIT/accel-pppd/ppp/ppp.c: In function 'init': /root/accel-ppp-GIT/accel-pppd/ppp/ppp.c:787: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [ 22%] Building C object accel-pppd/CMakeFiles/accel-pppd.dir/ppp/ipv6cp_opt_intfid.c.o /root/accel-ppp-GIT/accel-pppd/ppp/ipv6cp_opt_intfid.c:226: warning: ignoring return value of 'write', declared with attribute warn_unused_result [ 26%] Building C object accel-pppd/CMakeFiles/accel-pppd.dir/cli/std_cmd.c.o /root/accel-ppp-GIT/accel-pppd/cli/std_cmd.c: In function 'show_stat_exec': /root/accel-ppp-GIT/accel-pppd/cli/std_cmd.c:34: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [ 29%] Building C object accel-pppd/CMakeFiles/accel-pppd.dir/cli/telnet.c.o /root/accel-ppp-GIT/accel-pppd/cli/telnet.c: In function 'save_history_file': /root/accel-ppp-GIT/accel-pppd/cli/telnet.c:697: warning: ignoring return value of 'write', declared with attribute warn_unused_result [ 37%] Building C object accel-pppd/CMakeFiles/accel-pppd.dir/log.c.o /root/accel-ppp-GIT/accel-pppd/log.c: In function 'write_msg': /root/accel-ppp-GIT/accel-pppd/log.c:341: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result [ 38%] Building C object accel-pppd/CMakeFiles/accel-pppd.dir/main.c.o /root/accel-ppp-GIT/accel-pppd/main.c: In function 'change_limits': /root/accel-ppp-GIT/accel-pppd/main.c:29: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result /root/accel-ppp-GIT/accel-pppd/main.c:35: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result /root/accel-ppp-GIT/accel-pppd/main.c: In function 'main': /root/accel-ppp-GIT/accel-pppd/main.c:104: warning: ignoring return value of 'daemon', declared with attribute warn_unused_result [ 50%] Building C object accel-pppd/ctrl/pptp/CMakeFiles/pptp.dir/pptp.c.o /root/accel-ppp-GIT/accel-pppd/ctrl/pptp/pptp.c: In function 'pptp_init': /root/accel-ppp-GIT/accel-pppd/ctrl/pptp/pptp.c:749: warning: ignoring return value of 'system', declared with attribute warn_unused_result [ 51%] Building C object accel-pppd/ctrl/pppoe/CMakeFiles/pppoe.dir/pppoe.c.o /root/accel-ppp-GIT/accel-pppd/ctrl/pppoe/pppoe.c: In function 'pppoe_init': /root/accel-ppp-GIT/accel-pppd/ctrl/pppoe/pppoe.c:1408: warning: ignoring return value of 'system', declared with attribute warn_unused_result /root/accel-ppp-GIT/accel-pppd/ctrl/pppoe/pppoe.c: In function 'pppoe_server_start': /root/accel-ppp-GIT/accel-pppd/ctrl/pppoe/pppoe.c:1127: warning: 'ifname' may be used uninitialized in this function [ 57%] Building C object accel-pppd/ctrl/l2tp/CMakeFiles/l2tp.dir/l2tp.c.o /root/accel-ppp-GIT/accel-pppd/ctrl/l2tp/l2tp.c: In function 'l2tp_init': /root/accel-ppp-GIT/accel-pppd/ctrl/l2tp/l2tp.c:1153: warning: ignoring return value of 'system', declared with attribute warn_unused_result [ 60%] Building C object accel-pppd/auth/CMakeFiles/auth_chap_md5.dir/auth_chap_md5.c.o /root/accel-ppp-GIT/accel-pppd/auth/auth_chap_md5.c: In function 'chap_send_challenge': /root/accel-ppp-GIT/accel-pppd/auth/auth_chap_md5.c:237: warning: ignoring return value of 'read', declared with attribute warn_unused_result [ 61%] Building C object accel-pppd/auth/CMakeFiles/auth_mschap_v1.dir/auth_mschap_v1.c.o /root/accel-ppp-GIT/accel-pppd/auth/auth_mschap_v1.c: In function 'chap_send_challenge': /root/accel-ppp-GIT/accel-pppd/auth/auth_mschap_v1.c:240: warning: ignoring return value of 'read', declared with attribute warn_unused_result [ 62%] Building C object accel-pppd/auth/CMakeFiles/auth_mschap_v2.dir/auth_mschap_v2.c.o /root/accel-ppp-GIT/accel-pppd/auth/auth_mschap_v2.c: In function 'chap_send_challenge': /root/accel-ppp-GIT/accel-pppd/auth/auth_mschap_v2.c:313: warning: ignoring return value of 'read', declared with attribute warn_unused_result [ 83%] Building C object accel-pppd/extra/net-snmp/CMakeFiles/net-snmp.dir/statCore.c.o /root/accel-ppp-GIT/accel-pppd/extra/net-snmp/statCore.c: In function 'handle_statCoreMemRss': /root/accel-ppp-GIT/accel-pppd/extra/net-snmp/statCore.c:119: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [ 96%] Building C object accel-pppd/shaper/CMakeFiles/shaper.dir/limiter.c.o /root/accel-ppp-GIT/accel-pppd/shaper/limiter.c: In function 'init_ifb': /root/accel-ppp-GIT/accel-pppd/shaper/limiter.c:483: warning: ignoring return value of 'system', declared with attribute warn_unused_result [ 98%] Generating driver/pptp.ko In file included from include/asm-generic/shmbuf.h:4, from /usr/src/linux-3.2.1-gentoo-r2/arch/x86/include/asm/shmbuf.h:1, from include/linux/shm.h:47, from include/linux/security.h:32, from include/net/sock.h:53, from /root/accel-ppp-build/driver/driver/if_pppox.h:150, from /root/accel-ppp-build/driver/driver/pptp.c:24: /usr/src/linux-3.2.1-gentoo-r2/arch/x86/include/asm/bitsperlong.h:5:1: warning: "__BITS_PER_LONG" redefined In file included from include/asm-generic/int-ll64.h:11, from include/asm-generic/types.h:7, from /usr/src/linux-3.2.1-gentoo-r2/arch/x86/include/asm/types.h:4, from include/linux/types.h:4, from include/linux/string.h:11, from /root/accel-ppp-build/driver/driver/pptp.c:13: include/asm-generic/bitsperlong.h:12:1: warning: this is the location of the previous definition /root/accel-ppp-build/driver/driver/pptp.c: In function 'pptp_xmit': /root/accel-ppp-build/driver/driver/pptp.c:388: error: unknown field 'oif' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:388: warning: missing braces around initializer /root/accel-ppp-build/driver/driver/pptp.c:388: warning: (near initialization for 'fl.u') /root/accel-ppp-build/driver/driver/pptp.c:389: error: unknown field 'nl_u' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:389: error: extra brace group at end of initializer /root/accel-ppp-build/driver/driver/pptp.c:389: error: (near initialization for 'fl') /root/accel-ppp-build/driver/driver/pptp.c:390: error: extra brace group at end of initializer /root/accel-ppp-build/driver/driver/pptp.c:390: error: (near initialization for 'fl') /root/accel-ppp-build/driver/driver/pptp.c:392: warning: excess elements in struct initializer /root/accel-ppp-build/driver/driver/pptp.c:392: warning: (near initialization for 'fl') /root/accel-ppp-build/driver/driver/pptp.c:393: error: unknown field 'proto' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:393: warning: excess elements in struct initializer /root/accel-ppp-build/driver/driver/pptp.c:393: warning: (near initialization for 'fl') /root/accel-ppp-build/driver/driver/pptp.c:397: warning: passing argument 2 of 'ip_route_output_key' from incompatible pointer type include/net/route.h:123: note: expected 'struct flowi4 *' but argument is of type 'struct rtable **' /root/accel-ppp-build/driver/driver/pptp.c:397: error: too many arguments to function 'ip_route_output_key' /root/accel-ppp-build/driver/driver/pptp.c:397: warning: assignment makes integer from pointer without a cast /root/accel-ppp-build/driver/driver/pptp.c: In function 'pptp_connect': /root/accel-ppp-build/driver/driver/pptp.c:862: error: unknown field 'nl_u' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:862: error: unknown field 'ip4_u' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:863: error: unknown field 'daddr' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:864: error: unknown field 'saddr' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:865: error: unknown field 'tos' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:866: error: unknown field 'proto' specified in initializer /root/accel-ppp-build/driver/driver/pptp.c:866: warning: excess elements in struct initializer /root/accel-ppp-build/driver/driver/pptp.c:866: warning: (near initialization for 'fl') /root/accel-ppp-build/driver/driver/pptp.c:873: warning: passing argument 2 of 'ip_route_output_key' from incompatible pointer type include/net/route.h:123: note: expected 'struct flowi4 *' but argument is of type 'struct rtable **' /root/accel-ppp-build/driver/driver/pptp.c:873: error: too many arguments to function 'ip_route_output_key' make[4]: *** [/root/accel-ppp-build/driver/driver/pptp.o] Error 1 make[3]: *** [_module_/root/accel-ppp-build/driver/driver] Error 2 make[2]: *** [driver/driver/pptp.ko] Error 2 make[1]: *** [driver/CMakeFiles/pptp_drv.dir/all] Error 2 make: *** [all] Error 2 Как тут быть? Изменено 10 февраля, 2012 пользователем KotikBSd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 10 февраля, 2012 · Жалоба А драйвер накой собирать? Он уже в ядре есть... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
