Jump to content
Калькуляторы

http://www.filedropper.com/bering-uclibctesti686isolinuxvga

 

разворачивается на какой-то FAT HDD (ну или подгружаются пакеты с подмонтированного сд вручную через apkg -i /mnt/пакет). leaf.cfg - там список загружаемых пакетов. accelppp - собссно аксель, devtools - gdb, strace и т.п.

Share this post


Link to post
Share on other sites

День добрый!

Xeb, 2 вопроса

 

ipv6 иненованные пулы, как для ipv4

 

и, к примеру, пул

91.219.х.х/24,name=ip_pool_server_based

10.36.0.0/23,name=ip_pool_server_based

чтобы приоритетом раздавались айпишки из пула белых адресов

Share this post


Link to post
Share on other sites
разворачивается на какой-то FAT HDD
запустил, попробовал, не воспроизводится

 

[2015-12-02 22:46:19.686] ipoe0: b12495e228bf9a8f: recv [DHCPv4 Request xid=2c1c0249 ciaddr=192.168.12.2 chaddr=52:54:00:12:34:61 <Message-Type Request> <Host-Name debian-i386> <Request-List Subnet,Broadcast,Time-Offset,Router,Domain-Name,DNS,119,Host-Name,44,47,MTU,Classless-Route,NTP>]
[2015-12-02 22:46:19.686] ipoe0: b12495e228bf9a8f: send [DHCPv4 Ack xid=2c1c0249 ciaddr=192.168.12.2 yiaddr=192.168.12.2 chaddr=52:54:00:12:34:61 <Message-Type Ack> <Server-ID 192.168.12.1> <Lease-Time 60> <T1 60> <Router 192.168.12.1> <Subnet 255.255.255.0>]
[2015-12-02 22:46:29.831] cli: telnet: new connection from 127.0.0.1
[2015-12-02 22:46:34.031] ipoe0: b12495e228bf9a8f: terminate
[2015-12-02 22:47:18.583] ipoe0: b12495e228bf9a8f: recv [DHCPv4 Request xid=2c1c0249 ciaddr=192.168.12.2 chaddr=52:54:00:12:34:61 <Message-Type Request> <Host-Name debian-i386> <Request-List Subnet,Broadcast,Time-Offset,Router,Domain-Name,DNS,119,Host-Name,44,47,MTU,Classless-Route,NTP>]
[2015-12-02 22:47:18.584] send [DHCPv4 Nak xid=2c1c0249 chaddr=52:54:00:12:34:61 <Message-Type Nak>]
[2015-12-02 22:47:18.585] ipoe0: b12495e228bf9a8f: radius(1): req_enter 1
[2015-12-02 22:47:18.586] ipoe0: b12495e228bf9a8f: send [RADIUS(1) Accounting-Request id=3 <User-Name "eth1.2"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 192.168.11.9> <NAS-Port 15> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "52:54:00:12:34:61"> <Called-Station-Id "eth1.2"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "b12495e228bf9a8f"> <Acct-Session-Time 83> <Acct-Input-Octets 656> <Acct-Output-Octets 1128> <Acct-Input-Packets 2> <Acct-Output-Packets 6> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 192.168.12.2> <Acct-Terminate-Cause NAS-Request>]
[2015-12-02 22:47:18.586] ipoe0: b12495e228bf9a8f: pppd_compat: ip-down started (pid 9666)
[2015-12-02 22:47:18.588] ipoe0: b12495e228bf9a8f: pppd_compat: ip-down finished (1)
[2015-12-02 22:47:18.589] ipoe0: b12495e228bf9a8f: radius(1): req_exit 0
[2015-12-02 22:47:18.589] ipoe0: b12495e228bf9a8f: ipoe: session finished
[2015-12-02 22:47:18.596] recv [RADIUS(1) Accounting-Response id=3]
[2015-12-02 22:47:28.079] : : recv [DHCPv4 Discover xid=2f25873 chaddr=52:54:00:12:34:61 <Message-Type Discover> <Host-Name debian-i386> <Request-List Subnet,Broadcast,Time-Offset,Router,Domain-Name,DNS,119,Host-Name,44,47,MTU,Classless-Route,NTP>]

 

Nov 30 20:51:29 test-26 accel-pppd: libnetlink: RTNETLINK answers: No such device
у тебя в ip-down видимо что-то происходит не обычное

Share this post


Link to post
Share on other sites

Да ничего там необычного:

 

