Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Михаил Касаджиков]

Anton Gorlov  писал(а) в своём письме Wed, 28 Jun 2017 
23:28:28 +0300:


28.06.2017 11:13, Михаил Касаджиков пишет:


Это дело стало необходимым потому что то ли в свежих ядрах, то ли в
дебиане (давно копал) теперь nat_helpers не применяются без явного на то
указания.


В ядрах..Вернее в таблесах автомат сделали депрекейтед.


Тогда точно нужно переходить на правила в iptables.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Eugene Berdnikov]

On Wed, Jun 28, 2017 at 10:09:49PM +0300, Andrey Tataranovich wrote:
> On Wed, 28 Jun 2017 13:53:51 +0300
> Eugene Berdnikov  wrote:
>  
> >  А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает?
> 
> Помогает.

 Тогда его в /etc/sysctl.conf.
-- 
 Eugene Berdnikov

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Andrey Tataranovich]

On Wed, 28 Jun 2017 11:13:18 +0300
Михаил Касаджиков <ha...@h13online.net> wrote:

> Добавьте в iptables в таблицу raw правило для использования pptp:
> 
> root@debby2: ~# iptables-save -t raw
> # Generated by iptables-save v1.6.0 on Wed Jun 28 11:08:40 2017
> *raw
> :PREROUTING ACCEPT [499445987:251052699965]
> :OUTPUT ACCEPT [118702475:62694078445]
> -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp
> COMMIT
> # Completed on Wed Jun 28 11:08:40 2017
> 
> Это дело стало необходимым потому что то ли в свежих ядрах, то ли в
> дебиане (давно копал) теперь nat_helpers не применяются без явного на
> то указания.

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

sysctl -w net.netfilter.nf_conntrack_helper=1

-- 
WBR, Andrey Tataranovich

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Andrey Tataranovich]

On Wed, 28 Jun 2017 13:53:51 +0300
Eugene Berdnikov  wrote:
 
>  А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает?

Помогает.

-- 
WBR, Andrey Tataranovich

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Михаил Касаджиков]

Eugene Berdnikov <b...@protva.ru> писал(а) в своём письме Wed, 28 Jun 2017 
13:53:51 +0300:


On Wed, Jun 28, 2017 at 11:13:18AM +0300, Михаил Касаджиков wrote:

Andrey Tataranovich <tataranov...@gmail.com> писал(а) в своём письме Tue, 27 
Jun 2017 20:04:29 +0300:
>Может кто-то знает что нужно подкрутить в новом ядре чтобы начал
>правильно работать NAT?
>

Добавьте в iptables в таблицу raw правило для использования pptp:

...

Это дело стало необходимым потому что то ли в свежих ядрах, то ли в
дебиане (давно копал) теперь nat_helpers не применяются без явного
на то указания.


 А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает?


Хм… Я, когда это дело начиналось, прочитал что теперь включать настраивать эти 
помощники нужно не параметрами модулей, а через raw-CT и что так оно 
рекомендовано. И с тех пор указываю порт и модуль явно. А в sysctl заглянуть и 
забыл. Но, думаю, sysctl тоже должен помочь.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Eugene Berdnikov]

On Wed, Jun 28, 2017 at 11:13:18AM +0300, Михаил Касаджиков wrote:
> Andrey Tataranovich <tataranov...@gmail.com> писал(а) в своём письме Tue, 27 
> Jun 2017 20:04:29 +0300:
> >Может кто-то знает что нужно подкрутить в новом ядре чтобы начал
> >правильно работать NAT?
> >
> 
> Добавьте в iptables в таблицу raw правило для использования pptp:
...
> Это дело стало необходимым потому что то ли в свежих ядрах, то ли в
> дебиане (давно копал) теперь nat_helpers не применяются без явного
> на то указания.

 А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает?
-- 
 Eugene Berdnikov

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Михаил Касаджиков]

Andrey Tataranovich <tataranov...@gmail.com> писал(а) в своём письме Tue, 27 
Jun 2017 20:04:29 +0300:


Доброго времени суток.

Имеется сервер на Debian Jessie, который служит маршрутизатором сети.

После апгрейдом ядра со штатного linux-image-3.16.0-4-amd64
(3.16.43-2+deb8u1) до linux-image-4.9.0-0.bpo.3-amd64 (4.9.30-2~bpo8+1)
у клиентов сломалось подключение через pptp. Пробовал обновиться до
linux-image-4.11.0-1-amd64 (4.11.6-1) из unstable, но ничего не
поменялось.

PPTP начинает работать, если перезагрузить маршрутизатор обратно на
3.16.43-2+deb8u1. Ввиду предстоящего апгрейда на stretch мне не хочется
откатываться на старое ядро, да и маловероятно, что в ядре что-то
глобально сломали - скорее всего я что-то упускаю относительно настроек.

Когда pptp НЕ работает:

$ sudo conntrack -L -p 47
gre  47 29 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0x285d
[UNREPLIED] src=y.y.y.y dst=z.z.z.z srckey=0x285d dstkey=0x0 mark=0
use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been
shown.

Когда pptp работает:
$ sudo conntrack -L -p 47
gre  47 17995 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0xbe6f
src=y.y.y.y dst=z.z.z.z srckey=0xbe6f dstkey=0xc6ad [ASSURED] mark=0
use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been
shown.

x.x.x.x - локальный адрес клиента
y.y.y.y - адрес VPN сервера
z.z.z.z - внешний адрес маршрутизатора

Может кто-то знает что нужно подкрутить в новом ядре чтобы начал
правильно работать NAT?



Добавьте в iptables в таблицу raw правило для использования pptp:

root@debby2: ~# iptables-save -t raw
# Generated by iptables-save v1.6.0 on Wed Jun 28 11:08:40 2017
*raw
:PREROUTING ACCEPT [499445987:251052699965]
:OUTPUT ACCEPT [118702475:62694078445]
-A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp
COMMIT
# Completed on Wed Jun 28 11:08:40 2017

Это дело стало необходимым потому что то ли в свежих ядрах, то ли в дебиане 
(давно копал) теперь nat_helpers не применяются без явного на то указания.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Andrey Tataranovich]

On Wed, 28 Jun 2017 00:07:14 +0700
Леонид Кальмаев <kalmae...@gmail.com> wrote:

> Так а модуль то загружен pptp для того чтобы впн через нат полазил?

$ grep pptp /etc/modules
nf_nat_pptp
nf_conntrack_pptp

Насколько я знаю только эти два модуля нужны для работы pptp через NAT.

$ lsmod | grep pptp
nf_nat_pptp16384  0 
nf_nat_proto_gre   16384  1 nf_nat_pptp
nf_conntrack_pptp  16384  1 nf_nat_pptp
nf_conntrack_proto_gre16384  1 nf_conntrack_pptp
nf_nat 28672  4
nf_nat_pptp,nf_nat_proto_gre,nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack  135168  11
nf_nat_pptp,nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_conntrack_pptp,nf_conntrack_netlink,nf_conntrack_proto_gre,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat

И эти модули загружены в ядро.

-- 
WBR, Andrey Tataranovich

Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Леонид Кальмаев]

Так а модуль то загружен pptp для того чтобы впн через нат полазил?

28 июн. 2017 г. 12:04 ДП пользователь "Andrey Tataranovich" <
tataranov...@gmail.com> написал:

> Доброго времени суток.
>
> Имеется сервер на Debian Jessie, который служит маршрутизатором сети.
>
> После апгрейдом ядра со штатного linux-image-3.16.0-4-amd64
> (3.16.43-2+deb8u1) до linux-image-4.9.0-0.bpo.3-amd64 (4.9.30-2~bpo8+1)
> у клиентов сломалось подключение через pptp. Пробовал обновиться до
> linux-image-4.11.0-1-amd64 (4.11.6-1) из unstable, но ничего не
> поменялось.
>
> PPTP начинает работать, если перезагрузить маршрутизатор обратно на
> 3.16.43-2+deb8u1. Ввиду предстоящего апгрейда на stretch мне не хочется
> откатываться на старое ядро, да и маловероятно, что в ядре что-то
> глобально сломали - скорее всего я что-то упускаю относительно настроек.
>
> Когда pptp НЕ работает:
>
> $ sudo conntrack -L -p 47
> gre  47 29 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0x285d
> [UNREPLIED] src=y.y.y.y dst=z.z.z.z srckey=0x285d dstkey=0x0 mark=0
> use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been
> shown.
>
> Когда pptp работает:
> $ sudo conntrack -L -p 47
> gre  47 17995 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0xbe6f
> src=y.y.y.y dst=z.z.z.z srckey=0xbe6f dstkey=0xc6ad [ASSURED] mark=0
> use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been
> shown.
>
> x.x.x.x - локальный адрес клиента
> y.y.y.y - адрес VPN сервера
> z.z.z.z - внешний адрес маршрутизатора
>
> Может кто-то знает что нужно подкрутить в новом ядре чтобы начал
> правильно работать NAT?
>
> --
> WBR, Andrey Tataranovich
>
>

Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT

[Andrey Tataranovich]

Доброго времени суток.

Имеется сервер на Debian Jessie, который служит маршрутизатором сети.

После апгрейдом ядра со штатного linux-image-3.16.0-4-amd64
(3.16.43-2+deb8u1) до linux-image-4.9.0-0.bpo.3-amd64 (4.9.30-2~bpo8+1)
у клиентов сломалось подключение через pptp. Пробовал обновиться до
linux-image-4.11.0-1-amd64 (4.11.6-1) из unstable, но ничего не
поменялось.

PPTP начинает работать, если перезагрузить маршрутизатор обратно на
3.16.43-2+deb8u1. Ввиду предстоящего апгрейда на stretch мне не хочется
откатываться на старое ядро, да и маловероятно, что в ядре что-то
глобально сломали - скорее всего я что-то упускаю относительно настроек.

Когда pptp НЕ работает:

$ sudo conntrack -L -p 47
gre  47 29 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0x285d
[UNREPLIED] src=y.y.y.y dst=z.z.z.z srckey=0x285d dstkey=0x0 mark=0
use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been
shown.

Когда pptp работает:
$ sudo conntrack -L -p 47
gre  47 17995 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0xbe6f
src=y.y.y.y dst=z.z.z.z srckey=0xbe6f dstkey=0xc6ad [ASSURED] mark=0
use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been
shown.

x.x.x.x - локальный адрес клиента
y.y.y.y - адрес VPN сервера
z.z.z.z - внешний адрес маршрутизатора

Может кто-то знает что нужно подкрутить в новом ядре чтобы начал
правильно работать NAT?

-- 
WBR, Andrey Tataranovich

Настройка pptp в debian squeeze

[Фёдор Елизаров]

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

/etc/ppp/options.pptp
/etc/ppp/options
/etc/ppp/pers

спасибо

Re: Настройка pptp в debian squeeze

[Dmitry A. Zhiglov]

19 августа 2012 г., 22:39 пользователь Фёдор Елизаров
blogd...@gmail.com написал:


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

 /etc/ppp/options.pptp
 /etc/ppp/options
 /etc/ppp/pers

 спасибо

Может тут есть ответ?
http://wiki.debian.org/ru/pptp-linux

Re: Настройка pptp в debian squeeze

[Фёдор Елизаров]

19 августа 2012 г., 23:24 пользователь Dmitry A. Zhiglov 
dmitry.zhig...@gmail.com написал:

 19 августа 2012 г., 22:39 пользователь Фёдор Елизаров
 blogd...@gmail.com написал:
 
 
  Вообщем либо я дурак полный, либо что то в системе не так
  Всегда пользовался NetworkManager,но он сеть не поднимает да и вообще
 надоел.
  Решил как полагается просто конфиги настроить  и забыть про подключение
 отключение
  И тут началось то одно не пашет то другое не пашет то вроде всё пашет но
 ничего не пашет дурдом вообщем.
  Приводить конфиги тут я не буду , а лучше попрошу выложить свои , так
 думаю будет проще понять что у меня не так.
  Пожалуйста выложите рабочие конфиги pptp соединения
 
  /etc/ppp/options.pptp
  /etc/ppp/options
  /etc/ppp/pers
 
  спасибо

 Может тут есть ответ?
 http://wiki.debian.org/ru/pptp-linux



Понял,спасибо.

Re: debian + hostapd + pptp = pptp random disconnect

[Andrey Melnikoff]

Gary Trotcko teego...@gmail.com wrote:
 Похоже проблема была не в карточке 3Com или не только в карточке 3Com.
 Сегодня после 3-х дней стабильной работы pptp с картой Realtek на моём
 роутере опять начались проблемы, правда теперь pptp не отключается, а
 падает wifi сеть. При этом наблюдается следующее:

 May 25 17:37:12 debian kernel: [519683.115028] ath: Could not stop RX,
 we could be confusing the DMA engine when we start RX up
 May 25 17:37:13 debian kernel: [519683.469333] ath: DMA failed to stop
 in 10 ms AR_CR=0x0024 AR_DIAG_SW=0x4220 DMADBG_7=0x8040
 May 25 17:37:13 debian kernel: [519683.469435] ath: Could not stop RX,
 we could be confusing the DMA engine when we start RX up
 May 25 17:37:13 debian kernel: [519683.823692] ath: DMA failed to stop
 in 10 ms AR_CR=0x0024 AR_DIAG_SW=0x4220 DMADBG_7=0x8040

 Видимо всё-таки баг в ath9k?

Смотрим в превое сообщение и видим 

$ iwconfig
wlan0 IEEE 802.11bgn  Mode:Master  Frequency:2.437 GHz  Tx-Power=13 dBm
  Retry  long limit:7   RTS thr:off   Fragment thr:off
  Power Management:on

mon.wlan0  IEEE 802.11bgn  Mode:Monitor  Tx-Power=13 dBm
  Retry  long limit:7   RTS thr:off   Fragment thr:off
  Power Management:on

Теперь идем в гуголь и ищем ath: phy0: DMA failed to stop. По дороге
находим сей чудесный тред
http://comments.gmane.org/gmane.linux.kernel.wireless.general/86340
и пробуем рекомендации.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1bmn99-rmv@kenga.kmv.ru

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

 Смотрим в превое сообщение и видим

$ iwconfig
wlan0     IEEE 802.11bgn  Mode:Master  Frequency:2.437 GHz  Tx-Power=13 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

mon.wlan0  IEEE 802.11bgn  Mode:Monitor  Tx-Power=13 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

 Теперь идем в гуголь и ищем ath: phy0: DMA failed to stop. По дороге
 находим сей чудесный тред
 http://comments.gmane.org/gmane.linux.kernel.wireless.general/86340
 и пробуем рекомендации.


 --
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/1bmn99-rmv@kenga.kmv.ru


Слишком долго я ждал отвтета в данной рассылке, посему отчаявшись
получить здесь ответ стал слёзно просить о помощи в других
рассылках[1] и не только[2]. Каюсь, упустил необходимость указать тут
некоторые свои действия, проведённые мною в последнее время. Пройдя по
указанным ссылкам можно заметить что предложенные Вами игры с
отключением power saving (я ходил в тот-же гуголь что и Вы) не дали
никакого эффекта, более того после установки последнего снапшота
compat-wireless отключить power managament стало просто невозможно.
Вот такой теперь выхлоп:

# iwconfig wlan0 power off
Error for wireless request Set Power Management (8B2C) :
SET failed on device wlan0 ; Invalid argument.

С дистрибутивными драйверами такого не замечалось. Из того эе треда,
на который Вы сослались, можно сделать вывод что power saving не
единственная причина такого поведения.


--
[1]https://lists.ath9k.org/pipermail/ath9k-devel/2012-May/008960.html
[2]http://unix.stackexchange.com/questions/39402/debian-whezzy-hostapd-1-0-ath9k-randomly-failing

