accel pptpd

Ivan Rostovikov

Опубликовано 4 апреля, 2011 (изменено) · Жалоба

Насколько я понимаю у меня тоже самое:

# dpkg -S libcrypto.a
libssl-dev: /usr/lib/libcrypto.a

# dpkg -L libssl-dev | grep crypto

/usr/lib/pkgconfig/libcrypto.pc

/usr/lib/libcrypto.a

/usr/share/man/man3/ERR_load_crypto_strings.3ssl.gz

/usr/share/man/man3/crypto.3ssl.gz

/usr/include/openssl/crypto.h

/usr/lib/libcrypto.so

# ls -la /usr/lib/libcrypto.so

lrwxrwxrwx 1 root root 18 Мар 31 10:32 /usr/lib/libcrypto.so -> libcrypto.so.0.9.8

# ls -la /usr/lib/libcrypto.so.0.9.8

-rw-r--r-- 1 root root 1693312 Фев 10 22:20 /usr/lib/libcrypto.so.0.9.8

# ls -la /usr/lib/libcrypto.a

rw-r--r-- 1 root root 3421782 Фев 10 22:20 /usr/lib/libcrypto.a

Однако "cannot find -lcrypto".

debian squeeze 2.6.38.2 x86_64

Изменено 4 апреля, 2011 пользователем Ivan Rostovikov

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

DrakoN

Опубликовано 4 апреля, 2011 (изменено) · Жалоба

# dpkg -L libssl-dev | grep crypto

/usr/lib/pkgconfig/libcrypto.pc

Тогда должно быть:

# pkg-config --variable pc_path pkg-config

/usr/local/lib/pkgconfig:/usr/local/lib/pkgconfig/i486-linux-gnu:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/lib/pkgconfig/i486-linux-gnu:/usr/share/pkgconfig

Изменено 4 апреля, 2011 пользователем DrakoN

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Ivan Rostovikov

Опубликовано 5 апреля, 2011 · Жалоба

# pkg-config --variable pc_path pkg-config
/usr/local/lib/pkgconfig:/usr/local/lib/pkgconfig/x86_64-linux-gnu:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/lib/pkgconfig/x86_64-linux-gnu:/usr/share/pkgconfig

Может дело в том, что у меня x86_64 ?

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

lan-viper

Опубликовано 6 апреля, 2011 · Жалоба

Прошу помощи. Имею следующую проблему, при перезагрузке/выключении сервера, когда система начинает удалять vlan интерфейсы, то в консоли вижу:

Removed VLAN -:vlan1:-
[   138.352005]  unregister_netdevice: waiting for vlan10 to become free. Usage count = 1
...

и так пока питание на сервер не отрубишь.

Софт на сервере: debian squeeze, accel-ppp 1.3.5 (включены все поддерживаемые протоколы: pptp, pppoe и l2tp).

Конфигурация тестовой сети: на сервер заведён транк с центрального L3 свича. vlan1 - полноценный внутрисетевой интерфейс, vlan10, vlan40, ... - интерфейсы в режиме promisc пользовательских подсетей, на которых слушает pppoe часть accel-ppp.

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

С остальными типами vpn проблем нет.

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

nuclearcat

Опубликовано 6 апреля, 2011 · Жалоба

Прошу помощи. Имею следующую проблему, при перезагрузке/выключении сервера, когда система начинает удалять vlan интерфейсы, то в консоли вижу:
Removed VLAN -:vlan1:-
[   138.352005]  unregister_netdevice: waiting for vlan10 to become free. Usage count = 1
...
и так пока питание на сервер не отрубишь.

Софт на сервере: debian squeeze, accel-ppp 1.3.5 (включены все поддерживаемые протоколы: pptp, pppoe и l2tp).

Конфигурация тестовой сети: на сервер заведён транк с центрального L3 свича. vlan1 - полноценный внутрисетевой интерфейс, vlan10, vlan40, ... - интерфейсы в режиме promisc пользовательских подсетей, на которых слушает pppoe часть accel-ppp.

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

С остальными типами vpn проблем нет.

Только апить ядро, это глюк ядра.

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

lan-viper

Опубликовано 6 апреля, 2011 (изменено) · Жалоба

