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
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
On Wed, 28 Jun 2017 11:13:18 +0300 Михаил Касаджиков 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
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 писал(а) в своём письме Wed, 28 Jun 2017 13:53:51 +0300: On Wed, Jun 28, 2017 at 11:13:18AM +0300, Михаил Касаджиков wrote: Andrey Tataranovich писал(а) в своём письме 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
On Wed, Jun 28, 2017 at 11:13:18AM +0300, Михаил Касаджиков wrote: > Andrey Tataranovich писал(а) в своём письме 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 писал(а) в своём письме 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
On Wed, 28 Jun 2017 00:07:14 +0700 Леонид Кальмаев 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
Доброго времени суток. Имеется сервер на 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
Re: Настройка pptp в debian squeeze
19 августа 2012 г., 23:24 пользователь Dmitry A. Zhiglov < dmitry.zhig...@gmail.com> написал: > 19 августа 2012 г., 22:39 пользователь Фёдор Елизаров > написал: > > > > > > Вообщем либо я дурак полный, либо что то в системе не так > > Всегда пользовался 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 г., 22:39 пользователь Фёдор Елизаров написал: > > > Вообщем либо я дурак полный, либо что то в системе не так > Всегда пользовался NetworkManager,но он сеть не поднимает да и вообще надоел. > Решил как полагается просто конфиги настроить и забыть про подключение > отключение > И тут началось то одно не пашет то другое не пашет то вроде всё пашет но > ничего не пашет дурдом вообщем. > Приводить конфиги тут я не буду , а лучше попрошу выложить свои , так думаю > будет проще понять что у меня не так. > Пожалуйста выложите рабочие конфиги pptp соединения > > /etc/ppp/options.pptp > /etc/ppp/options > /etc/ppp/pers > > спасибо Может тут есть ответ? http://wiki.debian.org/ru/pptp-linux
Настройка pptp в debian squeeze
Вообщем либо я дурак полный, либо что то в системе не так Всегда пользовался NetworkManager,но он сеть не поднимает да и вообще надоел. Решил как полагается просто конфиги настроить и забыть про подключение отключение И тут началось то одно не пашет то другое не пашет то вроде всё пашет но ничего не пашет дурдом вообщем. Приводить конфиги тут я не буду , а лучше попрошу выложить свои , так думаю будет проще понять что у меня не так. Пожалуйста выложите рабочие конфиги pptp соединения /etc/ppp/options.pptp /etc/ppp/options /etc/ppp/pers спасибо
Re: debian + hostapd + pptp = pptp random disconnect
> Смотрим в превое сообщение и видим > >>$ 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 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
Похоже проблема была не в карточке 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] [] ? warn_slowpath_common+0x68/0x79 May 25 17:32:33 debian kernel: [519404.008514] [] ? dev_watchdog+0xb1/0x104 May 25 17:32:33 debian kernel: [519404.008531] [] ? warn_slowpath_fmt+0x29/0x2d May 25 17:32:33 debian kernel: [519404.008546] [] ? dev_watchdog+0xb1/0x104 May 2
Re: debian + hostapd + pptp = pptp random disconnect
Отключил я трикомовскую карточку. Поднимаю впн на риелтеке - всё работает. -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
Gary Trotcko wrote: > 2012/5/18 Andrey Tataranovich : > > Выкинь ты свой 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
19:12 Fri 18 May, Gary Trotcko wrote: > 2012/5/18 Andrey Tataranovich : > > > Выкинь ты свой 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
2012/5/18 Andrey Tataranovich : > Выкинь ты свой 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
18:35 Fri 18 May, Gary Trotcko wrote: > 2012/5/18 Andrey Melnikoff : > > Gary Trotcko 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
2012/5/18 Andrey Melnikoff : > Gary Trotcko wrote: >> Сглазил... Сегодня после 3-х дней исправной работы система намертво >> зависла. Причина возможно постом выше. > Так выкинь ты это трикомовское поделье. Купи в ближайшей лавке кривалетк за > $3 и всё. Не могу. Мы не ищем лёгких путей. Если секс, то исключитеьно в гамаке, надев гидрокостюм, ласты и акваланг :-) С наступающим всех летом! P.S. Если буду уверен что виновата именно карточка 3Com, а не WiFi TP-Link, то я её выкину без сожаления, тем более что лишняя карта и так уже есть. -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
Gary Trotcko 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
Сглазил... Сегодня после 3-х дней исправной работы система намертво зависла. Причина возможно постом выше. -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
Похоже что всё начинается с этого: $ 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] [] ? warn_slowpath_common+0x68/0x79 May 17 18:29:43 debian kernel: [ 455.008461] [] ? dev_watchdog+0xb1/0x104 May 17 18:29:43 debian kernel: [ 455.008476] [] ? warn_slowpath_fmt+0x29/0x2d May 17 18:29:43 debian kernel: [ 455.008491] [] ? dev_watchdog+0xb1/0x104 May 17 18:29:43 debian kernel: [ 455.008534] [] ? local_bh_enable+0x2/0x2 May 17 18:29:43 debian kernel: [ 455.008559] [] ? run_timer_softirq+0x150/0x1f3 May 17 18:29:43 debian kernel: [ 455.008575] [] ? netif_tx_unlock+0x3a/0x3a May 17 18:29:43 debian kernel: [ 455.008591] [] ? local_bh_enable+0x2/0x2 May 17 18:29:43 debian kernel: [ 455.008606] [] ? __do_softirq+0x94/0x12f May 17 18:29:43 debian kernel: [ 455.008621] [] ? local_bh_enable+0x2/0x2 May 17 18:29:43 debian kernel: [ 455.008631] [] ? irq_exit+0x32/0x80 May 17 18:29:43 debian kernel: [ 455.008677] [] ? do_IRQ+0x65/0x76 May 17 18:29:43 debian kernel: [ 455.008701] [] ? common_interrupt+0x30/0x38 May 17 18:29:43 debian kernel: [ 455.008734] [] ? ps2_handle_ack+0x4d/0xb5 May 17 18:29:43 debian kernel: [ 455.008753] [] ? native_safe_halt+0x2/0x3 May 17 18:29:43 debian kernel: [ 455.008779] [] ? default_idle+0x52/0x87 May 17 18:29:43 debian kernel: [ 455.008794] [] ? cpu_idle+0x95/0xaf May 17 18:29:43 debian kernel: [ 455.008812] [] ? 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
Похоже действительно застарелый баг http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556433 -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
Ну в принципе можно резюмировать - 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
2012/5/14 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 -- окончание процесса умирания > по таймауту. Тогда никакие "злоумышленники" не при чём, конечно. :) Приблизительно такую причину я и предполагал (эмпирически :)), Вот решил поиграться с опциями pptp - обратил внимание что выключена буферизация опцией --nobuffer. Запустил без неё - рабтает уже больше 4-х часов. Ждём-с... -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
2012/5/14 Andrey Melnikoff : > Gary Trotcko wrote: >> Мммм Но почему при _выключенном_hostapd_ сессия на рвётся? Начать > ifconfig и arp -an в момент разрыва покажи. Пока работает... >> разбираться с провайдером можно было бы, но дело в том что он, мягко >> говоря, не приветствует подобные вещи (роутеры и пр.), у них политика >> такая - 1 канал на 1 хост. Хочешь больше, подключай ещё 1 кабель. > Голосовать деньгами надо от таких провайдеров. Ибо его не должно волновать, > сколько электрочайников с прочими книгочиталками сидят за твоим роутером. Надо, но бежать некуда. Город небольшой, а провайдер, по сути локальный монополист. -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
Извиняюсь, за ненарочно отправленные письма не в рассылку.
Re: debian + hostapd + pptp = pptp random disconnect
Gary Trotcko 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
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
Мммм Но почему при _выключенном_hostapd_ сессия на рвётся? Начать разбираться с провайдером можно было бы, но дело в том что он, мягко говоря, не приветствует подобные вещи (роутеры и пр.), у них политика такая - 1 канал на 1 хост. Хочешь больше, подключай ещё 1 кабель. -- Best Regards, Gary Trotcko
Re: debian + hostapd + pptp = pptp random disconnect
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],
Re: debian + hostapd + pptp = pptp random disconnect
Хм, собственно вот, но... (( 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 13775
Re: debian + hostapd + pptp = pptp random disconnect
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
debian + hostapd + pptp = pptp random disconnect
Приветствую всех читающих. Дебютирую с этим тредом в данной рассылке )) Преамбула. -- Есть роутер, сделанный из старого "тазика". На нём 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 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 старт автоматически при загрузке
Eugene Berdnikov 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 старт автоматически при загрузке
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 старт автоматически при загрузке
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 старт автоматически при загрузке
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 * 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 старт автоматически при загрузке
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 старт автоматически при загрузке
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] - дефектный ro und robin в DNS
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
Re: [pptp] - дефектный round robin в DNS
Здравствуйте! Можно попробовать настроить два PPTP-соединения по одному на каждый адрес.
Re: [pptp] - дефектный round ro bin в DNS
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
[pptp] - дефектный round robin в DNS
Есть 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: /etc/network/interfaces и pptp. Что не так?
Олег Анисимов 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. Что не так?
В Чтв, 04/12/2008 в 17:13 +0300, Олег Анисимов пишет: > Peter Teslenko пишет: > > Покотиленко Костик wrote: > > > >> Если маршрут не подымается, значит в нём что-то не так, попробуй "2>&1 > >>>> /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: Если маршрут не подымается, значит в нём что-то не так, попробуй "2>&1 /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 в 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. Что не так?
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 в 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. Что не так?
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]
Re: /etc/network/interfaces и pptp. Что не так?
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. Что не так?
В Срд, 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. Что не так?
Peter Teslenko -> debian-russian@lists.debian.org @ Wed, 03 Dec 2008 17:49:15 +0300: >> Если маршрут не подымается, значит в нём что-то не так, попробуй "2>&1 >>>> /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: Jabber: [EMAIL PROTECTED] Мне еще спать под рутом (С)энта -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/network/interfaces и pptp. Что не так?
Покотиленко Костик wrote: Если маршрут не подымается, значит в нём что-то не так, попробуй "2>&1 /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. Что не так?
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. Что не так?
В сообщении от 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. Что не так?
В Срд, 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. Что не так?
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. Что не так?
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. Что не так?
В Вто, 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 > > но почему-то и там роут не понимается. > Что я делаю не так? Если маршрут не подымается, значит в нём что-то не так, попробуй "2>&1 >> /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]
/etc/network/interfaces и pptp. Что не т ак?
Приветствую. Прописал в /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
В Чтв, 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
В сообщении от середа, 12-бер-2008 Покотиленко Костик написал(a): > С pptp я не работал, может кто другой подскажет логику работы. Ну, pptp тут запускается из pppd. > Но на мой > взгляд для начала тебе надо разобраться почему при опускании интерфейса > не выходит pppd. Ты не понял. Я не опускаю интерфейс. Связь пропадает, pppd перезапускает pptp, но сам pppd не завершается, и не должен. Но через некторое время (дней, недель), ifupdown начинает думать, что интерфейс опущен. Надо будет следующий раз проверить /etc/network/run/ifstate. Он же вроде оттуда читает поднят интерфейс или нет. хм. может есть какой-то монитор за содержимым файла, чтобы в лог скидывал дату модификации? -- JID: alexey#boyko,km,ua
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: mtu 1500 qdisc pfifo_fast > qlen 32 > # ifdown ppp0 > # ip link |grep ppp0 > # ifup ppp0 > # ip link |grep ppp0 > 2215: ppp0: 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]
Re: pptp client restart
Я как-то видел, что 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-бер-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: mtu 1500 qdisc pfifo_fast qlen 32 # ifdown ppp0 # ip link |grep ppp0 # ifup ppp0 # ip link |grep ppp0 2215: ppp0: 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
В Срд, 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: 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
В сообщении от вівторок, 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: mtu 1500 qdisc pfifo_fast qlen 3 link/ppp Я то знаю, как сделать kill 2616, но неприятно. А если у меня много ppp интерфейсов? конкретно на этой машине настроен ещё pptpd, просто сейчас никто не подсоединён, который pppd килять? Это ещё дольше искать по логам. То есть всё в принципе решаемо, но проблемы есть. -- JID: alexey#boyko,km,ua
Re: pptp client restart
В Вто, 11/03/2008 в 19:15 +0300, 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 думает, что он всё ещё порднят --- это > нормально, да? Архитектура решения такова, что это абсолютно нормально. У Вас с этим проблемы? -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pptp client restart
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]
Re: pptp client restart
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
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
В сообщении от вівторок, 11-бер-2008 sergio написал(a): > Есть машинка под дебианом. В данный момент pptp работает через > pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво. > > Очень хочется, что бы при падении туннель поднимался заново.. Мне тоже кажется что pppd из ifupdown запускается несколько криво, но вот автопередозвон таки работает, хоть и не средствами ifupdown, а средствами pppd. Опции persist, maxfail и holdoff -- JID: alexey#boyko,km,ua
pptp client restart
Всем привет. Собсна вот сабж. Есть машинка под дебианом. В данный момент pptp работает через pptp-linux и pppd. pppd запускается из ifupdown что, имхо, криво. Очень хочется, что бы при падении туннель поднимался заново.. -- sergio. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: падает инет при подключении pptp
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: падает инет при подкл ючении pptp
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
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
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.
падает инет при подключении pptp
Добрый день. Столкнулся с проблемой: настроил у себе сервер pptp. Когда пользователь конектица к моему серверу ровно через 30 секунд пинги перестают ходит с компа пользователя и на сервере тоже пропадает пинг в инет. Соединение с инетом происходит через соседнюю машину на которой настроен MASQUERADE. В чем может быть проблема? -- --- Best Regards Kharlamov Sergey
Re: troubles with mppe & radius plugin in pptp vpn
Добрый день, обнаружил странный глюк: при подключении по 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 ] 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 ] 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 ] Jun 1 09:38:25 gate pppd[6785]: rcvd [LCP ConfReq id=0x0 ] Jun 1 09:38:25 gate pppd[6785]: sent [LCP ConfRej id=0x0 ] Jun 1 09:38:25 gate pppd[6785]: rcvd [LCP ConfReq id=0x1] Jun 1 09:38:25 gate pppd[6785]: sent [LCP ConfAck id=0x1] Jun 1 09:38:28 gate pppd[6785]: sent [LCP ConfReq id=0x1 ] Jun 1 09:38:28 gate pppd[6785]: rcvd [LCP ConfAck id=0x1 ] 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 , 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 ] Jun 1 09:38:28 gate pppd[6785]: sent [IPCP ConfReq id=0x1 ] Jun 1 09:38:28 gate pppd[6785]: rcvd [CCP ConfReq id=0x4 ] Jun 1 09:38:28 gate pppd[6785]: sent [CCP ConfRej id=0x4 ] Jun 1 09:38:28 gate pppd[6785]: rcvd [IPCP ConfReq id=0x5 ] Jun 1 09:38:28 gate pppd[6785]: sent [IPCP ConfNak id=0x5 ] Jun 1 09:38:28 gate pppd[6785]: rcvd [CCP ConfRej id=0x1 ] 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 ] Jun 1 09:38:28 gate pppd[6785]: sent [IPCP ConfReq id=0x2 ] 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
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]
Re: pptp-linux & mpd
В сообщении от 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
провайдер тут потихоньку переводит сетку с какого-то vpn-сервера на mpd. ну и сделали они mpd-сервер в локалке к которому можно коннектиться. старый тоже работает. новый сервак только IP-шником отличается, а коннект на них оба одинаковый: конфиги/роутинги/удаленные IP-шники итп. так вот, когда коннектимся к mpd-серверу сеть работает: только пинги ходят, остальные протоколы по таймаутам выпадают, а к старому vpn - сеть нормально работает. я полазил по инету с такой проблемой vs mpd куча народу сталкивалась, но решения не нашел, только вопросы в инете и есть. никто не сталкивался? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
iptraf и pptp
Хост ходит в инет через ppp0 (VPN), LAN висит на eth0. Пакеты до VPN access server-a идут через некий гейт, доступный с eth0. Это правильно, что в iptraf в выводе "LAN station monitor" отображается _два_ разных HW address: один - MAC гейта, и другой, похожий на местный MAC хоста, но не он. Это из-за туннеля так? По статистике видно, что все пакеты туда и обратно идут как-бы через этот левый MAC. Что вводит меня в некий предпаранойдальный ступор. -- Станислав
pptp соединение рвётся пр и запуске p2p приложений
Здраствуйте. Есть такая проблема: соединение с провайдером идёт через 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] rcvd [LCP ConfReq id=0x1 ] sent [LCP ConfAck id=0x1 ] rcvd [LCP ConfAck id=0x1] sent [LCP EchoReq id=0x0 magic=0xb3517224] rcvd [CHAP Challenge id=0x1 , 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 ] rcvd [IPCP ConfReq id=0x1 ] sent [IPCP ConfAck id=0x1 ] rcvd [IPCP ConfNak id=0x1 ] sent [IPCP ConfReq id=0x2 ] rcvd [IPCP ConfAck id=0x2 ] 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
Добрый день. 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
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]
Re: pptp over ppp
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 over ppp
On Sat, 14 Oct 2006, Nicholas wrote: N> Столкнулся с проблемой - не подмимается openvpn киент при диалапном доступе в N> сеть. Есть мнение что "pptp over ppp" просто делать нельзя. N> Вопрос: можно ли теоретически поднять openvpn туннель при диалапном N> соединении? Так все-таки openvpn или pptp нужно поднять? И в чем проблема?
pptp over ppp
Столкнулся с проблемой - не подмимается 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 и хренов пров
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 <[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]
Re: pptp и хренов пров
On Sun, Jun 04, 2006 at 09:11:17PM +0400, Stanislav Maslovski wrote: > gateway в дауне, не пингуется, "no route to host". ^^ Тут очепятка. Следует читать "Destination Host Unreachable". -- Cтанислав
pptp и хренов пров
Доброго времени суток, Имеем: самосборное ядро 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танислав
Re: Продолжение pptp
Sergievskaya Irina пишет: Hello Hodot, Friday, May 5, 2006, 8:45:06 PM, you wrote: Нечаянно вышло... сорь :) Дублирую. Это после команды pon ? в таком случае видно что ppp0 не поднялся Честно говоря, я обладаю самым минимумом знаний, посему не поняла, что именно не поднялось и соответственно,как это лечить. вот это и смущает, что за авторизация на серваке? случайно не mppe? в винде прописывается только протокол CHAP что -то вроде строки должно появиться: 10.1.7.1192.168.0.245 255.255.255.255 UG0 0 0 eth0 после перезагрузки совсем весело стало с роутингом. на команду route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse просто пустая таблица, хотя еще ничего не добавляла и не убивала.. iriks:/home/iriks# ifconfig ---тоже пусто... /etc/network/interfaces - нужно вернуть назад настройки и вдруг здесь что понятно будет. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]