# cat /etc/ppp/ip-down
#!/bin/sh
#
# $Id: ip-down,v 1.1.1.1 2010/04/26 09:02:26 nitr0man Exp $
#
# This script is run by the pppd _after_ the link is brought down.
# It uses run-parts to run scripts in /etc/ppp/ip-down.d, so to delete
# routes, unset IP addresses etc. you should create script(s) there.
#
# Be aware that other packages may include /etc/ppp/ip-down.d scripts (named
# after that package), so choose local script names with that in mind.
#
# This script is called with the following arguments:
#    Arg  Name                          Example
#    $1   Interface name                ppp0
#    $2   The tty                       ttyS1
#    $3   The link speed                38400
#    $4   Local IP number               12.34.56.78
#    $5   Peer  IP number               12.34.56.99
#    $6   Optional ``ipparam'' value    foo

# The  environment is cleared before executing this script
# so the path must be reset
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH

# These variables are for the use of the scripts run by run-parts
PPP_IFACE="$1"
PPP_TTY="$2"
PPP_SPEED="$3"
PPP_LOCAL="$4"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM

# as an additional convenience, $PPP_TTYNAME is set to the tty name,
# stripped of /dev/ (if present) for easier matching.
PPP_TTYNAME=`/usr/bin/basename "$2"`
export PPP_TTYNAME 

# Main Script starts here
run-parts /etc/ppp/ip-down.d
[ -x /bin/beep ] && /bin/beep -f 1800 -n -f1200 -n -f900 -n -f600
# last line


# cat /etc/ppp/ip-down.d/ppp-down 
#!/bin/sh
#
# When the ppp link comes up, this script is called with the following
# parameters
#       $1      the interface name used by pppd (e.g. ppp3)
#       $2      the tty device name
#       $3      the tty device speed
#       $4      the local IP address for the interface
#       $5      the remote IP address
#       $6      the parameter specified by the 'ipparam' option to pppd
#

. /etc/ppp/ppp-hsh.conf

if [ -f /var/run/radattr.$OUTPUT ]
then
  IP=$5
  if [ "$IP" = "" ];
     then
     IP="$PPP_REMOTE"
  fi

  /usr/sbin/hsh.sh $IP 102400

fi

аттрибуты:

# cat /var/run/radattr.ipoe0
Reply-Message No corresponding dv_login found for test-E18.2610
Acct-Interim-Interval 60
Session-Timeout 600
User-Name test-E18.2610
Framed-IP-Address 10.250.139.18
Framed-IP-Netmask 0.0.0.0

 

секция конфига акселя:

[ipoe]
verbose=1
username=lua:username
lease-time=120
renew-time=70
max-lease-time=3600
shared=1
ifcfg=1
mode=L2
start=dhcpv4
proxy-arp=2
lua-file=/etc/accel-ppp.lua
soft-terminate=0
check-mac-change=1
interface=re:eth1.[1-9][0-9][0-9][0-9]
gw-ip-address=10.251.0.1/21
gw-ip-address=10.250.128.1/20
gw-ip-address=10.250.64.1/24
gw-ip-address=91.202.132.1/22
gw-ip-address=91.226.56.1/22

Share this post


Link to post
Share on other sites

Что это означает? У клиента скорость теперь постоянно от 700кбит и выше варьируется.

tc -s class show dev ipoe1

class htb 1:1 root leaf 2: prio 0 rate 30000Kbit ceil 30000Kbit burst 1875Kb cburst 306795b
Sent 587030277 bytes 398495 pkt (dropped 16636, overlimits 0 requeues 0)
rate 31090Kbit 2745pps backlog 0b 95p requeues 0
lended: 383263 borrowed: 0 giants: 0
tokens: 6715350 ctokens: -6322

class sfq 2:66 parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 19682b 13p requeues 0
allot 456

class sfq 2:7a parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 22710b 15p requeues 0
allot 864

class sfq 2:bf parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 24224b 16p requeues 0
allot 320

class sfq 2:d5 parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 7570b 5p requeues 0
allot 352

class sfq 2:130 parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 1514b 1p requeues 0
allot 1504

class sfq 2:15d parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 16654b 11p requeues 0
allot 368

class sfq 2:168 parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 16654b 11p requeues 0
allot 368

class sfq 2:1c8 parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 22710b 15p requeues 0
allot -704

class sfq 2:2fd parent 2:
(dropped 0, overlimits 0 requeues 0)
backlog 12112b 8p requeues 0
allot 0

 

tc -s -d class show dev ipoe1
class htb 1:1 root leaf 2: prio 0 quantum 1500 rate 30000Kbit ceil 30000Kbit burst 1875Kb/8 mpu 0b overhead 0b cburst 306795b/8 mpu 0b overhead 0b level 0
Sent 683632461 bytes 467648 pkt (dropped 19272, overlimits 0 requeues 0)
rate 96648bit 30pps backlog 0b 0p requeues 0
lended: 450350 borrowed: 0 giants: 0
tokens: 7998875 ctokens: 1277203

 