Нет, только что собрал и установил стоковое дебиановское 2.6.37 (было на 2.6.32 патченом всякой всячиной), та же борода...

Завтра попробую обкатанный мною pppoe-server в kernel-mode, сравню.

Жалко, если pppoe не заведётся на accel-ppp, удобно всё в одном месте держать, прям как mpd фряшный.

Изменено 6 апреля, 2011 пользователем lan-viper

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

a_andry

Опубликовано 7 апреля, 2011 · Жалоба

Можно напомнить?

получили с радиуса E=1315, а отдали клиенту E=691. Более и менее понятные ошибки снижают немного нагрузку на сапорт ... можно их передавать дальше без изменения?
ок

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

lan-viper

Опубликовано 7 апреля, 2011 (изменено) · Жалоба

Завтра попробую обкатанный мною pppoe-server в kernel-mode, сравню.

Отписываю результаты экспериментов:

1. Ядерный pppoe-server работает исправно на этих vlan-ах;

2. Попробовал без vlan-ов, на чистом eth0 - данная проблема отсутствует!

Предварительные выводы: либо некорректно обрабатывается декримент счётчика ссылок на интерфейсы (в интернетах чаще всего упоминаются какой то счётчик интерфейсов в структурах ядра) в ядерном модуле pppoe, либо проблемы в работе подсистемы pppoe в самом accel-ppp, что маловероятно.

Знающие админы/программисты, помогите, где собака порылась, как этот баг отловить. Со своей стороны могу оказать активное содействие в поисках решения проблемы. Самое главное, повторится ли эта проблема у кого-нибудь ещё?

UPD:

Неповезло мне: https://bugzilla.kernel.org/show_bug.cgi?id=16611

Изменено 7 апреля, 2011 пользователем lan-viper

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

lan-viper

Опубликовано 7 апреля, 2011 (изменено) · Жалоба

не знаю, перепробовал все варианты включая аварийное завершение, указанный баг воспроизвести не удаётся

accel-ppp version d7efa14d50976995b1e6c8b43f0a110767bf7661

Linux book2 2.6.37-gentoo #1 SMP Sun Feb 13 23:26:55 MSK 2011 x86_64 Intel® Core™ i5 CPU M 450 @ 2.40GHz GenuineIntel GNU/Linux

эта ситуёвина возникает именно при удалении вилана т. е. при выполнении команды

vconfig rem $INTERFACE

в моём дистре (оупенсюзя 11.3) эта команда в конечном итоге выполняется в скриптах дауна сетевого ифейса, если это вилан. Я обошёл это, заменив её на

ip l s $INTERFACE down

т. е. вилан даунится но не удаляется

Прочёл тему с начала февраля, 100% совпадение всего, что писал aran.

/etc/network/if-post-down.d/vlan

...
#vconfig rem $IFACE
ip link set $IFACE down

бляха-муха, больше ничего не остаётся...

Изменено 7 апреля, 2011 пользователем lan-viper

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Dethman

Опубликовано 7 апреля, 2011 (изменено) · Жалоба

Доброе время суток.

есть необходимость убивать ppp из скрипта на сервере, т.е. например ifdown ppp10 должно отключать этот самый ppp10

есть разумные решения кроме нарисованного ниже ?

#!/bin/sh

accel_addr=127.0.0.1

accel_port=2001

ifname=$1

echo -en "terminate if ${ifname}" | netcat -t ${accel_addr} ${accel_port}

Изменено 7 апреля, 2011 пользователем Dethman

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Vofffka

Опубликовано 7 апреля, 2011 (изменено) · Жалоба

Версия 1.3.5 падает с ошибками:

[ 3754.022480] accel-pppd[6990]: segfault at 20 ip 00007fa7c8d5d750 sp 00007fff787a9110 error 4 in libtriton.so[7fa7c8d59000+8000]

[ 4022.973460] accel-pppd[19738]: segfault at 70 ip 00007f00a50e4750 sp 00007fff59c9c2a0 error 4 in libtriton.so[7f00a50e0000+8000]

[13970.239684] accel-pppd[7597]: segfault at c8 ip 00007f030b6bedfc sp 00007f0304a4a470 error 4 in libc-2.11.2.so[7f030b64d000+158000]