-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Похоже проблема была не в карточке 3Com или не только в карточке 3Com.
Сегодня после 3-х дней стабильной работы pptp с картой Realtek на моём
роутере опять начались проблемы, правда теперь pptp не отключается, а
падает wifi сеть. При этом наблюдается следующее:

$ ifconfig
eth1  Link encap:Ethernet  HWaddr 00:60:97:d8:dd:ea
  inet addr:192.168.120.184  Bcast:192.168.120.255  Mask:255.255.255.0
  inet6 addr: fe80::260:97ff:fed8:ddea/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:12337789 errors:41 dropped:236 overruns:32 frame:0
  TX packets:10504103 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3014012007 (2.8 GiB)  TX bytes:3729509028 (3.4 GiB)
  Interrupt:10 Base address:0xd800

eth2  Link encap:Ethernet  HWaddr 14:da:e9:a7:21:33
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::16da:e9ff:fea7:2133/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:9238340 errors:0 dropped:59 overruns:0 frame:0
  TX packets:8264413 errors:1 dropped:30 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3287755996 (3.0 GiB)  TX bytes:643438599 (613.6 MiB)
  Interrupt:11 Base address:0xdc00

loLink 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:6 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:588 (588.0 B)  TX bytes:588 (588.0 B)

mon.wlan0 Link encap:UNSPEC  HWaddr
B0-48-7A-E3-AE-0F-00-00-00-00-00-00-00-00-00-00
  UP BROADCAST RUNNING MULTICAST  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ppp0  Link encap:Point-to-Point Protocol
  inet addr:93.190.180.221  P-t-P:195.66.139.22  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
  RX packets:2170289 errors:0 dropped:0 overruns:0 frame:0
  TX packets:259 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:3
  RX bytes:1698063924 (1.5 GiB)  TX bytes:2336947509 (2.1 GiB)

wlan0 Link encap:Ethernet  HWaddr b0:48:7a:e3:ae:0f
  inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
  inet6 addr: fe80::b248:7aff:fee3:ae0f/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1197072 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1729950 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:143929456 (137.2 MiB)  TX bytes:1956722531 (1.8 GiB)

В /var/log/messages появляется такое:

May 25 17:32:33 debian kernel: [519404.008050] [ cut here
]
May 25 17:32:33 debian kernel: [519404.008099] WARNING: at
/build/buildd-linux-2.6_3.2.16-1-i386-xAlW9F/linux-2.6-3.2.16/debian/build/s
ource_i386_none/net/sched/sch_generic.c:255 dev_watchdog+0xb1/0x104()
May 25 17:32:33 debian kernel: [519404.008114] Hardware name:
May 25 17:32:33 debian kernel: [519404.008123] NETDEV WATCHDOG: eth2
(sundance): transmit queue 0 timed out
May 25 17:32:33 debian kernel: [519404.008134] Modules linked in:
cryptd aes_i586 aes_generic ppp_async crc_ccitt ppp_generic slhc ipt_
MASQUERADE xt_TCPMSS xt_limit xt_pkttype ipt_REJECT xt_tcpudp xt_state
ipt_LOG iptable_mangle iptable_nat iptable_filter nf_conntrack_i
rc nf_nat_ftp nf_conntrack_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_conntrack ip_tables x_tables loop arc4 ath9k ath9k_common ath
9k_hw ath snd_ens1371 mac80211 snd_ac97_codec snd_rawmidi
snd_seq_device snd_pcm cfg80211 snd_page_alloc snd_timer snd rfkill
soundcore
 ac97_bus evdev serio_raw joydev pcspkr i2c_i801 gameport i2c_core
iTCO_wdt iTCO_vendor_support rng_core shpchp parport_pc parport proc
essor thermal_sys button ext4 crc16 jbd2 mbcache dm_mod hid_microsoft
usbhid hid sr_mod sd_mod cdrom crc_t10dif ata_generic 8139too ata_piix
libata uhci_hcd ehci_hcd usbcore scsi_mod floppy 3c59x 8139cp
usb_common sundance mii [last unloaded: scsi_wait_scan]
May 25 17:32:33 debian kernel: [519404.008432] Pid: 0, comm: swapper/0
Not tainted 3.2.0-2-686-pae #1
May 25 17:32:33 debian kernel: [519404.008441] Call Trace:
May 25 17:32:33 debian kernel: [519404.008471]  [c10384b8] ?
warn_slowpath_common+0x68/0x79
May 25 17:32:33 debian kernel: [519404.008514]  [c12313b4] ?
dev_watchdog+0xb1/0x104
May 25 17:32:33 debian kernel: [519404.008531]  [c1038531] ?
warn_slowpath_fmt+0x29/0x2d
May 25 17:32:33 debian kernel: [519404.008546]  [c12313b4] ?
dev_watchdog

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Отключил я трикомовскую карточку. Поднимаю впн на риелтеке - всё работает.

-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Andrey Melnikoff]

Gary Trotcko teego...@gmail.com wrote:
 2012/5/18 Andrey Tataranovich tataranov...@gmail.com:

  Выкинь ты свой 3Com, бо подозреваю, что у тебя OfficeConnect какой-нить.

 $ lspci | grep -i 3com
 01:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Выкинь нафиг и забудь, что ты это держал в руках. Вечные проблемы с IRQ,
плач ярославны на все интернеты с 1998 года.

Кончно, если так прельщает сам процесс да в гамаке и с лыжами... Рекомендую
в онный роутер еще поставить блок питания послабее - станет еще интереснее.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ikek89-ehd@kenga.kmv.ru

Re: debian + hostapd + pptp = pptp random disconnect

[Andrey Melnikoff]

Gary Trotcko teego...@gmail.com wrote:
 Сглазил... Сегодня после 3-х дней исправной работы  система намертво
 зависла. Причина возможно постом выше.
Так выкинь ты это трикомовское поделье. Купи в ближайшей лавке кривалетк за
$3 и всё.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/fjth89-t17@kenga.kmv.ru

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

2012/5/18 Andrey Melnikoff temnota+n...@kmv.ru:
 Gary Trotcko teego...@gmail.com wrote:
 Сглазил... Сегодня после 3-х дней исправной работы  система намертво
 зависла. Причина возможно постом выше.
 Так выкинь ты это трикомовское поделье. Купи в ближайшей лавке кривалетк за
 $3 и всё.

Не могу. Мы не ищем лёгких путей. Если секс, то исключитеьно в гамаке,
надев гидрокостюм, ласты и акваланг :-) С наступающим всех летом!

P.S. Если буду уверен что виновата именно карточка 3Com, а не WiFi
TP-Link, то я её выкину без сожаления, тем более что лишняя карта и
так уже есть.

-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Andrey Tataranovich]

18:35 Fri 18 May, Gary Trotcko wrote:
 2012/5/18 Andrey Melnikoff temnota+n...@kmv.ru:
  Gary Trotcko teego...@gmail.com wrote:
  Сглазил... Сегодня после 3-х дней исправной работы  система намертво
  зависла. Причина возможно постом выше.
  Так выкинь ты это трикомовское поделье. Купи в ближайшей лавке кривалетк за
  $3 и всё.
 
 Не могу. Мы не ищем лёгких путей. Если секс, то исключитеьно в гамаке,
 надев гидрокостюм, ласты и акваланг :-) С наступающим всех летом!
 
 P.S. Если буду уверен что виновата именно карточка 3Com, а не WiFi
 TP-Link, то я её выкину без сожаления, тем более что лишняя карта и
 так уже есть.

Выкинь ты свой 3Com, бо подозреваю, что у тебя OfficeConnect какой-нить.

-- 
WBR, Andrey Tataranovich


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120518154028.gb27...@debbox.it

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

2012/5/18 Andrey Tataranovich tataranov...@gmail.com:

 Выкинь ты свой 3Com, бо подозреваю, что у тебя OfficeConnect какой-нить.

$ lspci | grep -i 3com
01:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Andrey Tataranovich]

19:12 Fri 18 May, Gary Trotcko wrote:
 2012/5/18 Andrey Tataranovich tataranov...@gmail.com:
 
  Выкинь ты свой 3Com, бо подозреваю, что у тебя OfficeConnect какой-нить.
 
 $ lspci | grep -i 3com
 01:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]

Да, прошу прощения. Пробежался по диагонали по треду.

Вот только я не смог найти внятного описания этой 3Com Boomerang. На картинке
выглядит как коробка типа роутера.

Думаю всетаки стоит попробовать обычный realtek, хотя бы для сравнения.

-- 
WBR, Andrey Tataranovich


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120518171448.gc27...@debbox.it

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Похоже действительно застарелый баг
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556433
-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Похоже что всё начинается с этого:

$ cat /var/log/messages
May 17 18:29:43 debian kernel: [  455.008040] [ cut here
]
May 17 18:29:43 debian kernel: [  455.008086] WARNING: at
/build/buildd-linux-2.6_3.2.16-1-i386-xAlW9F/linux-2.6-3.2.16/debian/build/source_i386_none/net/sched/sch_generic.c:255
dev_watchdog+0xb1/0x104()
May 17 18:29:43 debian kernel: [  455.008100] Hardware name:
May 17 18:29:43 debian kernel: [  455.008110] NETDEV WATCHDOG: eth0
(3c59x): transmit queue 0 timed out
May 17 18:29:43 debian kernel: [  455.008119] Modules linked in:
ppp_async crc_ccitt ppp_generic slhc ppdev lp ipt_MASQUERADE xt_TCPMSS
xt_limit xt_pkttype ipt_REJECT xt_tcpudp xt_state ipt_LOG
iptable_mangle iptable_nat iptable_filter nf_conntrack_irc nf_nat_ftp
nf_conntrack_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
ip_tables x_tables loop arc4 ath9k ath9k_common ath9k_hw snd_ens1371
snd_ac97_codec ath mac80211 snd_rawmidi snd_seq_device cfg80211
snd_pcm snd_page_alloc evdev snd_timer ac97_bus gameport snd soundcore
rfkill pcspkr serio_raw iTCO_wdt i2c_i801 iTCO_vendor_support i2c_core
rng_core shpchp parport_pc parport processor thermal_sys button ex
t4 crc16 jbd2 mbcache dm_mod sr_mod sd_mod cdrom crc_t10dif
ata_generic ata_piix libata 8139too uhci_hcd ehci_hcd usbcore scsi_mod
3c59x usb_common 8139cp floppy sundance mii [last unloaded:
scsi_wait_scan]
May 17 18:29:43 debian kernel: [  455.008412] Pid: 0, comm: swapper/0
Not tainted 3.2.0-2-686-pae #1
May 17 18:29:43 debian kernel: [  455.008422] Call Trace:
May 17 18:29:43 debian kernel: [  455.008445]  [c10384b8] ?
warn_slowpath_common+0x68/0x79
May 17 18:29:43 debian kernel: [  455.008461]  [c12313b4] ?
dev_watchdog+0xb1/0x104
May 17 18:29:43 debian kernel: [  455.008476]  [c1038531] ?
warn_slowpath_fmt+0x29/0x2d
May 17 18:29:43 debian kernel: [  455.008491]  [c12313b4] ?
dev_watchdog+0xb1/0x104
May 17 18:29:43 debian kernel: [  455.008534]  [c103ceed] ?
local_bh_enable+0x2/0x2
May 17 18:29:43 debian kernel: [  455.008559]  [c10420a0] ?
run_timer_softirq+0x150/0x1f3
May 17 18:29:43 debian kernel: [  455.008575]  [c1231303] ?
netif_tx_unlock+0x3a/0x3a
May 17 18:29:43 debian kernel: [  455.008591]  [c103ceed] ?
local_bh_enable+0x2/0x2
May 17 18:29:43 debian kernel: [  455.008606]  [c103cf81] ?
__do_softirq+0x94/0x12f
May 17 18:29:43 debian kernel: [  455.008621]  [c103ceed] ?
local_bh_enable+0x2/0x2
May 17 18:29:43 debian kernel: [  455.008631]  IRQ  [c103d172] ?
irq_exit+0x32/0x80
May 17 18:29:43 debian kernel: [  455.008677]  [c100ce06] ? do_IRQ+0x65/0x76
May 17 18:29:43 debian kernel: [  455.008701]  [c12c5af0] ?
common_interrupt+0x30/0x38
May 17 18:29:43 debian kernel: [  455.008734]  [c12000d8] ?
ps2_handle_ack+0x4d/0xb5
May 17 18:29:43 debian kernel: [  455.008753]  [c10246c0] ?
native_safe_halt+0x2/0x3
May 17 18:29:43 debian kernel: [  455.008779]  [c1010d9c] ?
default_idle+0x52/0x87
May 17 18:29:43 debian kernel: [  455.008794]  [c100b22f] ? cpu_idle+0x95/0xaf
May 17 18:29:43 debian kernel: [  455.008812]  [c141e708] ?
start_kernel+0x32a/0x32f
May 17 18:29:43 debian kernel: [  455.008822] ---[ end trace
9737306d46d59b07 ]---
--
Best Regards,
Gary Trotcko


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAG0qy5+e-t8uFAqVJEUoDVM9aSXKa=prshmow-w2f6azy13...@mail.gmail.com

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Сглазил... Сегодня после 3-х дней исправной работы  система намертво
зависла. Причина возможно постом выше.
-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Ну в принципе можно резюмировать - pptp канал работает вторые сутки
вполне стабильно. Помогло включение буферизации. Однако стоит
заметить, что в Squeezy, игры с опциями pptp не приносили никакой
пользы. Stable, как я уже писал, мог зависнуть намертво, если просто
поднять wlan, даже не запуская hostapd - видимо в ядре 2.6.32 есть
баг, а в Wheezy (Linux 3.2) его исправили. Рискну предположить что баг
именно в ядре 2.6.32 (возможнов в ath9k). На hostapd грешить не могу.
Делаю такое предположение, исходя из того что аналогичные проблемы
были и в Fedora 13 (Linux 2.6.32), на ней я пробовал разные версии
hostapd - 0.6.9; 0.6.10; 0.7.2 и проблема оставалась не решённой.

Спасибо всем откликнувшимся за помощь.
-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Eugene Berdnikov]