tc -s filter show dev ipoe1 parent ffff:
filter protocol ip pref 100 u32
filter protocol ip pref 100 u32 fh 800: ht divisor 1
filter protocol ip pref 100 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid :1  (rule hit 322240 success 322240)
 match 00000000/00000000 at 0 (success 322240 )
       action order 1:  skbedit priority :713 installed 542 sec used 0 sec     Action statistics:
       Sent 45995378 bytes 322240 pkt (dropped 0, overlimits 0 requeues 0)
       backlog 0b 0p requeues 0

       action order 2: mirred (Egress Redirect to device ifb0) stolen
       index 194 ref 1 bind 1 installed 542 sec used 0 sec
       Action statistics:
       Sent 45995378 bytes 322240 pkt (dropped 0, overlimits 2 requeues 0)
       backlog 0b 0p requeues 0

 

attr=Filter-Id
#attr-up=
#attr-down=
#burst-factor=2
down-burst-factor=0.512
#up-burst-factor=1.0
#latency=50
#mpu=0
#mtu=0
r2q=12
quantum=1500
#moderate-quantum=1
#cburst=1534
cburst=306800
ifb=ifb0
up-limiter=htb
down-limiter=htb
leaf-qdisc=sfq perturb 10
#leaf-qdisc=fq_codel [limit PACKETS] [flows NUMBER] [target TIME] [interval TIME] [quantum BYTES] [[no]ecn]
#leaf-qdisc=fq_codel
#rate-multiplier=1
#fwmark=1
verbose=100

Edited by hsvt

Share this post


Link to post
Share on other sites

К слову, у кого там сервера на 4.1.12 и новее крашились быстро (часы/сутки) - есть возможность попробовать ядро, пропатченное этим патчем?

Share this post


Link to post
Share on other sites

ну у меня краши - редкие, что-то с уверенностью можно будет сказать только через несколько недель. потому и попросил потестить. в тесткейсе (1000 реконнектящихся пппое сессий) падать перестало.

Share this post


Link to post
Share on other sites

Я на 3,16 примерил из интереса, патч не совсем гладко вписывается.

Этой строки нет.

-	INIT_WORK(&po->proto.pppoe.padt_work, pppoe_unbind_sock_work);

Share this post


Link to post
Share on other sites

На 3.16 не примерится, баг который фиксится всплыл после 3.18

Share this post


Link to post
Share on other sites

Я один из двух крашащихся брасов перевел на 3.14, он уже 8 дней пока прожил, второй на днях буду запускать на 4.1.13, там и попробую патч, заодно и новый accel 1.10.0 проверю :)

Share this post


Link to post
Share on other sites

Меня замучал один нас с ядром 4 ветки, мог работать неделю сутки или час. В итоге накатил на него рабочую копию сервера с ядром 3.3.8 работает без проблем.

Share this post


Link to post
Share on other sites

Все эти патчи и ядра не имеют никакого отношения к accel-ppp. Давайте уже перенесем обсуждения в соседнюю ветку, Linux softrouter.

Share this post


Link to post
Share on other sites

На 3.16 не примерится, баг который фиксится всплыл после 3.18

Значит на 3.16 тоже какая-то иная проблема, зачем вообще трогали pppoe.c

если всё хорошо работало многие годы.

Share this post


Link to post
Share on other sites

К слову, у кого там сервера на 4.1.12 и новее крашились быстро (часы/сутки) - есть возможность попробовать ядро, пропатченное этим патчем?

Давайте обсудим патчик.

Откуда он, если не секрет?

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

Например:

- if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {

+ if (po->pppoe_dev) {

Это отсюда https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=e3e62cc7abb53bc0317be8b3a0ba98b36768630d

Но почему не взяли это https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a2a46f5816a863b33e79e1fecb74e06422350cfd ???

 

Что дает перенос наверх INIT_WORK(&po->proto.pppoe.padt_work, pppoe_unbind_sock_work); с легким изменением???

Что дает переписывание функции memset(sk_pppox(po) + 1, 0, sizeof(struct pppox_sock) - sizeof(struct sock)); ???

Share this post


Link to post
Share on other sites

К слову, у кого там сервера на 4.1.12 и новее крашились быстро (часы/сутки) - есть возможность попробовать ядро, пропатченное этим патчем?

Давайте обсудим патчик.

Откуда он, если не секрет?

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

Например:

- if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {

+ if (po->pppoe_dev) {

Это отсюда https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=e3e62cc7abb53bc0317be8b3a0ba98b36768630d

Но почему не взяли это https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a2a46f5816a863b33e79e1fecb74e06422350cfd ???

 

Что дает перенос наверх INIT_WORK(&po->proto.pppoe.padt_work, pppoe_unbind_sock_work); с легким изменением???

Что дает переписывание функции memset(sk_pppox(po) + 1, 0, sizeof(struct pppox_sock) - sizeof(struct sock)); ???

 

Автор патча написал:

I confirm the bug comes from this commit.

 

It happens if pppoe_connect() reinitialises po->proto.pppoe.padt_work

after pppoe_disc_rcv() has added it to the system's work queue, and

before that work got scheduled. Then when scheduling occurs, the worker

thread tries to run a corrupted structure and crashes.

Share this post


Link to post
Share on other sites

Откуда он, если не секрет?

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

Угу. 2 патчика в одном. Один - поправить баг в pppoe_release, второй - правит падения при массовом реконнекте (тесткейс - 1000+ пппое клиентов на машине, ломящихся с неверным паролем на брас, вызывали кернел паник на клиенте в течение 10-15 секунд), из net-next.

 

Но почему не взяли это https://git.kernel.o...b74e06422350cfd ???

в 4.1.13 (или 12?) он уже включен.

Share this post


Link to post
Share on other sites

А какой баг исправлялся введением этого INIT_WORK? В 3.10.0 его нет.

 

Судя по описанию была какая-то проблема с обработкой PADT сообщений и в качестве временного решения сервер при получении такого пакета переставал передавать трафик. Вызывало ли это реальные проблемы у пользователей, учитывая что PADT посылался при отключении?

 

Получается бага при массовом подключении в нем также нет и нужно применить только фиксы для pppoe_release?

 

Кстати, раньше сервер крашился после примерно недели работы (последний раз по soft lockup на fib_table_flush) на 3.10.0 с первым фиксом для pppoe_release, но после того как автор посоветовал включить unit-cache - крашиться перестал и аптайм уже почти 2 месяца.

Edited by avb1987

Share this post


Link to post
Share on other sites

А какой баг исправлялся введением этого INIT_WORK? В 3.10.0 например его нет.

баг который фиксится всплыл после 3.18

 

Получается бага при массовом подключении в нем также нет и нужно применить только фиксы для pppoe_release?

не могу сказать, что в нем есть и чего нет. какая-то грабля при удалении шейпера в ip-down при опускании интерфейса 100% есть в 3.14. в остальном - особо эти ядра не щупал.

Share this post


Link to post
Share on other sites

Учитывая то, какой существует зоопарк багов связанных с PPPoE во всех ядрах, нужно наверное определить и сделать наименее глючную рекомендуемую версию :)

Share this post


Link to post
Share on other sites

Дык писали уже: 3.2 стабильная, хоть и неторопливая. 3.4 возможно тоже.

 

Но лучше в netdev писать о багах. С трейсами и местом где падает (gdb <module>.o и list *<func>+0x<offset>). Больше толку.

Share this post


Link to post
Share on other sites

Пытаюсь собрать ipoe-драйвер на Gentoo Linux. Получаю следующее:

 

/var/tmp/portage/net-dialup/accel-ppp-1.10.0/work/accel-ppp-1.10.0_build/drivers/ipoe/driver/ipoe.c: In function ‘ipoe_xmit’:

/var/tmp/portage/net-dialup/accel-ppp-1.10.0/work/accel-ppp-1.10.0_build/drivers/ipoe/driver/ipoe.c:445:5: error: ‘struct sk_buff’ has no member named ‘tc_verd’

skb->tc_verd = SET_TC_NCLS(0);

^

 

На ядрах 4.0.9 и 4.3.0 - ошибка та же. Как я понимаю поменялась структура в ядре, но когда именно(в какой версии) - затрудняюсь сказать - спец по ядру из меня никакой.

Edited by Pinkbyte

Share this post


Link to post
Share on other sites

Пытаюсь собрать ipoe-драйвер на Gentoo Linux. Получаю следующее:

 

/var/tmp/portage/net-dialup/accel-ppp-1.10.0/work/accel-ppp-1.10.0_build/drivers/ipoe/driver/ipoe.c: In function ‘ipoe_xmit’:

/var/tmp/portage/net-dialup/accel-ppp-1.10.0/work/accel-ppp-1.10.0_build/drivers/ipoe/driver/ipoe.c:445:5: error: ‘struct sk_buff’ has no member named ‘tc_verd’

skb->tc_verd = SET_TC_NCLS(0);

^

 

На ядрах 4.0.9 и 4.3.0 - ошибка та же. Как я понимаю поменялась структура в ядре, но когда именно(в какой версии) - затрудняюсь сказать - спец по ядру из меня никакой.

 

Я думаю не стоит еще использовать ветку 1.10.0, лучше 1.9

 

git clone -b 1.9 git://git.code.sf.net/p/accel-ppp/code accel-ppp.git

 

Edited by Dimka88

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now