Последний билд из git тоже падает:

[15121.198780] accel-pppd[9940] general protection ip:7f872b576750 sp:7fffe1774eb0 error:0 in libtriton.so[7f872b572000+8000]

[16738.736240] accel-pppd[29830]: segfault at 50 ip 0000000000406484 sp 00007f17d3126d60 error 4 in accel-pppd[400000+17000]

error 4 это чтение по адресу 0?

ситема Debian 6.0.1. ядро 2.6.32-5-amd64

сделал objdump -d accel-pppd. вот кусок кода там где падает:

0000000000406410 <lcp_layer_free>:

406410: 55 push %rbp

406411: 31 c0 xor %eax,%eax

406413: 53 push %rbx

406414: 48 89 fb mov %rdi,%rbx

406417: 48 8d 3d f8 c1 00 00 lea 0xc1f8(%rip),%rdi # 412616 <_IO_stdin_used+0x54e>

40641e: 48 83 ec 08 sub $0x8,%rsp

406422: e8 e9 a5 00 00 callq 410a10 <log_ppp_debug>

406427: 48 83 bb 18 01 00 00 cmpq $0x0,0x118(%rbx)

40642e: 00

40642f: 74 0c je 40643d <lcp_layer_free+0x2d>

406431: 48 8d bb 18 01 00 00 lea 0x118(%rbx),%rdi

406438: e8 ab ce ff ff callq 4032e8 <triton_timer_del@plt>

40643d: 48 8b bb 00 01 00 00 mov 0x100(%rbx),%rdi

406444: 48 8d 73 28 lea 0x28(%rbx),%rsi

406448: 48 8d ab 08 01 00 00 lea 0x108(%rbx),%rbp

40644f: e8 6c d5 ff ff callq 4039c0 <ppp_unregister_handler>

406454: 48 8b b3 08 01 00 00 mov 0x108(%rbx),%rsi

40645b: 48 39 f5 cmp %rsi,%rbp

40645e: 74 33 je 406493 <lcp_layer_free+0x83>

406460: 48 8b 46 08 mov 0x8(%rsi),%rax

406464: 48 8b 16 mov (%rsi),%rdx

406467: 48 89 df mov %rbx,%rdi

40646a: 48 89 42 08 mov %rax,0x8(%rdx)

40646e: 48 89 10 mov %rdx,(%rax)

406471: 48 8b 46 20 mov 0x20(%rsi),%rax

406475: 48 c7 06 00 00 00 00 movq $0x0,(%rsi)

40647c: 48 c7 46 08 00 00 00 movq $0x0,0x8(%rsi)

406483: 00

406484: ff 50 50 callq *0x50(%rax)

406487: 48 8b b3 08 01 00 00 mov 0x108(%rbx),%rsi

40648e: 48 39 ee cmp %rbp,%rsi

406491: 75 cd jne 406460 <lcp_layer_free+0x50>

406493: 48 8d 7b 50 lea 0x50(%rbx),%rdi

406497: e8 c4 ea ff ff callq 404f60 <ppp_fsm_free>

40649c: 48 8b 83 00 01 00 00 mov 0x100(%rbx),%rax

4064a3: 48 8d 35 f6 fb ff ff lea -0x40a(%rip),%rsi # 4060a0 <_lcp_layer_finished>

libtriton.so падает в функции triton_terminate по смещению 0x4750:

471b: f0 41 83 46 18 01 lock addl $0x1,0x18(%r14)

4721: e9 3a ff ff ff jmpq 4660 <triton_terminate+0x40>

4726: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)

472d: 00 00 00

4730: 48 8d 3d 89 2f 20 00 lea 0x202f89(%rip),%rdi # 2076c0 <ctx_list_lock>

4737: 48 8d 2d 12 2e 20 00 lea 0x202e12(%rip),%rbp # 207550 <threads>

473e: e8 f5 df ff ff callq 2738 <pthread_mutex_unlock@plt>

4743: 48 8b 1d 06 2e 20 00 mov 0x202e06(%rip),%rbx # 207550 <threads>

474a: 48 39 eb cmp %rbp,%rbx