On Mon, May 14, 2012 at 02:01:40AM +0300, Gary Trotcko wrote:
 May 14 00:45:32 debian pptp[11703]: anon
 log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has
 closed
 May 14 00:45:32 debian pptp[11703]: anon
 log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
 May 14 00:45:32 debian pptp[11703]: anon
 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12
 'Call-Clear-Request'

 Запишите дамп трафика и посмотрите, действительно ли обрывается
 контрольная коннекция pptp (tcp порт 1723). Если да, то далее
 нужно будет искать причину обрыва.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120514083508.gn2...@protva.ru

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Хм, собственно вот, но... ((

cat /var/log/messages | grep pppd
May 14 13:30:46 debian pppd[11352]: Modem hangup
May 14 13:30:46 debian pppd[11352]: Connect time 4.6 minutes.
May 14 13:30:46 debian pppd[11352]: Sent 34894 bytes, received 61693 bytes.
May 14 13:30:47 debian pppd[11352]: Connection terminated.
May 14 13:30:48 debian pppd[11352]: Using interface ppp0
May 14 13:30:48 debian pppd[11352]: Connect: ppp0 -- /dev/pts/0
May 14 13:30:56 debian pppd[11352]: CHAP authentication succeeded: Welcome.
May 14 13:30:56 debian pppd[11352]: CHAP authentication succeeded
May 14 13:30:56 debian pppd[11352]: local  IP address 80.242.110.65
May 14 13:30:56 debian pppd[11352]: remote IP address 195.66.139.28

tcpdump -i eth0 tcp port 1723
13:29:30.676173 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[P.], seq 4103653949:4103653965, ack 4202577046, win 3650, options
[nop,nop,TS val 32806508 ecr 654449703], length 16: pptp
CTRL_MSGTYPE=ECHORQ ID(3)
13:29:55.662113 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[P.], seq 0:16, ack 1, win 3650, options [nop,nop,TS val 32811781 ecr
654449703], length 16: pptp CTRL_MSGTYPE=ECHORQ ID(3)
13:29:55.662446 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[.], ack 16, win 62, options [nop,nop,TS val 654458202 ecr
32811781,nop,nop,sack 1 {0:16}], length 0
13:29:55.739219 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[P.], seq 1:21, ack 16, win 62, options [nop,nop,TS val 654458210 ecr
32811781], length 20: pptp CTRL_MSGTYPE=ECHORP ID(3) RESULT_CODE(1)
ERR_CODE(0)
13:29:55.739405 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[.], ack 21, win 3650, options [nop,nop,TS val 32812773 ecr
654458210], length 0
13:30:46.979768 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463334 ecr
32812773], length 0
13:30:46.980456 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[P.], seq 16:32, ack 22, win 3650, options [nop,nop,TS val 32825584
ecr 654463334], length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)
13:30:46.981123 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[F.], seq 32, ack 22, win 3650, options [nop,nop,TS val 32825584 ecr
654463334], length 0
13:30:47.188552 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463355 ecr
32812773], length 0
13:30:47.188877 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[.], ack 22, win 3650, options [nop,nop,TS val 32825636 ecr
654463355,nop,nop,sack 1 {21:22}], length 0
13:30:47.608535 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463397 ecr
32812773], length 0
13:30:47.608775 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[.], ack 22, win 3650, options [nop,nop,TS val 32825741 ecr
654463397,nop,nop,sack 1 {21:22}], length 0
13:30:48.448503 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463481 ecr
32812773], length 0
13:30:50.128529 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463649 ecr
32812773], length 0
13:30:53.498452 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463986 ecr
32812773], length 0
13:30:55.665424 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[.], ack 22, win 3650, options [nop,nop,TS val 32825951 ecr
654463481,nop,nop,sack 1 {21:22}], length 0
13:30:55.665534 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.665542 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.665564 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.665572 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.666073 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.666464 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[.], ack 22, win 3650, options [nop,nop,TS val 32826371 ecr
654463649,nop,nop,sack 1 {21:22}], length 0
13:30:55.74 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.667079 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
[.], ack 22, win 3650, options [nop,nop,TS val 32827213 ecr
654463986,nop,nop,sack 1 {21:22}], length 0
13:30:55.667305 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
[R], seq 4202577067, win 0, length 0
13:30:55.705798 IP 192.168.120.184.59274  192.168.117.208.1723: Flags
[S], seq 497417327, win 14600, options [mss 1460,sackOK,TS val
32827755 ecr 0,nop,wscale 2], length 0
13:30:55.706265 IP 192.168.117.208.1723  192.168.120.184.59274: Flags
[S.], seq 1377554967, ack 497417328, win 5792, options [mss
1460,sackOK,TS val 1232785412 ecr 32827755,nop,wscale 7], length 0
13:30

Re: debian + hostapd + pptp = pptp random disconnect

[Eugene Berdnikov]

On Mon, May 14, 2012 at 02:13:26PM +0300, Gary Trotcko wrote:
 Хм, собственно вот, но... ((
 
 cat /var/log/messages | grep pppd
 May 14 13:30:46 debian pppd[11352]: Modem hangup
 May 14 13:30:46 debian pppd[11352]: Connect time 4.6 minutes.
 May 14 13:30:46 debian pppd[11352]: Sent 34894 bytes, received 61693 bytes.
 May 14 13:30:47 debian pppd[11352]: Connection terminated.
 May 14 13:30:48 debian pppd[11352]: Using interface ppp0
 May 14 13:30:48 debian pppd[11352]: Connect: ppp0 -- /dev/pts/0
 May 14 13:30:56 debian pppd[11352]: CHAP authentication succeeded: Welcome.
 May 14 13:30:56 debian pppd[11352]: CHAP authentication succeeded
 May 14 13:30:56 debian pppd[11352]: local  IP address 80.242.110.65
 May 14 13:30:56 debian pppd[11352]: remote IP address 195.66.139.28
 
 tcpdump -i eth0 tcp port 1723
 13:29:30.676173 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [P.], seq 4103653949:4103653965, ack 4202577046, win 3650, options
 [nop,nop,TS val 32806508 ecr 654449703], length 16: pptp
 CTRL_MSGTYPE=ECHORQ ID(3)
 13:29:55.662113 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [P.], seq 0:16, ack 1, win 3650, options [nop,nop,TS val 32811781 ecr
 654449703], length 16: pptp CTRL_MSGTYPE=ECHORQ ID(3)
 13:29:55.662446 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [.], ack 16, win 62, options [nop,nop,TS val 654458202 ecr
 32811781,nop,nop,sack 1 {0:16}], length 0
 13:29:55.739219 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [P.], seq 1:21, ack 16, win 62, options [nop,nop,TS val 654458210 ecr
 32811781], length 20: pptp CTRL_MSGTYPE=ECHORP ID(3) RESULT_CODE(1)
 ERR_CODE(0)
 13:29:55.739405 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 21, win 3650, options [nop,nop,TS val 32812773 ecr
 654458210], length 0

 13:30:46.979768 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463334 ecr
 32812773], length 0

 Собственно, содержательная часть начинается с этого FINa (последний пакет).
 Сервер закрыл коннекцию без видимых причин. Отправляйте этот дамп
 провайдеру в качестве рекламации (желательно добавить ещё -vv -s0)
 и спрашивайте, какого чёрта так происходит.

 13:30:46.980456 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [P.], seq 16:32, ack 22, win 3650, options [nop,nop,TS val 32825584
 ecr 654463334], length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)
 13:30:46.981123 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [F.], seq 32, ack 22, win 3650, options [nop,nop,TS val 32825584 ecr
 654463334], length 0
 13:30:47.188552 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463355 ecr
 32812773], length 0
 13:30:47.188877 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 22, win 3650, options [nop,nop,TS val 32825636 ecr
 654463355,nop,nop,sack 1 {21:22}], length 0
 13:30:47.608535 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463397 ecr
 32812773], length 0
 13:30:47.608775 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 22, win 3650, options [nop,nop,TS val 32825741 ecr
 654463397,nop,nop,sack 1 {21:22}], length 0
 13:30:48.448503 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463481 ecr
 32812773], length 0
 13:30:50.128529 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463649 ecr
 32812773], length 0
 13:30:53.498452 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463986 ecr
 32812773], length 0

 Судя по пачке FINов от сервера, для которых нет никаких видимых на
 стороне клиента причин (т.е. отправленных от 192.168.120.184 на сервер
 пакетов), а также по аналогичной пачке RST ниже, похоже, что какой-то
 промежуточный узел активно закрывает коннекцию от имени клиента.
 То есть соединения портятся злоумышленником, в качестве которого может
 выступать прослушивающий соединения мониторинговый софт. Есть вирусы,
 пытающиеся перехватывать трафик для поиска адресов e-mail, паролей
 и прочего, они иногда так глючат.

 13:30:55.665424 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 22, win 3650, options [nop,nop,TS val 32825951 ecr
 654463481,nop,nop,sack 1 {21:22}], length 0
 13:30:55.665534 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [R], seq 4202577067, win 0, length 0
 13:30:55.665542 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [R], seq 4202577067, win 0, length 0
 13:30:55.665564 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [R], seq 4202577067, win 0, length 0
 13:30:55.665572 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [R], seq 4202577067, win 0, length 0
 13:30:55.666073 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [R], seq 4202577067, win 0, length 0
-- 
 Eugene

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Мммм  Но почему при _выключенном_hostapd_ сессия на рвётся? Начать
разбираться с провайдером можно было бы, но дело в том что он, мягко
говоря, не приветствует подобные вещи (роутеры и пр.), у них политика
такая  - 1 канал на 1 хост. Хочешь больше, подключай ещё 1 кабель.

-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Eugene Berdnikov]

On Mon, May 14, 2012 at 04:15:22PM +0300, Gary Trotcko wrote:
 Мммм  Но почему при _выключенном_hostapd_ сессия на рвётся?

 Это меня тоже занимало, продолжал чесать репу после того как
 написал последнее письмо. И нашёл признаки того, что у клиента
 поломан ip-шный стэк. Видно по этому фрагменту:

 13:29:55.739405 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 21, win 3650, options [nop,nop,TS val 32812773 ecr
 654458210], length 0

 13:30:46.979768 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463334 ecr
 32812773], length 0

 13:30:46.980456 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [P.], seq 16:32, ack 22, win 3650, options [nop,nop,TS val 32825584
 ecr 654463334], length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)

 Здесь такая нестыковка: после прихода от сервера пакета нулевой длины
 на клиенте счётчик байтов смещается на 1 (с ack=21 на ack=22).
 IMHO, это бага.

 Как реагирует на это ядро сервера -- неизвестно, но вполне вероятно,
 что оно начинает дропать все дальнейшие пакеты от клиента (которые
 выбежали за границу окна передачи), но при этом считать, что FIN остался
 без подтверждения. Если это так, то пачка FINов от сервера является
 простыми ретрансмиссиями первого, что похоже на правду, поскольку
 у них всех ecr=32812773.

 Ниже нашлась ещё одна фигня со строны клиента:

 13:30:47.188877 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 22, win 3650, options [nop,nop,TS val 32825636 ecr
 654463355,nop,nop,sack 1 {21:22}], length 0

 Сочетание ack=22 и sack={21:22} нелепо, таких пакетов быть не должно.

 В общем, похоже что включение hostapd приводит к поломке ip-стэка.
 Правда, я всё-таки не вижу причину для первоначального FINа от сервера.
 Но дамп неполный, не исключено, что коннекция сломалась задолго до того,
 как был запущен tcpdump, и первый FIN -- окончание процесса умирания
 по таймауту. Тогда никакие злоумышленники не при чём, конечно. :)
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120514141827.gc7...@protva.ru

Re: debian + hostapd + pptp = pptp random disconnect

[Andrey Melnikoff]

Gary Trotcko teego...@gmail.com wrote:
 Мммм  Но почему при _выключенном_hostapd_ сессия на рвётся? Начать
ifconfig и arp -an в момент разрыва покажи.

 разбираться с провайдером можно было бы, но дело в том что он, мягко
 говоря, не приветствует подобные вещи (роутеры и пр.), у них политика
 такая  - 1 канал на 1 хост. Хочешь больше, подключай ещё 1 кабель.
Голосовать деньгами надо от таких провайдеров. Ибо его не должно волновать,
сколько электрочайников с прочими книгочиталками сидят за твоим роутером.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/v9j789-dd3@kenga.kmv.ru

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Извиняюсь, за ненарочно отправленные письма не в рассылку.

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

2012/5/14 Andrey Melnikoff temnota+n...@kmv.ru:
 Gary Trotcko teego...@gmail.com wrote:
 Мммм  Но почему при _выключенном_hostapd_ сессия на рвётся? Начать
 ifconfig и arp -an в момент разрыва покажи.
Пока работает...

 разбираться с провайдером можно было бы, но дело в том что он, мягко
 говоря, не приветствует подобные вещи (роутеры и пр.), у них политика
 такая  - 1 канал на 1 хост. Хочешь больше, подключай ещё 1 кабель.
 Голосовать деньгами надо от таких провайдеров. Ибо его не должно волновать,
 сколько электрочайников с прочими книгочиталками сидят за твоим роутером.
Надо, но бежать некуда. Город небольшой, а провайдер, по сути
локальный монополист.
-- 
Best Regards,
Gary Trotcko

Re: debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

2012/5/14 Eugene Berdnikov b...@protva.ru:
 On Mon, May 14, 2012 at 04:15:22PM +0300, Gary Trotcko wrote:
 Мммм  Но почему при _выключенном_hostapd_ сессия на рвётся?

  Это меня тоже занимало, продолжал чесать репу после того как
  написал последнее письмо. И нашёл признаки того, что у клиента
  поломан ip-шный стэк. Видно по этому фрагменту:

 13:29:55.739405 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 21, win 3650, options [nop,nop,TS val 32812773 ecr
 654458210], length 0

 13:30:46.979768 IP 192.168.117.211.1723  192.168.120.184.56438: Flags
 [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463334 ecr
 32812773], length 0

 13:30:46.980456 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [P.], seq 16:32, ack 22, win 3650, options [nop,nop,TS val 32825584
 ecr 654463334], length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)

  Здесь такая нестыковка: после прихода от сервера пакета нулевой длины
  на клиенте счётчик байтов смещается на 1 (с ack=21 на ack=22).
  IMHO, это бага.

  Как реагирует на это ядро сервера -- неизвестно, но вполне вероятно,
  что оно начинает дропать все дальнейшие пакеты от клиента (которые
  выбежали за границу окна передачи), но при этом считать, что FIN остался
  без подтверждения. Если это так, то пачка FINов от сервера является
  простыми ретрансмиссиями первого, что похоже на правду, поскольку
  у них всех ecr=32812773.

  Ниже нашлась ещё одна фигня со строны клиента:

 13:30:47.188877 IP 192.168.120.184.56438  192.168.117.211.1723: Flags
 [.], ack 22, win 3650, options [nop,nop,TS val 32825636 ecr
 654463355,nop,nop,sack 1 {21:22}], length 0

  Сочетание ack=22 и sack={21:22} нелепо, таких пакетов быть не должно.

  В общем, похоже что включение hostapd приводит к поломке ip-стэка.
  Правда, я всё-таки не вижу причину для первоначального FINа от сервера.
  Но дамп неполный, не исключено, что коннекция сломалась задолго до того,
  как был запущен tcpdump, и первый FIN -- окончание процесса умирания
  по таймауту. Тогда никакие злоумышленники не при чём, конечно. :)

Приблизительно такую причину я и предполагал (эмпирически :)), Вот
решил поиграться с опциями pptp - обратил внимание что выключена
буферизация опцией --nobuffer. Запустил без неё - рабтает уже больше
4-х часов. Ждём-с...



-- 
Best Regards,
Gary Trotcko

debian + hostapd + pptp = pptp random disconnect

[Gary Trotcko]

Приветствую всех читающих. Дебютирую с этим тредом в данной рассылке ))

Преамбула.
--
Есть роутер, сделанный из старого тазика. На нём 3 сетевых и 1 wifi
карта TP-Link TL-WN751ND. На этом крутится: dhcpd, hostapd и пр.
eth0 получает IP по DHCP от провайдера (3Com)
eth1 раздаёт IP в локалку по DHCPD (Realtek)
eth2 отключен
ppp0 - это VPN по PPTP
wlan0 собственно в мастер-мод и есть точка доступа через hostapd.

Работает это всё через NAT iptables.

Собственно проблема заключается в том что pptp периодически и
произвольно обрывается - может работать несколько часов без перерыва,
а может и в течение 5 минут несколько раз оборваться.  Если отключить
hostapd, то pptp соединение работает стабильно. Намёка на возможную
причину в логах обнаружить не удалось.

В squeezy дела обстояли ещё плачевнее - система периодически зависала
намертво, просто при поднятом wlan0. После обновления до sid ситуация
всё же стала получше.

Хочу ещё заметить что Debian на этой машине работает всего 3 дня, до
этого стояла Fedora 13 и ситуация была почти такая же.

И ещё один момент - с карточкой TP-LINK TL-WN951N, пару месяцев назад,
Fedora 13 работала гладко.


Конфигурация
--

$ cat /etc/debian_version
wheezy/sid

$ uname -r
3.2.0-2-686-pae

$ hostapd -v
hostapd v0.7.3
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2010, Jouni Malinen j...@w1.fi and contributors

$ lspci
00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics
Memory Controller Hub (rev 03)
00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133
(CGC) Chipset Graphics Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
00:1f.2 USB controller: Intel Corporation 82801AA USB Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
01:07.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
01:08.0 Network controller: Atheros Communications Inc. AR9227
Wireless Network Adapter (rev 01)
01:09.0 Ethernet controller: Sundance Technology Inc / IC Plus Corp IC
Plus IP100A Integrated 10/100 Ethernet MAC + PHY (rev 31)
01:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:60:97:d8:dd:ea
          inet addr:192.168.120.184  Bcast:192.168.120.255  Mask:255.255.255.0
          inet6 addr: fe80::260:97ff:fed8:ddea/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1366967 errors:0 dropped:0 overruns:1 frame:0
          TX packets:305996 errors:1695 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:586611842 (559.4 MiB)  TX bytes:57518913 (54.8 MiB)
          Interrupt:9 Base address:0xdf00

eth1      Link encap:Ethernet  HWaddr 00:0e:2e:d9:00:54
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:2eff:fed9:54/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:376318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:500999 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:53562288 (51.0 MiB)  TX bytes:481165916 (458.8 MiB)
          Interrupt:10 Base address:0xd800

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:1476 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1476 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:167995 (164.0 KiB)  TX bytes:167995 (164.0 KiB)

mon.wlan0 Link encap:UNSPEC  HWaddr
B0-48-7A-E3-AE-0F-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4971 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:574458 (560.9 KiB)  TX bytes:0 (0.0 B)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:93.190.182.144  P-t-P:195.66.139.22  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:1480 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1659 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:336409 (328.5 KiB)  TX bytes:399862 (390.4 KiB)

wlan0     Link encap:Ethernet  HWaddr b0:48:7a:e3:ae:0f
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::b248:7aff:fee3:ae0f/64 Scope:Link

Re: pptp старт автоматически при загрузке

[Andrey Melnikoff]

Eugene Berdnikov b...@protva.ru wrote:
 On Mon, Apr 02, 2012 at 02:31:14AM +0400, Stanislav Maslovski wrote:
   auto ppp0
   iface ppp0 inet ppp
   provider prov
   
   man 5 interfaces

  Этот пинок не туда. Надо в zless /usr/share/doc/ppp/README.Debian.gz

  Мда, кто б мог подумать что формат директив для ifupdown описан лишь
  в сопроводиловке к пакету ppp... в общем, если не страдать чистоплюйством
  (в смысле обязательно описывать интерфейс в /etc/network/interfaces)
У тебя там всегоа будет eth0, pptp ведь не через lo будет к серверу
коннектиться? Вот и пропиши туда up pon provider. А чтоб pppd при обрывах
не плодил ppp? интерфесы - в /etc/ppp/peers/provider добавить unit 0 или
какой более люимый номер.

  то поставленная задача (subj) решается подвешиванием pppd под init.
так все можно сделать через прописывание в init. только зачем?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/dsfo49-riv@kenga.kmv.ru

Re: pptp старт автоматически при загрузке

[Andrey Tataranovich]

19:30 Sun 01 Apr, Grigory Fateyev wrote:
 Добрый день!
 
 Подключение к локальной сети, настроена через NM, стартует при загрузке
 системы. Настроить pptp через NM не получилось, написал сценарий
 в /etc/ppp/peers/prov и стартую как pon prov.
 
 Хочется автоматизировать процесс и поднимать линка при загрузке, в
 идеале, ловить обрыв связи и рестартить коннект (типа etcnet). Как это
 лучше сделать?

Добавить в /etc/network/interfaces

auto ppp0
iface ppp0 inet ppp
provider prov

man 5 interfaces

Проблемы с обрывом - добавить в конфиг /etc/ppp/peers/prov

persist
maxfail 0 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120401202512.ga3...@blackice.home.tataranovich.com

Re: pptp старт автоматически при загрузке

[Eugene Berdnikov]

On Sun, Apr 01, 2012 at 11:25:12PM +0300, Andrey Tataranovich wrote:
 Добавить в /etc/network/interfaces
 
 auto ppp0
 iface ppp0 inet ppp
   provider prov
 
 man 5 interfaces

 В какой версии ifupdown есть метод ppp и директива provider?
 Покажите, pls, выдачу dpkg -l ifupdown.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120401210100.go1...@sie.protva.ru

Re: pptp старт автоматически при загрузке

[Stanislav Maslovski]

On Mon, Apr 02, 2012 at 01:01:00AM +0400, Eugene Berdnikov wrote:
 On Sun, Apr 01, 2012 at 11:25:12PM +0300, Andrey Tataranovich wrote:
  Добавить в /etc/network/interfaces
  
  auto ppp0
  iface ppp0 inet ppp
  provider prov
  
  man 5 interfaces
 
  В какой версии ifupdown есть метод ppp и директива provider?
  Покажите, pls, выдачу dpkg -l ifupdown.

Со времен sarge, емнимс, если не раньше. Собственно, в changelog
есть запись от 2000-го года:

2000-10-20   0.6.3  Anthony Towns a...@azure.humbug.org.au

* Fixed horrible bugs where to get n structures I realloc n
  bytes, instead of n * sizeof(..) bytes. Shame on me.

* Don't commit the new networking state to the statefile when
  --no-act is happening (after all, there *aren't* any changes...)

* Bring forward some changes from the .deb:
- /var/run/ifupdown.state - /etc/network/ifstate
  (/var may be NFS mounted...)
- Add /e/n/ifstate to manpage.
- Add pointopoint support for inet/static.
- dhcpcd works with all kernels, not 2.0 and 2.2 :)
- Add provider support for ppp. It's still a kludge.
  

В sarge оно уже точно работало.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120401222529.GA14628@kaiba.homelan

Re: pptp старт автоматически при загрузке

[Stanislav Maslovski]

On Sun, Apr 01, 2012 at 11:25:12PM +0300, Andrey Tataranovich wrote:
 19:30 Sun 01 Apr, Grigory Fateyev wrote:
  Добрый день!
  
  Подключение к локальной сети, настроена через NM, стартует при загрузке
  системы. Настроить pptp через NM не получилось, написал сценарий
  в /etc/ppp/peers/prov и стартую как pon prov.
  
  Хочется автоматизировать процесс и поднимать линка при загрузке, в
  идеале, ловить обрыв связи и рестартить коннект (типа etcnet). Как это
  лучше сделать?
 
 Добавить в /etc/network/interfaces
 
 auto ppp0
 iface ppp0 inet ppp
   provider prov
 
 man 5 interfaces
  
Этот пинок не туда. Надо в zless /usr/share/doc/ppp/README.Debian.gz

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120401223114.GB14628@kaiba.homelan

Re: pptp старт автоматически при загрузке

[Eugene Berdnikov]

On Mon, Apr 02, 2012 at 02:31:14AM +0400, Stanislav Maslovski wrote:
  auto ppp0
  iface ppp0 inet ppp
  provider prov
  
  man 5 interfaces
   
 Этот пинок не туда. Надо в zless /usr/share/doc/ppp/README.Debian.gz

 Мда, кто б мог подумать что формат директив для ifupdown описан лишь
 в сопроводиловке к пакету ppp... в общем, если не страдать чистоплюйством
 (в смысле обязательно описывать интерфейс в /etc/network/interfaces)
 то поставленная задача (subj) решается подвешиванием pppd под init.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120402053338.gp1...@sie.protva.ru

Re: [pptp] - дефектный ro und robin в DNS

[Stanislav Maslovski]

On Mon, Dec 29, 2008 at 03:09:40AM +0300, George Shuklin wrote:
 Есть PPTP-сервер (циска), которая не от доброй жизни висит по-очереди на 
 разных ИП разных провайдеров. Для того, чтобы имя циски было одно, она 
 прописана (всеми адресами) для одного имени:
 
 vpn IN A XX.XX.XX.XX
 vpn IN A YY.YY.YY.YY
 
 В виндах это приводило к паузе (секунд на 30) при присоединении (с 
 вероятностью 50%, как и ожидалось). При этом, при аварийном дисконнекте (и 
 переходе на резервную линию) переконнект происходил-таки сам, на нужный IP.
 
 С pptp ситуация другая - с вероятностью 50% он уходит в задумчивость:
 
 Dec 29 03:07:17 ns pppd[5125]: Using interface ppp0
 Dec 29 03:07:17 ns pppd[5125]: Connect: ppp0 -- /dev/pts/9

И это всё, что ты видишь в логе? Если один из адресов недоступен,
pptp будет отваливаться с no route to host, в логе ты это увидишь.
Если _оба_ адреса доступны (пингуются), то отваливаться будет скорее
скорее всего pppd по таймауту LCP config request, что тоже отразится в
логе. Хотелось бы увидеть лог целиком (и с опцией debug для pppd).

В первом случае как workaround проще всего написать скрипт типа такого:

apt-get install fping

= /etc/ppp/run-pptp =
#!/bin/sh
for VPN_ADDR in `dig $1 +short`; do
if fping -q $VPN_ADDR; then
   exec pptp $VPN_ADDR --sync --nolaunchpppd --nobuffer --loglevel 0
fi
done
=

и в /etc/ppp/peers/provider иметь

pty /etc/ppp/run-pptp vpn.domain.name

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

[pptp] - дефектный round robin в DNS

[George Shuklin]

Есть PPTP-сервер (циска), которая не от доброй жизни висит по-очереди на разных 
ИП разных провайдеров. Для того, чтобы имя циски было одно, она прописана 
(всеми адресами) для одного имени:

vpn IN A XX.XX.XX.XX
vpn IN A YY.YY.YY.YY

В виндах это приводило к паузе (секунд на 30) при присоединении (с вероятностью 
50%, как и ожидалось). При этом, при аварийном дисконнекте (и переходе на 
резервную линию) переконнект происходил-таки сам, на нужный IP.

С pptp ситуация другая - с вероятностью 50% он уходит в задумчивость:

Dec 29 03:07:17 ns pppd[5125]: Using interface ppp0
Dec 29 03:07:17 ns pppd[5125]: Connect: ppp0 -- /dev/pts/9

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

Где бы это поправить? Терять резервирование (какое-никакое) не хочется.

-- 
wBR,George.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [pptp] - дефектный round ro bin в DNS

[Nicholas]

George Shuklin wrote:

Есть PPTP-сервер (циска)


Если вам здесь не ответят, попробуйте спросить на:
http://forum.nag.ru/

--
Sincerely,
Nicholas


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [pptp] - дефектный round robin в DNS

[Владимир Ступин]

Здравствуйте!

Можно попробовать настроить два PPTP-соединения по одному на каждый адрес.

Re: /etc/network/interfaces и pptp. Что не так?

[Покотиленко Костик]

В Чтв, 04/12/2008 в 10:15 +0300, Peter Teslenko пишет:
 Alexey Boyko wrote:
 
  А вот там должно работать. Добавь вывод отладочной информации в скрипт, 
  чтобы 
  разобраться почему ( типа 2/tmp/1.log ).
 
 Уже разобрался почему не работало в /etc/ppp/ip-up.d/
 У меня в имени скрипта была точка, а run-parts, который вызывается из 
 /etc/ppp/ip-up
 этот скрипт просто не видит.

Вот-вот, опять вспомнил как я с этим тоже боролся, злой run-parts!

 [EMAIL PROTECTED]:/etc/ppp/ip-up.d# ls -al
 total 21
 drwxr-xr-x 2 root root  192 2008-12-04 10:14 .
 drwxr-xr-x 8 root root  544 2008-12-01 19:08 ..
 -rwxr-xr-x 1 root root  891 2007-03-18 01:52 usepeerdns
 -rwxr-xr-x 1 root root  467 2006-08-09 17:36 000resolvconf
 -rwxr-xr-x 1 root root 4022 2007-06-11 01:13 0dns-up
 -rwxr-xr-x 1 root root 1120 2007-03-21 14:17 postfix
 -rwxr-xr-x 1 root root  281 2008-12-03 21:41 pptp.routes-up
 
 [EMAIL PROTECTED]:/etc/ppp/ip-up.d# run-parts --list /etc/ppp/ip-up.d
 /etc/ppp/ip-up.d/usepeerdns
 /etc/ppp/ip-up.d/000resolvconf
 /etc/ppp/ip-up.d/0dns-up
 /etc/ppp/ip-up.d/postfix
 
 Убрал точку - всё заработало.
 
 -- 
 Peter Teslenko
 Jabber: [EMAIL PROTECTED]
 
 
-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Stanislav Maslovski]

On Thu, Dec 04, 2008 at 11:33:23AM +0200, Покотиленко Костик wrote:
 В Чтв, 04/12/2008 в 10:15 +0300, Peter Teslenko пишет:

  Уже разобрался почему не работало в /etc/ppp/ip-up.d/
  У меня в имени скрипта была точка, а run-parts, который вызывается из 
  /etc/ppp/ip-up
  этот скрипт просто не видит.
 
 Вот-вот, опять вспомнил как я с этим тоже боролся, злой run-parts!

Он не злой, к нему мануал есть.

-- 
Stanislav


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Покотиленко Костик]

В Чтв, 04/12/2008 в 12:41 +0300, Stanislav Maslovski пишет:
 On Thu, Dec 04, 2008 at 11:33:23AM +0200, Покотиленко Костик wrote:
  В Чтв, 04/12/2008 в 10:15 +0300, Peter Teslenko пишет:
 
   Уже разобрался почему не работало в /etc/ppp/ip-up.d/
   У меня в имени скрипта была точка, а run-parts, который вызывается из 
   /etc/ppp/ip-up
   этот скрипт просто не видит.
  
  Вот-вот, опять вспомнил как я с этим тоже боролся, злой run-parts!
 
 Он не злой, к нему мануал есть.

...в котором написано, что он злой!

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Олег Анисимов]

Peter Teslenko пишет:

Покотиленко Костик wrote:


Если маршрут не подымается, значит в нём что-то не так, попробуй 21

/root/route.log в конце команд по добавлению маршрутов добавить.


Вот так из interfaces

[EMAIL PROTECTED]:/etc/ppp# ifup --verbose ppp0
Configuring interface ppp0=ppp0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
pon c1841.pptp
ip r a 192.168.1.0/24 via 192.168.1.1

А разве вот это ^^ правильно? Ведь это по сути та же сеть.
Вот оно и ругается. Я еще понял бы p r a 192.168.1.0/24 via 192.168.2.1

RTNETLINK answers: No such process
Failed to bring up ppp0.

Т.е. честно выполняется post-up, но интерфейс ещё не поднялся.
Что нужно пнуть чтобы дождалось его поднятия?




--
--
С наилучшими пожеланиями,
Олег Анисимов AKA Yoda


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Покотиленко Костик]

В Чтв, 04/12/2008 в 17:13 +0300, Олег Анисимов пишет:
 Peter Teslenko пишет:
  Покотиленко Костик wrote:
 
  Если маршрут не подымается, значит в нём что-то не так, попробуй 21
  /root/route.log в конце команд по добавлению маршрутов добавить.
 
  Вот так из interfaces
 
  [EMAIL PROTECTED]:/etc/ppp# ifup --verbose ppp0
  Configuring interface ppp0=ppp0 (inet)
  run-parts --verbose /etc/network/if-pre-up.d
  run-parts: executing /etc/network/if-pre-up.d/wireless-tools
  run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
  pon c1841.pptp
  ip r a 192.168.1.0/24 via 192.168.1.1
 А разве вот это ^^ правильно? Ведь это по сути та же сеть.
 Вот оно и ругается. Я еще понял бы p r a 192.168.1.0/24 via 192.168.2.1