474d: 74 14 je 4763 <triton_terminate+0x143>

474f: 90 nop

4750: 48 8b 7b 20 mov 0x20(%rbx),%rdi

4754: 31 f6 xor %esi,%esi

4756: e8 3d e0 ff ff callq 2798 <pthread_join@plt>

475b: 48 8b 1b mov (%rbx),%rbx

475e: 48 39 eb cmp %rbp,%rbx

4761: 75 ed jne 4750 <triton_terminate+0x130>

4763: 31 c0 xor %eax,%eax

4765: e8 26 e4 ff ff callq 2b90 <md_terminate>

если смотреть в коде:

void __export triton_terminate()

{

struct _triton_context_t *ctx;

struct _triton_thread_t *t;

int r;

need_terminate = 1;

spin_lock(&ctx_list_lock);

list_for_each_entry(ctx, &ctx_list, entry) {

spin_lock(&ctx->lock);

ctx->need_close = 1;

r = triton_queue_ctx(ctx);

if ®

triton_thread_wakeup(ctx->thread);

spin_unlock(&ctx->lock);

}

spin_unlock(&ctx_list_lock);

list_for_each_entry(t, &threads, entry)

pthread_join(t->thread, NULL);

md_terminate();

timer_terminate();

}

то падает t->thread перед вызовом pthread_join. похоже указатель t - неверный

Изменено 7 апреля, 2011 пользователем Vofffka

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Mihalych

Опубликовано 7 апреля, 2011 (изменено) · Жалоба

Такая же фигня, третий день бьюсь ))))

NAS на Gentoo недельной сборки

Linux pppoe 2.6.36-gentoo-r8 #9 SMP Sat Apr 9 00:32:57 MSD 2011 x86_64 Intel® Core i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux

+ UTM на другом серваке.

По логам на UTM авторизация проходит, а вот на NAS accel чего-то не хочет ip выдавать.

Ассel ставил из git. accel-ppp version 859b328684c41f2ffdb0f14b0c480dad0075ef50

На UTM:

?Debug : Apr 08 02:49:08 RADIUS DBA: NAS found. Data size <0>

?Debug : Apr 08 02:49:08 AuthServer: Packet from <10.62.17.254> packet dump: RPacket:

Code: 1; ID: 1

<Vendor: 0; Attr: 1>[6]: 76696b746f72

<Vendor: 0; Attr: 4>[4]: 0a3e11fe

<Vendor: 0; Attr: 5>[4]: 00000000

<Vendor: 0; Attr: 6>[4]: 00000002

<Vendor: 0; Attr: 7>[4]: 00000001

<Vendor: 0; Attr: 30>[17]: 30303a31623a32313a38633a62633a6138

<Vendor: 0; Attr: 31>[17]: 30303a31393a36363a38613a32633a6638

<Vendor: 0; Attr: 32>[9]: 616363656c2d707070

<Vendor: 0; Attr: 61>[4]: 00000005

<Vendor: 311; Attr: 11>[16]: b74e689476e5c2c5f467539bf45aba70

<Vendor: 311; Attr: 25>[50]: 0100804205f6f2168fdef74b85e1a67c3774000000000000000017bc2613176f1046dc869521e5fef45c7a2146a899434c4d

?Debug : Apr 08 02:49:08 AuthServer: User <viktor> connecting

?Debug : Apr 08 02:49:08 AuthServer: Session for sessionid <viktor> not found in <10.62.17.254> cache

?Debug : Apr 08 02:49:08 RADIUS DBA: Info for login <viktor> found. type <1>

?Debug : Apr 08 02:49:08 AuthServer: Auth scheme: MS-CHAPv2

?Debug : Apr 08 02:49:08 AuthServer: MS-CHAPv2: Authorized user <viktor>

?Debug : Apr 08 02:49:08 AuthServer: MS-CHAPv2: MPPE Keys send

?Debug : Apr 08 02:49:08 RADIUS IPPool: Dropped on timeout: 0x0a01410c

?Debug : Apr 08 02:49:08 AuthServer: IP claimed: 0xa01410c (<10.1.65.12>)

?Debug : Apr 08 02:49:08 AuthServer: Calling fill radius attributes for service. Attr storage size <0>