Это *может* быть правильно, 192.168.1.1 скорее всего P-t-P адрес (какой
ещё он может быть на PPP???), поэтому маршрут при поднятии есть только
для него, а для сети надо прописать.

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Peter Teslenko]

Олег Анисимов wrote:


pon c1841.pptp
ip r a 192.168.1.0/24 via 192.168.1.1

А разве вот это ^^ правильно? Ведь это по сути та же сеть.
Вот оно и ругается. Я еще понял бы p r a 192.168.1.0/24 via 192.168.2.1


Ещё как правильно. Это адрес pptp сервера, и, в данном случае, ещё и адрес 
обратной стороны туннеля.
Проблема была не с роутингом, а с тем что поднимать его из файла interfaces, в 
случае pptp (или просто ppp),
является плохой идеей. Правильным местом является /etc/ppp/ip-up.d/ , но т.к. 
скрипты запускаются через run-parts,
то на имена скриптов накладываются некоторые ограничения. В моём случае лишней 
была точка в имени скрипта.

--
Peter Teslenko
Jabber: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Покотиленко Костик]

В Вто, 02/12/2008 в 20:06 +0300, Peter Teslenko пишет:
 Приветствую.
 
 Прописал в /etc/network/intrfaces вот такую конструкцию
 
 iface ppp0 inet ppp
  provider c1841.pptp
 
 /etc/ppp/peers/c1841.pptp выглядит так
 
 remotename gw.bla-bla.ru
 linkname c1841.pptp
 ipparam c1841.pptp
 pty /usr/sbin/pptp --loglevel 1 gw.bla-bla.ru --nolaunchpppd
 name pptp
 require-mppe
 nomppe-stateful
 noauth
 lock
 bsdcomp 9,15
 deflate 9,15
 mtu 1492
 mru 1492
 
 После поднятия интерфейса ppp0 мне нужно прописать маршрут через него.
 Пытался прописывать в /etc/network/intrfaces
 
 post-up ip r a 192.168.1.0/24 via 192.168.1.1
 pre-down ip r d 192.168.1.0/24 via 192.168.1.1
 
 Почему-то не отрабатывает.
 Пытался положить скрипт в /etc/ppp/ip-up.d/
 и там отслеживать одно из
 
 IFNAME=ppp0
 IPLOCAL=192.168.2.10
 IPREMOTE=192.168.1.1
 LINKNAME=c1841.pptp
 PPP_IFACE=ppp0
 PPP_IPPARAM=c1841.pptp
 PPP_LOCAL=192.168.2.10
 PPP_REMOTE=192.168.1.1
 
 но почему-то и там роут не понимается.
 Что я делаю не так?

Если маршрут не подымается, значит в нём что-то не так, попробуй 21
 /root/route.log в конце команд по добавлению маршрутов добавить.

Для via 192.168.1.1 192.168.1.1 должен уже быть достижим. Можно
попробовать вместо via 192.168.1.1 поставить dev ppp0

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Oleg Anisimov (Олег Анисимов)]

Peter Teslenko пишет:

Приветствую.

Прописал в /etc/network/intrfaces вот такую конструкцию

iface ppp0 inet ppp
provider c1841.pptp

/etc/ppp/peers/c1841.pptp выглядит так

remotename gw.bla-bla.ru
linkname c1841.pptp
ipparam c1841.pptp
pty /usr/sbin/pptp --loglevel 1 gw.bla-bla.ru --nolaunchpppd
name pptp
require-mppe
nomppe-stateful
noauth
lock
bsdcomp 9,15
deflate 9,15
mtu 1492
mru 1492

После поднятия интерфейса ppp0 мне нужно прописать маршрут через него.

Просто добавьте в ваш /etc/ppp/peers/c1841.pptp следующее:
defaultroute
replacedefaultroute

Пытался прописывать в /etc/network/intrfaces

post-up ip r a 192.168.1.0/24 via 192.168.1.1
pre-down ip r d 192.168.1.0/24 via 192.168.1.1

Почему-то не отрабатывает.
Пытался положить скрипт в /etc/ppp/ip-up.d/
и там отслеживать одно из

IFNAME=ppp0
IPLOCAL=192.168.2.10
IPREMOTE=192.168.1.1
LINKNAME=c1841.pptp
PPP_IFACE=ppp0
PPP_IPPARAM=c1841.pptp
PPP_LOCAL=192.168.2.10
PPP_REMOTE=192.168.1.1

но почему-то и там роут не понимается.
Что я делаю не так?




--
--
С наилучшими пожеланиями,
Олег Анисимов AKA Yoda


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Peter Teslenko]

Oleg Anisimov (Олег Анисимов) wrote:



После поднятия интерфейса ppp0 мне нужно прописать маршрут через него.

Просто добавьте в ваш /etc/ppp/peers/c1841.pptp следующее:
defaultroute
replacedefaultroute


А мне не нужно чтобы менялся default gw на этот ppp.
Мне нужно прописать доп.маршрут через него.

--
Peter Teslenko
Jabber: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Покотиленко Костик]

В Срд, 03/12/2008 в 16:37 +0300, Oleg Anisimov (Олег Анисимов) пишет:
 Peter Teslenko пишет:
  Приветствую.
 
  Прописал в /etc/network/intrfaces вот такую конструкцию
 
  iface ppp0 inet ppp
  provider c1841.pptp
 
  /etc/ppp/peers/c1841.pptp выглядит так
 
  remotename gw.bla-bla.ru
  linkname c1841.pptp
  ipparam c1841.pptp
  pty /usr/sbin/pptp --loglevel 1 gw.bla-bla.ru --nolaunchpppd
  name pptp
  require-mppe
  nomppe-stateful
  noauth
  lock
  bsdcomp 9,15
  deflate 9,15
  mtu 1492
  mru 1492
 
  После поднятия интерфейса ppp0 мне нужно прописать маршрут через него.
 Просто добавьте в ваш /etc/ppp/peers/c1841.pptp следующее:
 defaultroute
 replacedefaultroute

Ему же не default надо, я только 192.168.1.0/24.

  Пытался прописывать в /etc/network/intrfaces
 
  post-up ip r a 192.168.1.0/24 via 192.168.1.1
  pre-down ip r d 192.168.1.0/24 via 192.168.1.1
 
  Почему-то не отрабатывает.
  Пытался положить скрипт в /etc/ppp/ip-up.d/
  и там отслеживать одно из
 
  IFNAME=ppp0
  IPLOCAL=192.168.2.10
  IPREMOTE=192.168.1.1
  LINKNAME=c1841.pptp
  PPP_IFACE=ppp0
  PPP_IPPARAM=c1841.pptp
  PPP_LOCAL=192.168.2.10
  PPP_REMOTE=192.168.1.1
 
  но почему-то и там роут не понимается.
  Что я делаю не так?
 
 
 
 -- 
 --
 С наилучшими пожеланиями,
 Олег Анисимов AKA Yoda
 
 
-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Andrey Nikitin]

В сообщении от 3 декабря 2008 17:26 Peter Teslenko написал(a):
 А мне не нужно чтобы менялся default gw на этот ppp.
 Мне нужно прописать доп.маршрут через него.

Посмотри в каталоги /etc/ppp/ip-{up,down}/
Может твоему скрипту (уст./удал. маршрута via ppp0) там самое правильное место?

-- 
С Уважением,
   Андрей Никитин


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Peter Teslenko]

Andrey Nikitin wrote:

В сообщении от 3 декабря 2008 17:26 Peter Teslenko написал(a):

А мне не нужно чтобы менялся default gw на этот ppp.
Мне нужно прописать доп.маршрут через него.


Посмотри в каталоги /etc/ppp/ip-{up,down}/
Может твоему скрипту (уст./удал. маршрута via ppp0) там самое правильное место?


В исходном сообщении я писал, что уже пытался это сделать

Получается вот это

RTNETLINK answers: No such process
Failed to bring up ppp0.

--
Peter Teslenko
Jabber: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Peter Teslenko]

Покотиленко Костик wrote:


Если маршрут не подымается, значит в нём что-то не так, попробуй 21

/root/route.log в конце команд по добавлению маршрутов добавить.


Вот так из interfaces

[EMAIL PROTECTED]:/etc/ppp# ifup --verbose ppp0
Configuring interface ppp0=ppp0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
pon c1841.pptp
ip r a 192.168.1.0/24 via 192.168.1.1
RTNETLINK answers: No such process
Failed to bring up ppp0.

Т.е. честно выполняется post-up, но интерфейс ещё не поднялся.
Что нужно пнуть чтобы дождалось его поднятия?

--
Peter Teslenko
Jabber: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Artem Chuprina]

Peter Teslenko - debian-russian@lists.debian.org  @ Wed, 03 Dec 2008 17:49:15 
+0300:

  Если маршрут не подымается, значит в нём что-то не так, попробуй 21
  /root/route.log в конце команд по добавлению маршрутов добавить.

 PT Вот так из interfaces

 PT [EMAIL PROTECTED]:/etc/ppp# ifup --verbose ppp0
 PT Configuring interface ppp0=ppp0 (inet)
 PT run-parts --verbose /etc/network/if-pre-up.d
 PT run-parts: executing /etc/network/if-pre-up.d/wireless-tools
 PT run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
 PT pon c1841.pptp
 PT ip r a 192.168.1.0/24 via 192.168.1.1
 PT RTNETLINK answers: No such process
 PT Failed to bring up ppp0.

 PT Т.е. честно выполняется post-up, но интерфейс ещё не поднялся.
 PT Что нужно пнуть чтобы дождалось его поднятия?

pon - это оно само придумало?  Тогда только в ppp'шных скриптах.  pon
сразу уходит в бэкграунд.  ppp'шные скрипты выполняются только после
настройки сети.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Мне еще спать под рутом (С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Покотиленко Костик]

В Срд, 03/12/2008 в 17:43 +0300, Peter Teslenko пишет:
 Andrey Nikitin wrote:
  В сообщении от 3 декабря 2008 17:26 Peter Teslenko написал(a):
  А мне не нужно чтобы менялся default gw на этот ppp.
  Мне нужно прописать доп.маршрут через него.
  
  Посмотри в каталоги /etc/ppp/ip-{up,down}/
  Может твоему скрипту (уст./удал. маршрута via ppp0) там самое правильное 
  место?
 
 В исходном сообщении я писал, что уже пытался это сделать
 
 Получается вот это
 
 RTNETLINK answers: No such process
 Failed to bring up ppp0.

Вот видишь, вот оно. Теперь я вспомнил, для ppp скрипты должны жить
в /etc/ppp/ip-[up|down].d или в файле из /etc/ppp/peers, но это не
уверен.

А так получается, что ifup интерфейс подымает мгновенно, в смысле
запускает pppd, а маршрут подымется только потом.

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: /etc/network/interfaces и pptp. Что не так?

[Alexey Boyko]

On Tuesday 02 December 2008 19:06:04 Peter Teslenko wrote:


 После поднятия интерфейса ppp0 мне нужно прописать маршрут через него.
 Пытался прописывать в /etc/network/intrfaces

 post-up ip r a 192.168.1.0/24 via 192.168.1.1
 pre-down ip r d 192.168.1.0/24 via 192.168.1.1

Так не будет работать. Наверное уже понял, почему.

 Пытался положить скрипт в /etc/ppp/ip-up.d/

А вот там должно работать. Добавь вывод отладочной информации в скрипт, чтобы 
разобраться почему ( типа 2/tmp/1.log ).

Re: /etc/network/interfaces и pptp. Что не так?

[Peter Teslenko]

Alexey Boyko wrote:

А вот там должно работать. Добавь вывод отладочной информации в скрипт, чтобы 
разобраться почему ( типа 2/tmp/1.log ).


Уже разобрался почему не работало в /etc/ppp/ip-up.d/
У меня в имени скрипта была точка, а run-parts, который вызывается из 
/etc/ppp/ip-up
этот скрипт просто не видит.

[EMAIL PROTECTED]:/etc/ppp/ip-up.d# ls -al
total 21
drwxr-xr-x 2 root root  192 2008-12-04 10:14 .
drwxr-xr-x 8 root root  544 2008-12-01 19:08 ..
-rwxr-xr-x 1 root root  891 2007-03-18 01:52 usepeerdns
-rwxr-xr-x 1 root root  467 2006-08-09 17:36 000resolvconf
-rwxr-xr-x 1 root root 4022 2007-06-11 01:13 0dns-up
-rwxr-xr-x 1 root root 1120 2007-03-21 14:17 postfix
-rwxr-xr-x 1 root root  281 2008-12-03 21:41 pptp.routes-up

[EMAIL PROTECTED]:/etc/ppp/ip-up.d# run-parts --list /etc/ppp/ip-up.d
/etc/ppp/ip-up.d/usepeerdns
/etc/ppp/ip-up.d/000resolvconf
/etc/ppp/ip-up.d/0dns-up
/etc/ppp/ip-up.d/postfix

Убрал точку - всё заработало.

--
Peter Teslenko
Jabber: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

/etc/network/interfaces и pptp. Что не т ак?

[Peter Teslenko]

Приветствую.

Прописал в /etc/network/intrfaces вот такую конструкцию

iface ppp0 inet ppp
provider c1841.pptp

/etc/ppp/peers/c1841.pptp выглядит так

remotename gw.bla-bla.ru
linkname c1841.pptp
ipparam c1841.pptp
pty /usr/sbin/pptp --loglevel 1 gw.bla-bla.ru --nolaunchpppd
name pptp
require-mppe
nomppe-stateful
noauth
lock
bsdcomp 9,15
deflate 9,15
mtu 1492
mru 1492

После поднятия интерфейса ppp0 мне нужно прописать маршрут через него.
Пытался прописывать в /etc/network/intrfaces

post-up ip r a 192.168.1.0/24 via 192.168.1.1
pre-down ip r d 192.168.1.0/24 via 192.168.1.1

Почему-то не отрабатывает.
Пытался положить скрипт в /etc/ppp/ip-up.d/
и там отслеживать одно из

IFNAME=ppp0
IPLOCAL=192.168.2.10
IPREMOTE=192.168.1.1
LINKNAME=c1841.pptp
PPP_IFACE=ppp0
PPP_IPPARAM=c1841.pptp
PPP_LOCAL=192.168.2.10
PPP_REMOTE=192.168.1.1

но почему-то и там роут не понимается.
Что я делаю не так?

--
Peter Teslenko
Jabber: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[Alexey Boyko]

В сообщении от середа, 12-бер-2008 Покотиленко Костик написал(a):

 С pptp я не работал, может кто другой подскажет логику работы. 

Ну, pptp тут запускается из pppd.

 Но на мой 
 взгляд для начала тебе надо разобраться почему при опускании интерфейса
 не выходит pppd.

Ты не понял. Я не опускаю интерфейс. Связь пропадает, pppd перезапускает pptp, 
но сам pppd не завершается, и не должен. 
Но через некторое время (дней, недель), ifupdown начинает думать, что интерфейс 
опущен.

Надо будет следующий раз проверить /etc/network/run/ifstate. Он же вроде оттуда 
читает поднят интерфейс или нет.

хм. может есть какой-то монитор за содержимым файла, чтобы в лог скидывал дату 
модификации?

-- 
JID: alexey#boyko,km,ua

Re: pptp client restart

[Покотиленко Костик]

В Чтв, 13/03/2008 в 12:05 +0200, Alexey Boyko пишет:
 В сообщении от середа, 12-бер-2008 Покотиленко Костик написал(a):
 
  С pptp я не работал, может кто другой подскажет логику работы. 
 
 Ну, pptp тут запускается из pppd.
 
  Но на мой 
  взгляд для начала тебе надо разобраться почему при опускании интерфейса
  не выходит pppd.
 
 Ты не понял. Я не опускаю интерфейс. Связь пропадает, pppd перезапускает 
 pptp, 
 но сам pppd не завершается, и не должен. 
 Но через некторое время (дней, недель), ifupdown начинает думать, что 
 интерфейс опущен.

Это уже мистика, ifupdown это не демон, следить и думать он не должен.
Сам поднял - должен знать, что поднято, пока сам не опустил. В этом 99%
и бок.

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[Alexey Boyko]

В сообщении от вівторок, 11-бер-2008 Покотиленко Костик написал(a):

   Наоборот - весьма прямо.
  те, когда pppd падает ifupdown думает, что он всё ещё порднят --- это 
  нормально, да?
 
 Архитектура решения такова, что это абсолютно нормально. У Вас с этим
 проблемы?

Значит кривая архитектура. У меня с эти проблемы. 
Во первых хуки на подъём/опускание интерфейса нужно ложить не только в 
/etc/network/if-*.d, 
но и в /etc/ppp/ip-*.d, плюс к описанному глюку наблюдал обратный. ifupdown 
думает, 
что интерфейс уже упал, а pppd ещё работает. И если я хочу сделать ifdown ppp0, 
получаю ошибку.

проверил - вот прямо щас система в таком состоянии:

# ifdown ppp0
ifdown: interface ppp0 not configured
# pidof pppd
2616
# ip link |grep ppp
2213: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast 
qlen 3
link/ppp

Я то  знаю, как сделать kill 2616, но неприятно. 
А если у меня много ppp интерфейсов? конкретно на этой машине настроен ещё 
pptpd, 
просто сейчас никто не подсоединён, который pppd килять? Это ещё дольше искать 
по логам.

То есть всё в принципе решаемо, но проблемы есть.

-- 
JID: alexey#boyko,km,ua

Re: pptp client restart

[Покотиленко Костик]

В Срд, 12/03/2008 в 12:10 +0200, Alexey Boyko пишет:
 В сообщении от вівторок, 11-бер-2008 Покотиленко Костик написал(a):
 
Наоборот - весьма прямо.
   те, когда pppd падает ifupdown думает, что он всё ещё порднят --- это 
   нормально, да?
  
  Архитектура решения такова, что это абсолютно нормально. У Вас с этим
  проблемы?
 
 Значит кривая архитектура. У меня с эти проблемы. 
 Во первых хуки на подъём/опускание интерфейса нужно ложить не только в 
 /etc/network/if-*.d, 
 но и в /etc/ppp/ip-*.d, плюс к описанному глюку наблюдал обратный. ifupdown 
 думает, 
 что интерфейс уже упал, а pppd ещё работает. И если я хочу сделать ifdown 
 ppp0, получаю ошибку.

Скажу так, у меня есть контора, в которой 5 выходов в мир, 3 из них ppp,
остальные ethernet/оптика. На каждом интерфейсе настроены достаточно
сложные правила при поднятии/опускании. Работает как часы. Поэтому
прежде чем хаять, рекомендую сначала спросить как лучше настроить. Я,
конечно, не говорю что вообще проблем не может быть...

Как делать надо: правила на ethernet вызывать через up/pre-up и
down/post-down в /etc/network/interfaces или /etc/network/if-*.d,
правила на ppp вызывать через /etc/ppp/ip-*.d. У меня так всё чётко
работает.

По поводу того, что ifdown'ом интерфейс положен, а ppp продолжает
работать - это результат неправильной настройки, такого быть не должно.
Сам подумай, сколько времени надо pppd чтобы разорвать соединение и
выйти...

 проверил - вот прямо щас система в таком состоянии:
 
 # ifdown ppp0
 ifdown: interface ppp0 not configured
 # pidof pppd
 2616
 # ip link |grep ppp
 2213: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast 
 qlen 3
 link/ppp
 
 Я то  знаю, как сделать kill 2616, но неприятно. 
 А если у меня много ppp интерфейсов? конкретно на этой машине настроен ещё 
 pptpd, 
 просто сейчас никто не подсоединён, который pppd килять? Это ещё дольше 
 искать по логам.
 
 То есть всё в принципе решаемо, но проблемы есть.
 

Возможные причины: если какой-то скрипт вызываемый по pre-up/up или
down/post-down возвращает не нулевое значение то вся процедура
поднятия/опускания (ifup iface или ifdown iface) прерывается, но то, что
на этот момент уже сделано - остаётся в силе.

Поэтому, если происходит такого рода сбой, командами ifup и ifdown уже
не вырулишь, приходится ручками подчищать: ifconfig, iptables, tc, ip.

Но повторяю, если скрипты отлажены, всё работает нормальным образом. С
pppd разберись, должен выходить мгновенно.

Может конфиги покажешь?

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[Alexey Boyko]

В сообщении от середа, 12-бер-2008 Покотиленко Костик написал(a):

 Как делать надо: правила на ethernet вызывать через up/pre-up и
 down/post-down в /etc/network/interfaces или /etc/network/if-*.d,
 правила на ppp вызывать через /etc/ppp/ip-*.d. У меня так всё чётко
 работает.

Работает. Знаю. Но именно это я и назвал кривой архитектурой, что хуки езернета 
в одном месте, 
а хуки pppd в другом месте. А опции post-up,post-down из /etc/network/intefaces 
(Полезные для одно- двух- строчных 
обработчиков для ppp не имеют смысла)
Хотя должен признать, в дебиане это сделано наиболее прямо из того, что я видел

 По поводу того, что ifdown'ом интерфейс положен, а ppp продолжает
 работать - это результат неправильной настройки, такого быть не должно.
 Сам подумай, сколько времени надо pppd чтобы разорвать соединение и
 выйти...

А я его не опускал. В interfaces стоит auto ppp0 и он при старте поднимается.
И при обрыве перезванивает. Но в какой-то момент, когда мне нужно вручную 
перезапустить получаю то, что показал. Происходит это сразу после запуска 
или потом в какой-то момент - я не проверял.

 Возможные причины: если какой-то скрипт вызываемый по pre-up/up или
 down/post-down возвращает не нулевое значение то вся процедура
 поднятия/опускания (ifup iface или ifdown iface) прерывается, но то, что
 на этот момент уже сделано - остаётся в силе.

Вот это дельный совет. Но было бы хорошо, если бы был предусмотрен какой-то 
механизм отката в случае ошибки.
Не подскажешь, как лучше найти который скрипт выдаёт ошибку?

 Но повторяю, если скрипты отлажены, всё работает нормальным образом. С
 pppd разберись, должен выходить мгновенно.

вот опустил вручную, потом опять поподнимал/поопускал.

# ifdown ppp0
ifdown: interface ppp0 not configured
# killall pppd
# ifup ppp0
# ip link |grep ppp0
2214: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast 
qlen 32
# ifdown ppp0
# ip link |grep ppp0
# ifup ppp0
# ip link |grep ppp0
2215: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast 
qlen 32

То есть после ручной починки - работает. Как долго проработает - не знаю.

 Может конфиги покажешь?

конфиги чего?

# cat /etc/ppp/peers/my_provider
name vpn_username
password vpn_password
pty pptp vpn.server --nolaunchpppd
noauth
nodefaultroute
holdoff 24
persist
maxfail 0
lock
ipparam provider
unit 0
logfile /var/log/pppd.log

# cat /etc/network/interfaces
...
iface ppp0 inet ppp
provider my_provider
...

после подключения лог заканчивается строками:
...
Script /etc/ppp/ip-up started (pid 21253)
Script /etc/ppp/ip-up finished (pid 21253), status = 0x0
...

-- 
JID: alexey#boyko,km,ua

Re: pptp client restart

[Mikhail Solovyev]

Я как-то видел, что pptp поднимался из /etc/inittab
И этот вариант обеспечивал перезапуск клиента после его падения


sergio wrote:

Всем привет.

Собсна вот сабж.

Есть машинка под дебианом. В данный момент pptp работает через
pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво.

Очень хочется, что бы при падении туннель поднимался заново..

--
sergio.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[Покотиленко Костик]

В Срд, 12/03/2008 в 13:44 +0200, Alexey Boyko пишет:
 В сообщении от середа, 12-бер-2008 Покотиленко Костик написал(a):
 
  Как делать надо: правила на ethernet вызывать через up/pre-up и
  down/post-down в /etc/network/interfaces или /etc/network/if-*.d,
  правила на ppp вызывать через /etc/ppp/ip-*.d. У меня так всё чётко
  работает.
 
 Работает. Знаю. Но именно это я и назвал кривой архитектурой, что хуки 
 езернета в одном месте, 
 а хуки pppd в другом месте. А опции post-up,post-down из 
 /etc/network/intefaces (Полезные для одно- двух- строчных 
 обработчиков для ppp не имеют смысла)
 Хотя должен признать, в дебиане это сделано наиболее прямо из того, что я 
 видел

Не могу сказать что такая архитектура мне очень нравится, но имеем то
что имеем. Другого я так понимаю просто нет.

  По поводу того, что ifdown'ом интерфейс положен, а ppp продолжает
  работать - это результат неправильной настройки, такого быть не должно.
  Сам подумай, сколько времени надо pppd чтобы разорвать соединение и
  выйти...
 
 А я его не опускал. В interfaces стоит auto ppp0 и он при старте поднимается.
 И при обрыве перезванивает. Но в какой-то момент, когда мне нужно вручную 
 перезапустить получаю то, что показал. Происходит это сразу после запуска 
 или потом в какой-то момент - я не проверял.

Вот и надо засечь на чём облом происходит. Во первых попробовать
вычислить в каких случаях ifup/ifdown чисто отрабатывает, а в каких нет.
И посмотреть на разницу между логами двух случаев.

  Возможные причины: если какой-то скрипт вызываемый по pre-up/up или
  down/post-down возвращает не нулевое значение то вся процедура
  поднятия/опускания (ifup iface или ifdown iface) прерывается, но то, что
  на этот момент уже сделано - остаётся в силе.
 
 Вот это дельный совет. Но было бы хорошо, если бы был предусмотрен какой-то 
 механизм отката в случае ошибки.
 Не подскажешь, как лучше найти который скрипт выдаёт ошибку?