?Debug : Apr 08 02:49:08 AuthServer: Calling fill radius attributes for slink. Attr storage size <0>

?Debug : Apr 08 02:49:08 AuthServer: Calling fill radius attributes for NAS. Attr storage size <0>

Notice: Apr 08 02:49:08 AuthServer: Login OK <viktor> from NAS <10.62.17.254> CLID <00:1b:21:8c:bc:a8> Calling-station <00:19:66:8a:2c:f8>

?Debug : Apr 08 02:49:08 AuthServer: Setting interim update interval from config

?Debug : Apr 08 02:49:08 AuthServer: Auth reply: RPacket:

На NASе:

accel-ppp.log:

info: ppp0: connect: ppp0 <--> pppoe(00:19:66:8a:2c:f8)

info: ppp0: send [RADIUS Access-Request id=1 <User-Name "viktor"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.62.17.254> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:19:66:8a:2c:f8"> <Called-Station-Id "00:1b:21:8c:bc:a8"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]

info: ppp0: recv [RADIUS Access-Accept id=1 <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-IP-Address 10.1.65.12> <Framed-IP-Netmask 255.255.255.255> <Session-Timeout 86400><Microsoft MS-MPPE-Encryption-Policy 1><Microsoft MS-MPPE-Encryption-Type 6><Microsoft MS-MPPE-Send-Key ><Microsoft MS-MPPE-Recv-Key ><Microsoft MS-CHAP2-Success >]

и /var/log/messages:

pppoe kernel: [ 7839.909349] accel-pppd[5789] general protection ip:7f645b626870 sp:7f6457e5e458 error:0 in ld-2.11.2.so[7f645b613000+1e000]

pppoe kernel: [ 7839.961245] netconsole: network logging stopped, interface ppp0 unregistered

P.S. Посмотрел лог установки, всё без ошибок, кроме этого:

* QA Notice: make jobserver unavailable:

*

* make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.

strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment

Изменено 12 апреля, 2011 пользователем Mihalych

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ShumBor

Опубликовано 11 апреля, 2011 · Жалоба

Что-то не смог подключить dlink DVG-7111S к accel-pppd (версия 859b328684c41f2ffdb0f14b0c480dad0075ef50)

Что по l2tp что по pptp отказался подключаться.

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

_longhorn_

Опубликовано 16 апреля, 2011 · Жалоба

moose

Сам на днях столкнулся. Нужно libnl2.

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Abram

Опубликовано 17 апреля, 2011 · Жалоба

есть разумные решения кроме нарисованного ниже ?

CoA/PoD.

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Mihalych

Опубликовано 18 апреля, 2011 (изменено) · Жалоба

Рано я начал радоваться.... рррое заработал, а вот рртр не хочет.

filename: /lib/modules/2.6.36-gentoo-r8/extra/pptp.ko

license: GPL

author: Kozlov D. (xeb@mail.ru)

description: Point-to-Point Tunneling Protocol for Linux

depends:

vermagic: 2.6.36-gentoo-r8 SMP mod_unload

parm: log_packets:int

parm: log_level:Logging level (default=0) (int)

Вот лог:

pptp: new connection from 10.62.17.12

: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

: : recv [PPTP Outgoing-Call-Request <Call-ID 8000> <Call-Serial fdb1> <Min-BPS 300> <Max-BPS 100000000> <Bearer 3> <Framing 3> <Window-Size 64> <Delay 0>]

: : send [PPTP Outgoing-Call-Reply <Call-ID 2> <Peer-Call-ID 8000> <Result 1> <Error 0> <Cause 0> <Speed 100000000> <Window-Size 64> <Delay 0> <Channel 0>]

ppp0: 1d2f01c080edd5fa: connect: ppp0 <--> pptp(10.62.17.12)

ppp0: 1d2f01c080edd5fa: lcp_layer_init

ppp0: 1d2f01c080edd5fa: auth_layer_init

ppp0: 1d2f01c080edd5fa: ccp_layer_init

ppp0: 1d2f01c080edd5fa: ipcp_layer_init

ppp0: 1d2f01c080edd5fa: ppp established

ppp0: 1d2f01c080edd5fa: lcp_layer_start