Готового механизма нет. Это в винде всё готовое, зато шаг в сторону -
расстрел на месте! Середины пока нет :(

Как найти плохой скрипт:

 - методом исключения
 - использовав скрипт-прокладку, который вызывает нужный скрипт, пишет
код возврата в лог, а сам всегда возвращает 0. Этот способ мне больше
нравится даже для повседневной работы, т.к. руками не обязательно потом
подчищать.

  Но повторяю, если скрипты отлажены, всё работает нормальным образом. С
  pppd разберись, должен выходить мгновенно.
 
 вот опустил вручную, потом опять поподнимал/поопускал.
 
 # ifdown ppp0
 ifdown: interface ppp0 not configured
 # killall pppd
 # ifup ppp0
 # ip link |grep ppp0
 2214: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast 
 qlen 32
 # ifdown ppp0
 # ip link |grep ppp0
 # ifup ppp0
 # ip link |grep ppp0
 2215: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast 
 qlen 32
 
 То есть после ручной починки - работает. Как долго проработает - не знаю.
 
  Может конфиги покажешь?
 
 конфиги чего?
 
 # cat /etc/ppp/peers/my_provider
 name vpn_username
 password vpn_password
 pty pptp vpn.server --nolaunchpppd
 noauth
 nodefaultroute
 holdoff 24
 persist
 maxfail 0
 lock
 ipparam provider
 unit 0
 logfile /var/log/pppd.log
 
 # cat /etc/network/interfaces
 ...
 iface ppp0 inet ppp
 provider my_provider
 ...
 
 после подключения лог заканчивается строками:
 ...
 Script /etc/ppp/ip-up started (pid 21253)
 Script /etc/ppp/ip-up finished (pid 21253), status = 0x0
 ...

С pptp я не работал, может кто другой подскажет логику работы. Но на мой
взгляд для начала тебе надо разобраться почему при опускании интерфейса
не выходит pppd.

Если я не ошибаюсь ifup/ifdown для интерфейсов ppp пользуется командами
pon/poff, на которых тебе будет легче использовать для отладки.

-- 
Покотиленко Костик [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

pptp client restart

[sergio]

Всем привет.

Собсна вот сабж.

Есть машинка под дебианом. В данный момент pptp работает через
pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво.

Очень хочется, что бы при падении туннель поднимался заново..

--
sergio.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[Alexey Boyko]

В сообщении от вівторок, 11-бер-2008 sergio написал(a):

 Есть машинка под дебианом. В данный момент pptp работает через
 pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво.
 
 Очень хочется, что бы при падении туннель поднимался заново..

Мне тоже кажется что pppd из ifupdown запускается несколько криво, 
но вот автопередозвон таки работает, хоть и не средствами ifupdown, 
а средствами pppd. Опции persist, maxfail и holdoff

-- 
JID: alexey#boyko,km,ua

Re: pptp client restart

[Alexander GQ Gerasiov]

Tue, 11 Mar 2008 18:30:36 +0300
sergio [EMAIL PROTECTED] wrote:

 Всем привет.
 
 Собсна вот сабж.
 
 Есть машинка под дебианом. В данный момент pptp работает через
 pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво.
Наоборот - весьма прямо.

 
 Очень хочется, что бы при падении туннель поднимался заново..
persist, maxfail


-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail:[EMAIL PROTECTED] Jabber:  [EMAIL PROTECTED]
 Homepage:  http://gq.net.ru ICQ: 7272757
 PGP fingerprint: 0628 ACC7 291A D4AA 6D7D  79B8 0641 D82A E3E3 CE1D


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[sergio]

Alexey Boyko wrote:

В сообщении от вівторок, 11-бер-2008 sergio написал(a):


Есть машинка под дебианом. В данный момент pptp работает через
pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво.

Очень хочется, что бы при падении туннель поднимался заново..


Мне тоже кажется что pppd из ifupdown запускается несколько криво, 
но вот автопередозвон таки работает, хоть и не средствами ifupdown, 
а средствами pppd. Опции persist, maxfail и holdoff

а я искал reconnect и redial..
спасибо

--
sergio.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp client restart

[sergio]

Alexander GQ Gerasiov wrote:

Tue, 11 Mar 2008 18:30:36 +0300
sergio [EMAIL PROTECTED] wrote:


Всем привет.

Собсна вот сабж.

Есть машинка под дебианом. В данный момент pptp работает через
pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво.

Наоборот - весьма прямо.
те, когда pppd падает ifupdown думает, что он всё ещё порднят --- это 
нормально, да?



Очень хочется, что бы при падении туннель поднимался заново..

persist, maxfail

спасибо

--
sergio.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

падает инет при подключении pptp

[Sergey Kharlamov]

Добрый день. Столкнулся с проблемой: настроил у себе сервер pptp. Когда
пользователь конектица к моему серверу ровно через 30 секунд пинги перестают
ходит с компа пользователя и на сервере тоже пропадает пинг в инет.
Соединение с инетом происходит через соседнюю машину на которой настроен
MASQUERADE. В чем может быть проблема?
-- 
---
Best Regards
Kharlamov Sergey

Re: падает инет при подключении pptp

[Mikhail A Antonov]

On 23 декабря 2007, Sergey Kharlamov wrote:
  Добрый день. Столкнулся с проблемой: настроил у себе сервер pptp. Когда
  пользователь конектица к моему серверу ровно через 30 секунд пинги
 перестают ходит с компа пользователя и на сервере тоже пропадает пинг в
 инет. Соединение с инетом происходит через соседнюю машину на которой
 настроен MASQUERADE. В чем может быть проблема?

Маршруты сбиваются?
Может у тебя IP-сети не правильно настроены, через 30 сек из ARP-таблицы 
пропадает MAC роутера в инет и все отваливается.

-- 
Best regards,
 Mikhail
Bart-mdv- @ SolarNet
IRC: irc.solarnet.ru
WWW: http://www.solarnet.ru/

--
Ликвидация границ часто означает выдвижение фронтов.
-- Евгений Кащеев


signature.asc
Description: This is a digitally signed message part.

Re: падает инет при подключении pptp

[Mikhail A Antonov]

On 23 декабря 2007, Sergey Kharlamov wrote:
  После отключения vpn на клиентской машине пинги вновь нормально ходят...

Я тебе и говорю - сбиваются маршруты. У pptp-клиента и у аплинка твоего должны 
быть разные подсети. Иначе ничего работать не будет.

P.S. В личку не надо писать.

-- 
Best regards,
 Mikhail
Bart-mdv- @ SolarNet
IRC: irc.solarnet.ru
WWW: http://www.solarnet.ru/

--
Женщина побеждает как реклама: повторяя одно и то же.
-- Янина Ипохорская


signature.asc
Description: This is a digitally signed message part.

Re: падает инет при подкл ючении pptp

[alex kuklin]

Mikhail A Antonov wrote:

On 23 декабря 2007, Sergey Kharlamov wrote:
  

 После отключения vpn на клиентской машине пинги вновь нормально ходят...


Я тебе и говорю - сбиваются маршруты. У pptp-клиента и у аплинка твоего должны 
быть разные подсети. Иначе ничего работать не будет.
  

Чего?

Может, просто не включать defaultroute на сервере?
А вообще, крайне желательно изучить основы TCP/IP, многие вопросы сами 
отпадут.

Еще изучить, что такое proxyarp и зачем он нужен.

--
Alex


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: падает инет при подключении pptp

[Mikhail A Antonov]

On 23 декабря 2007, alex kuklin wrote:
  Может, просто не включать defaultroute на сервере?
  А вообще, крайне желательно изучить основы TCP/IP, многие вопросы сами
  отпадут.
  Еще изучить, что такое proxyarp и зачем он нужен.
Гм, может я не правильно выразился, но именно это я и имел ввиду :-)

-- 
Best regards,
 Mikhail
Bart-mdv- @ SolarNet
IRC: irc.solarnet.ru
WWW: http://www.solarnet.ru/

--
Крепка рать воеводою.
-- Русская пословица


signature.asc
Description: This is a digitally signed message part.

Re: troubles with mppe radius plugin in pptp vpn

[Konstantin Kubatkin]

Добрый день, обнаружил странный глюк: при подключении по pptp с 
авторизацией через радиус (plugin radius.so в опциях ppp) не работает 
mppe шифрование, если отключить плагин и авторизоватся через 
chap-secrets то все ок.


у меня радиус добавляет в ответ вот такое:

MS-MPPE-Encryption-Policy = 0x0001,
MS-MPPE-Encryption-Types = 0x0006,

или как-то так

еще в настройках самого радиуса ( у меня freeradius ) есть настроки mppe

--
Konstantin Kubatkin [KUB-RIPE] [KUB-UANIC]
Kherson, TriLogiC Group
Fido: 2:468/[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

troubles with mppe radius plugin in pptp vpn

[Артем Пастухов]

Добрый день, обнаружил странный глюк: при подключении по pptp с авторизацией
через радиус (plugin radius.so в опциях ppp) не работает mppe шифрование,
если отключить плагин и авторизоватся через chap-secrets то все ок.
логи:
c radius:
Jun  1 10:18:35 gate pppd[2925]: RADATTR plugin wrote 4 line(s) to file
/var/run/radattr.ppp0.
Jun  1 10:18:35 gate pppd[2925]: sent [CHAP Success id=0xd9
S=DBCEA18FDDB307F1EA21F8D04406A816B20DD697]
Jun  1 10:18:35 gate pppd[2925]: sent [LCP TermReq id=0x2 MPPE required but
not available]
Jun  1 10:18:35 gate pppd[2925]: rcvd [CCP ConfReq id=0x4 mppe +H +M +S +L
-D +C]
Jun  1 10:18:35 gate pppd[2925]: Discarded non-LCP packet when LCP not open
Jun  1 10:18:35 gate pppd[2925]: rcvd [IPCP ConfReq id=0x5 addr 0.0.0.0
ms-dns1 0.0.0.0 ms-wins 0.0.0.0 ms-dns3 0.0.0.0 ms-wins 0.0.0.0]
Jun  1 10:18:35 gate pppd[2925]: Discarded non-LCP packet when LCP not open
Jun  1 10:18:35 gate pppd[2925]: rcvd [LCP TermAck id=0x2 MPPE required but
not available]
Jun  1 10:18:35 gate pppd[2925]: RADATTR plugin removed file
/var/run/radattr.ppp0.

c chap-secrets:
Jun  1 09:38:25 gate pppd[6785]: sent [LCP ConfReq id=0x1 asyncmap 0x0
auth chap MS-v2 magic 0x36554d26 pcomp accomp]
Jun  1 09:38:25 gate pppd[6785]: rcvd [LCP ConfReq id=0x0 mru 1400 magic
0x51370ed8 pcomp accomp callback CBCP]
Jun  1 09:38:25 gate pppd[6785]: sent [LCP ConfRej id=0x0 callback CBCP]
Jun  1 09:38:25 gate pppd[6785]: rcvd [LCP ConfReq id=0x1 mru 1400 magic
0x51370ed8 pcomp accomp]
Jun  1 09:38:25 gate pppd[6785]: sent [LCP ConfAck id=0x1 mru 1400 magic
0x51370ed8 pcomp accomp]
Jun  1 09:38:28 gate pppd[6785]: sent [LCP ConfReq id=0x1 asyncmap 0x0
auth chap MS-v2 magic 0x36554d26 pcomp accomp]
Jun  1 09:38:28 gate pppd[6785]: rcvd [LCP ConfAck id=0x1 asyncmap 0x0
auth chap MS-v2 magic 0x36554d26 pcomp accomp]
Jun  1 09:38:28 gate pppd[6785]: sent [LCP EchoReq id=0x0 magic=0x36554d26]
Jun  1 09:38:28 gate pppd[6785]: sent [CHAP Challenge id=0x21
a18e4aadb6d24827ad4b25a485565636, name = gate]
Jun  1 09:38:28 gate pppd[6785]: rcvd [LCP Ident id=0x2 magic=0x51370ed8 
MSRASV5.10]
Jun  1 09:38:28 gate pppd[6785]: rcvd [LCP Ident id=0x3 magic=0x51370ed8
MSRAS-0-JULIA]
Jun  1 09:38:28 gate pppd[6785]: rcvd [LCP EchoRep id=0x0 magic=0x51370ed8]
Jun  1 09:38:28 gate pppd[6785]: rcvd [CHAP Response id=0x21
0303dc2928db5c81b0ab583deb541743215f649c77cd8adb57b17023d15a8b
fb1100b2bda82a892b00, name = 123]
Jun  1 09:38:28 gate pppd[6785]: RADATTR plugin wrote 4 line(s) to file
/var/run/radattr.ppp0.
Jun  1 09:38:28 gate pppd[6785]: sent [CHAP Success id=0x21
S=19640EC96068F43C05951FD3206A512CCDCB0A69]
Jun  1 09:38:28 gate pppd[6785]: sent [CCP ConfReq id=0x1 deflate 15
deflate(old#) 15 bsd v1 15]
Jun  1 09:38:28 gate pppd[6785]: sent [IPCP ConfReq id=0x1 compress VJ 0f
01 addr 192.168.1.7]
Jun  1 09:38:28 gate pppd[6785]: rcvd [CCP ConfReq id=0x4 mppe +H +M +S +L
-D +C]
Jun  1 09:38:28 gate pppd[6785]: sent [CCP ConfRej id=0x4 mppe +H +M +S +L
-D +C]
Jun  1 09:38:28 gate pppd[6785]: rcvd [IPCP ConfReq id=0x5 addr 0.0.0.0
ms-dns1 0.0.0.0 ms-wins 0.0.0.0 ms-dns3 0.0.0.0 ms-wins 0.0
.0.0]
Jun  1 09:38:28 gate pppd[6785]: sent [IPCP ConfNak id=0x5 addr
192.168.1.16 ms-dns1 192.168.1.3 ms-wins 192.168.1.3 ms-dns3 192.168.
1.3 ms-wins 192.168.1.3]
Jun  1 09:38:28 gate pppd[6785]: rcvd [CCP ConfRej id=0x1 deflate 15
deflate(old#) 15 bsd v1 15]
Jun  1 09:38:28 gate pppd[6785]: sent [CCP ConfReq id=0x2]
Jun  1 09:38:28 gate pppd[6785]: rcvd [IPCP ConfRej id=0x1 compress VJ 0f
01]
Jun  1 09:38:28 gate pppd[6785]: sent [IPCP ConfReq id=0x2 addr 192.168.1.7

]

Jun  1 09:38:28 gate pppd[6785]: rcvd [LCP TermReq id=0x6
Q7\016\330\000\315t\000\000\002\346]
Jun  1 09:38:28 gate pppd[6785]: sent [LCP TermAck id=0x6]


Пришлось пока шифрование отключить, благо что трафик шифруется на уровне
приложения

pptpd.conf:

option /etc/ppp/options.pptpd
bcrelay eth0
localip 192.168.1.7
remoteip 192.168.1.16-31

options.pptpd:
lock
auth
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
proxyarp
debug
ms-dns 192.168.1.3
ms-wins 192.168.1.3
plugin radius.so
plugin radattr.so

без радиуса соответственно options.pptpd:
lock
auth
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe
proxyarp
debug
ms-dns 192.168.1.3
ms-wins 192.168.1.3

Это баг или я маны недокурил?

pptp-linux mpd

[Dmitry E. Oboukhov]

провайдер тут потихоньку переводит сетку с какого-то vpn-сервера на mpd.
ну и сделали они mpd-сервер в локалке к которому можно коннектиться.
старый тоже работает.

новый сервак только IP-шником отличается, а коннект на них оба
одинаковый: конфиги/роутинги/удаленные IP-шники итп.

так вот, когда коннектимся к mpd-серверу сеть работает: только пинги
ходят, остальные протоколы по таймаутам выпадают,
а к старому vpn - сеть нормально работает.

я полазил по инету с такой проблемой vs mpd куча народу сталкивалась, но
решения не нашел, только вопросы в инете и есть.

никто не сталкивался?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp-linux mpd

[Oleg Tsymaenko]

В сообщении от 28 ноября 2006 10:24 Dmitry E. Oboukhov написал(a):
 провайдер тут потихоньку переводит сетку с какого-то vpn-сервера на mpd.
 ну и сделали они mpd-сервер в локалке к которому можно коннектиться.
 старый тоже работает.

 новый сервак только IP-шником отличается, а коннект на них оба
 одинаковый: конфиги/роутинги/удаленные IP-шники итп.

 так вот, когда коннектимся к mpd-серверу сеть работает: только пинги
 ходят, остальные протоколы по таймаутам выпадают,
 а к старому vpn - сеть нормально работает.

 я полазил по инету с такой проблемой vs mpd куча народу сталкивалась, но
 решения не нашел, только вопросы в инете и есть.

 никто не сталкивался?
выпиши что пишет route -n после поднятия соединения

-- 
Oleg Tsymaenko [EMAIL PROTECTED] LA4791-RIPE; TO2-UANIC;
http://lafox.net/  -  Free Software Distribution Center;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

pptp-linux mpd

[Dmitry E. Oboukhov]

On 11:42 Tue 28 Nov , Oleg Tsymaenko wrote:
 В сообщении от 28 ноября 2006 10:24 Dmitry E. Oboukhov написал(a):
  провайдер тут потихоньку переводит сетку с какого-то vpn-сервера на mpd.
  ну и сделали они mpd-сервер в локалке к которому можно коннектиться.
  старый тоже работает.
 
  новый сервак только IP-шником отличается, а коннект на них оба
  одинаковый: конфиги/роутинги/удаленные IP-шники итп.
 
  так вот, когда коннектимся к mpd-серверу сеть работает: только пинги
  ходят, остальные протоколы по таймаутам выпадают,
  а к старому vpn - сеть нормально работает.
 
  я полазил по инету с такой проблемой vs mpd куча народу сталкивалась, но
  решения не нашел, только вопросы в инете и есть.
 
  никто не сталкивался?
 выпиши что пишет route -n после поднятия соединения
я с этого и начал
список ровно такой же как и со старым сервером.

default gw становится на P-t-P хост ppp-соединения (то есть в моем
случае на 1.1.1.1), а остальная таблица роутингов не меняется.

я pppd пускаю с ключом replacedefaultroute.

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
1.1.1.1 0.0.0.0 255.255.255.255 UH0  00 ppp0
212.118.45.128  10.4.0.1255.255.255.128 UG0  00 eth0
10.255.3.0  0.0.0.0 255.255.255.0   U 0  00 wlan0
10.255.1.0  0.0.0.0 255.255.255.0   U 0  00 eth1
195.250.55.010.4.0.1255.255.255.0   UG0  00 eth0
10.4.0.00.0.0.0 255.255.255.0   U 0  00 eth0
62.140.242.010.4.0.1255.255.255.0   UG0  00 eth0
212.118.37.010.4.0.1255.255.255.0   UG0  00 eth0
212.118.55.010.4.0.1255.255.255.0   UG0  00 eth0
212.118.54.010.4.0.1255.255.255.0   UG0  00 eth0
195.91.159.010.4.0.1255.255.255.0   UG0  00 eth0
62.140.240.010.4.0.1255.255.254.0   UG0  00 eth0
85.142.16.0 10.4.0.1255.255.252.0   UG0  00 eth0
195.225.128.0   10.4.0.1255.255.252.0   UG0  00 eth0
81.88.112.0 10.4.0.1255.255.240.0   UG0  00 eth0
81.9.48.0   10.4.0.1255.255.240.0   UG0  00 eth0
81.222.176.010.4.0.1255.255.240.0   UG0  00 eth0
217.70.16.0 10.4.0.1255.255.240.0   UG0  00 eth0
81.88.208.0 10.4.0.1255.255.240.0   UG0  00 eth0
80.86.240.0 10.4.0.1255.255.240.0   UG0  00 eth0
84.23.32.0  10.4.0.1255.255.224.0   UG0  00 eth0
192.168.0.0 10.4.0.1255.255.0.0 UG0  00 eth0
172.16.0.0  10.4.0.1255.240.0.0 UG0  00 eth0
10.0.0.010.4.0.1255.0.0.0   UG0  00 eth0
0.0.0.0 1.1.1.1 0.0.0.0 UG0  00 ppp0

все что идет через 10.4.0.1 - локалка провайдера.
ну а 10.255 - несколько моих локалок.
таблица роутинга при коннекте на второй vpn сервер ровно такая же 
(сервер дает нам тот же IP и гейт мы через него используем тот же)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

iptraf и pptp

[Stanislav Maslovski]

Хост ходит в инет через ppp0 (VPN), LAN висит на eth0. Пакеты до VPN access
server-a идут через некий гейт, доступный с eth0.

Это правильно, что в iptraf в выводе LAN station monitor отображается
_два_ разных HW address: один - MAC гейта, и другой, похожий на местный MAC
хоста, но не он. Это из-за туннеля так?

По статистике видно, что все пакеты туда и обратно идут как-бы через этот
левый MAC. Что вводит меня в некий предпаранойдальный ступор.

-- 
Станислав

pptp соединение рвётся пр и запуске p2p приложений

[Alexander Sitnik]

Здраствуйте.
Есть такая проблема: соединение с провайдером идёт через pptp, в общем
оно работает нормально, по несколько суток неразрывается. Но при запуске
разных p2p программ (amule,bittorentgui) соединение разрывается через
несколько минут. В логах ничего нет, пробовал пускать pon icpptp debug
dump logfd 2 nodetach как советовали на pptpclient.sf.net, но ничего
подозрительного он не сообщает, лог прилагается. Притом винда с eMule
работает нормально, соединение не рвётся. В чём может быть проблема?
pppd options in effect:
debug   # (from command line)
nodetach# (from command line)
logfd 2 # (from command line)
dump# (from command line)
noauth  # (from /etc/ppp/options.pptp)
name pwsas  # (from /etc/ppp/peers/icpptp)
remotename PPTP # (from /etc/ppp/peers/icpptp)
# (from /etc/ppp/options.pptp)
pty pptp 192.168.149.1 --nolaunchpppd   # (from /etc/ppp/peers/icpptp)
crtscts # (from /etc/ppp/options)
# (from /etc/ppp/options)
asyncmap 0  # (from /etc/ppp/options)
lcp-echo-failure 4  # (from /etc/ppp/options)
lcp-echo-interval 30# (from /etc/ppp/options)
hide-password   # (from /etc/ppp/options)
ipparam icpptp  # (from /etc/ppp/peers/icpptp)
proxyarp# (from /etc/ppp/options)
nobsdcomp   # (from /etc/ppp/options.pptp)
nodeflate   # (from /etc/ppp/options.pptp)
noipx   # (from /etc/ppp/options)
using channel 2
Using interface ppp0
Connect: ppp0 -- /dev/pts/1
sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0xb3517224 pcomp accomp]
rcvd [LCP ConfReq id=0x1 auth chap MD5 magic 0xa892ca64]
sent [LCP ConfAck id=0x1 auth chap MD5 magic 0xa892ca64]
rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0xb3517224 pcomp accomp]
sent [LCP EchoReq id=0x0 magic=0xb3517224]
rcvd [CHAP Challenge id=0x1 fb44a8fe573f925145280ed28b16772b, name = icpptp]
sent [CHAP Response id=0x1 43be4b9cddc0bd1568806e4164acdaa8, name = pwxxx]
rcvd [LCP EchoRep id=0x0 magic=0xa892ca64]
rcvd [CHAP Success id=0x1 ]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 compress VJ 0f 01 addr 0.0.0.0]
rcvd [IPCP ConfReq id=0x1 compress VJ 0f 01 addr 195.98.64.240]
sent [IPCP ConfAck id=0x1 compress VJ 0f 01 addr 195.98.64.240]
rcvd [IPCP ConfNak id=0x1 addr 217.25.224.51]
sent [IPCP ConfReq id=0x2 compress VJ 0f 01 addr 217.25.224.51]
rcvd [IPCP ConfAck id=0x2 compress VJ 0f 01 addr 217.25.224.51]
Cannot determine ethernet address for proxy ARP
local  IP address 217.25.224.51
remote IP address 195.98.64.240
Script /etc/ppp/ip-up started (pid 24148)
Script /etc/ppp/ip-up finished (pid 24148), status = 0x0
Modem hangup
Connect time 12.3 minutes.
Sent 13196386 bytes, received 2722754 bytes.
Script /etc/ppp/ip-down started (pid 24703)
Connection terminated.
Script pptp 192.168.149.1 --nolaunchpppd finished (pid 24142), status = 0x0
Waiting for 1 child processes...
  script /etc/ppp/ip-down, pid 24703
Script /etc/ppp/ip-down finished (pid 24703), status = 0x0

Re: pptp over ppp

[Alexey Lobanov]

Добрый день.

On 15/10/06 21:35, Nicholas wrote:


abraham shapirus wrote:



Так все-таки openvpn или pptp нужно поднять?



Есть такое мнение, что pptp работает по gre протоколу.
Используется openvpn на сервере и openvpn gui у клиента.


То есть pptp вроде как не имеет отношения к делу. Как и вся первая фраза 
из двух вышепроцитированных.



И в чем проблема?


Проблема в том, что сервер работает нормально, а вот у одного из 
клиентов на w2000 и диалапом вылетает такая ошибка:


Sat Oct 07 05:07:17 2006 route DELETE 0.0.0.0 MASK 0.0.0.0 217.107.236.217
Sat Oct 07 05:07:17 2006 Route deletion via IPAPI succeeded
Sat Oct 07 05:07:17 2006 route ADD 0.0.0.0 MASK 0.0.0.0 192.168.231.5
Sat Oct 07 05:07:17 2006 Warning: route gateway is not reachable on any 
active network adapters: 192.168.231.5

Sat Oct 07 05:07:17 2006 Route addition via IPAPI failed
Sat Oct 07 05:07:17 2006 Initialization Sequence Completed With Errors


А можно подробнее? Конфигурацию OpenVPN, откуда берётся адрес 
192.168.231.5 и что написано в конфигурации на обоих концах по поводу 
маршрутизации. Про 217.107.236.217 вопросов нет:


217.236.107.217.in-addr.arpa domain name pointer 217.236.dialup.mari-el.ru.

А.Л.








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp over ppp

[Nicholas]

abraham shapirus wrote:

Так все-таки openvpn или pptp нужно поднять?

Есть такое мнение, что pptp работает по gre протоколу.
Используется openvpn на сервере и openvpn gui у клиента.

И в чем проблема?
Проблема в том, что сервер работает нормально, а вот у одного из 
клиентов на w2000 и диалапом вылетает такая ошибка:


Sat Oct 07 05:07:17 2006 route DELETE 0.0.0.0 MASK 0.0.0.0 217.107.236.217
Sat Oct 07 05:07:17 2006 Route deletion via IPAPI succeeded
Sat Oct 07 05:07:17 2006 route ADD 0.0.0.0 MASK 0.0.0.0 192.168.231.5
Sat Oct 07 05:07:17 2006 Warning: route gateway is not reachable on any 
active network adapters: 192.168.231.5

Sat Oct 07 05:07:17 2006 Route addition via IPAPI failed
Sat Oct 07 05:07:17 2006 Initialization Sequence Completed With Errors


--
Best regards,
Nicholas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

pptp over ppp

[Nicholas]

Столкнулся с проблемой - не подмимается openvpn киент при диалапном 
доступе в сеть. Есть мнение что pptp over ppp просто делать нельзя.
Вопрос: можно ли теоретически поднять openvpn туннель при диалапном 
соединении?

--
Best regards,
Nicholas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp over ppp

[abraham shapirus]

On Sat, 14 Oct 2006, Nicholas wrote:

N Столкнулся с проблемой - не подмимается openvpn киент при диалапном доступе в
N сеть. Есть мнение что pptp over ppp просто делать нельзя.
N Вопрос: можно ли теоретически поднять openvpn туннель при диалапном
N соединении?
Так все-таки openvpn или pptp нужно поднять?
И в чем проблема?

Re: pptp over ppp

[Kirill Shatalaev]

Nicholas пишет:
Столкнулся с проблемой - не подмимается openvpn киент при диалапном 
доступе в сеть. Есть мнение что pptp over ppp просто делать нельзя.
Вопрос: можно ли теоретически поднять openvpn туннель при диалапном 
соединении?


Никаких запретов на поднятие vpn (pptp), gre и openvpn через ppp нет.
Можешь подробнее в чём проблема?

--
С наилучшими,
Кирилл Шаталаев.

begin:vcard
fn:Kirill Shatalaev
n:Shatalaev;Kirill
email;internet:[EMAIL PROTECTED]
version:2.1
end:vcard

Re: pptp и хренов пров

[Stanislav Maslovski]

On Mon, Jun 05, 2006 at 08:53:49PM +0400, Andrey Melnikoff wrote:
 Stanislav Maslovski [EMAIL PROTECTED] wrote:
  Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
  buffering packet 101906 (expecting 101903, lost or reordered) 
  В преизрядном количестве. Это нормально?
 Ага. я наблюдаю такое на WiFi линке, для него это нормально. Для ethernetа -
 наврядли. Попробуй подкрутить таймауты для реордеринга.

Вчера собрал 2.6.16.20. После ночи активного скачивания в логах сообщений о
потерянных пакетах _нет_. Подозреваю, что виноват forcedeth в 2.4.33-pre3.

  Дальше, раз в 2 дня происходит вот что:
 
  Jun  4 18:04:10 localhost pptp[296]: anon log[ctrlp_rep:pptp_ctrl.c:243]:
  Sent control packet type is 12 'Call-Clear-Request'

[скипнуто]

 pptp как честный, хоть и заметил то, что сеть уже рухнула и на echo ему
 никто не ответил, тем неменее пытается серверу сообщить, что он отключается.

Не хочу раньше времени делать выводы, но, в принципе, могло быть и такое,
что свитч вешался из-за некорректной работы forcedeth. На эту мысль наводит
повторяемость сценария - длинная серия reordered пакетов в логах, сразу после
которой сетка уходила в даун.

-- 
Cтанислав

Re: pptp и хренов пров

[Stanislav Maslovski]

On Sun, Jun 04, 2006 at 09:11:17PM +0400, Stanislav Maslovski wrote:
 gateway в дауне, не пингуется, no route to host.
 ^^
Тут очепятка. Следует читать Destination Host Unreachable.

-- 
Cтанислав

Re: pptp и хренов пров

[Andrey Melnikoff]

Stanislav Maslovski [EMAIL PROTECTED] wrote:
 Доброго времени суток,

 Имеем:
 самосборное ядро 2.4.33-pre3 c GRE tunnels;
 pptp-linux 1.5.0-5;
 тупого провайдера с VPN;

 В логи сыплются вот такие сообщения

 Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
 buffering packet 101904 (expecting 101903, lost or reordered) 
 Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
 buffering packet 101905 (expecting 101903, lost or reordered) 
 Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
 buffering packet 101906 (expecting 101903, lost or reordered) 
 В преизрядном количестве. Это нормально?
Ага. я наблюдаю такое на WiFi линке, для него это нормально. Для ethernetа -
наврядли. Попробуй подкрутить таймауты для реордеринга.

 Дальше, раз в 2 дня происходит вот что:

 Jun  4 18:04:10 localhost pptp[296]: anon log[ctrlp_rep:pptp_ctrl.c:243]:
 Sent control packet type is 12 'Call-Clear-Request'

 Jun  4 18:04:10 localhost pptp[296]: anon 
 log[pptp_conn_close:pptp_ctrl.c:425]: 
 Closing PPTP connection 
 Jun  4 18:04:10 localhost pptp[296]: anon log[ctrlp_rep:pptp_ctrl.c:243]:
 Sent control packet type is 3 'Stop-Control-Connection-Request' 
   ^
 Jun  4 18:04:10 localhost pptp[296]: anon 
 log[call_callback:pptp_callmgr.c:77]: 
 Closing connection 
 Jun  4 18:04:10 localhost pppd[286]: Modem hangup 
 Jun  4 18:04:10 localhost pppd[286]: Connect time 102.0 minutes. 
 Jun  4 18:04:10 localhost pppd[286]: Sent 55451375 bytes, received 74552026 
 bytes. 
 Jun  4 18:04:10 localhost pppd[286]: Connection terminated. 

 После чего pppd несколько раз пытается снова поднять соединение
 (ему сказано persist), но безуспешно. Смотрим, что с локалкой: недоступна,
 gateway в дауне, не пингуется, no route to host.
 arp на eth0 не видит ни черта.

 Приходящие мальчики перегружают свитч на чердаке, после чего все снова
 работает до следующего обвала. Собственно, второй вопрос по отмеченному 
 .
 Это _с_моей_стороны_ pptp пытается завершить соединение, когда уже сетка ушла 
 в
 даун? 

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

pptp и хренов пров

[Stanislav Maslovski]

Доброго времени суток,

Имеем:
самосборное ядро 2.4.33-pre3 c GRE tunnels;
pptp-linux 1.5.0-5;
тупого провайдера с VPN;

В логи сыплются вот такие сообщения

Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
buffering packet 101904 (expecting 101903, lost or reordered) 
Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
buffering packet 101905 (expecting 101903, lost or reordered) 
Jun  4 17:58:38 localhost pptp[290]: anon log[decaps_gre:pptp_gre.c:404]:
buffering packet 101906 (expecting 101903, lost or reordered) 

В преизрядном количестве. Это нормально?

Дальше, раз в 2 дня происходит вот что:

Jun  4 18:04:10 localhost pptp[296]: anon log[ctrlp_rep:pptp_ctrl.c:243]:
Sent control packet type is 12 'Call-Clear-Request'
   
Jun  4 18:04:10 localhost pptp[296]: anon log[pptp_conn_close:pptp_ctrl.c:425]: 
Closing PPTP connection 
Jun  4 18:04:10 localhost pptp[296]: anon log[ctrlp_rep:pptp_ctrl.c:243]:
Sent control packet type is 3 'Stop-Control-Connection-Request' 
  ^
Jun  4 18:04:10 localhost pptp[296]: anon log[call_callback:pptp_callmgr.c:77]: 
Closing connection 
Jun  4 18:04:10 localhost pppd[286]: Modem hangup 
Jun  4 18:04:10 localhost pppd[286]: Connect time 102.0 minutes. 
Jun  4 18:04:10 localhost pppd[286]: Sent 55451375 bytes, received 74552026 
bytes. 
Jun  4 18:04:10 localhost pppd[286]: Connection terminated. 

После чего pppd несколько раз пытается снова поднять соединение
(ему сказано persist), но безуспешно. Смотрим, что с локалкой: недоступна,
gateway в дауне, не пингуется, no route to host.
arp на eth0 не видит ни черта.

Приходящие мальчики перегружают свитч на чердаке, после чего все снова
работает до следующего обвала. Собственно, второй вопрос по отмеченному .
Это _с_моей_стороны_ pptp пытается завершить соединение, когда уже сетка ушла в
даун? 

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

-- 
Cтанислав

pptp

[Sergievskaya Irina]

Hello
Помогите, плз, настроить сабж.
Надо прозвонится на VPN (в винде устанавливается
необязательное шифрование) с использованием протокола chap.
пакет уже установлен.
Надо настроить.
Находила информацию о pptp-client но не могу запустить.
К примеру запустить pptp-command не могу.
или что как конфигурить? Как потом запускать соединение?


-- 
Best regards,
 Sergievskaya  mailto:[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pptp

[Hodot D.A.]

В сообщении от 5 Май 2006 09:17 Sergievskaya Irina написал(a):
 Hello
 Помогите, плз, настроить сабж.
 Надо прозвонится на VPN (в винде устанавливается
 необязательное шифрование) с использованием протокола chap.
 пакет уже установлен.
 Надо настроить.
 Находила информацию о pptp-client но не могу запустить.
 К примеру запустить pptp-command не могу.
 или что как конфигурить? Как потом запускать соединение?

#file /etc/ppp/options.pptp
lock
+chap
nobsdcomp
noauth
nodeflate
ipparam ai
defaultroute

#file /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# clientserver  secret  IP addresses
user * password

#file /etc/ppp/peers/atlant
pty pptp 10.0.78.1 --nolaunchpppd
name user
remotename pptp
file /etc/ppp/options.pptp

запускается командой pon atlant, выключается poff
для юзера можно прописать в sudo
стоит заметить что сервер на который идёт прозвон, в данном случае это 
10.0.78.1 должен быть прописан в таблице маршрутов как хост, тоесть командой 
наподобии route add -host 10.0.78.1 gw 172.31.5.52 wlan0

-- 
Best regards,
Dmitry Hodot
E-mail: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]