Отправляет email-рассылки с помощью сервиса Sendsay

KirovLUG: пользователи Linux в Вятке

PPP

Добрый вечер.

Опять я со своей проблемой с PPP-соединением (или уже и не знаю с чем
:) Еще раз спасибо за советы всем ответившим. Некоторое время некогда
было заниматься этой проблемой, но на выходных попробовал еще раз.

Результат неутешительный:
- настройки, сгенерированные pppconfig, работают точно так же, как и
мои (т.е. соединение, вроде бы, устанавливается нормально, но не
пингуются ни remote IP, ни nameserver'ы, ни любые другие известные IP)
- настройки, которые в этот список кидал А. Колотов, начинают работать
только после добавления в /etc/ppp/options опции noauth, после чего
результат аналогичен вышеописанному
- для 100% очистки совести в отношении правильности настройки ppp,
установил KDE, запустил KPPP (который, вроде, должен предусматривать
максимальную защиту от дурака) - результат тот же.

Дело, вероятно, не в настройках ppp или скриптах. Стал разбираться в
софте. Неполный перечень мер, оказавшихся также безрезультатными:
- вернул pppd из дистрибутива вместо более поздней версии, которую
ставил из contribs
- пересобрал ядро (на всякий случай :)
- вернул дистрибутивное ядро 2.4.20-9asp вместо самостоятельно
собранного 2.4.22 (с ним-то точно работало)
- снес Win4Lin (я подумал, может это он со своими попытками
организовать виртуальную сеть вызывает глюки)
- попробовал не просто делать setuid pppd, но логиниться рутом

В общем, результат одинаков. Из-под винды на этой же машине при
соединении с тем же ВТ и с тем же логином все работает.

Я в растерянности... Не переставлять же Linux с нуля из-за этого. В
какую сторону хотя бы копать?

Ответить   Alexander Sat, 8 Nov 2003 18:47:41 +0300 (#18122)

 

Ответы:

Hello Alexander,

Ваши притензи необходимо предьявить к Вашему провайдеру, т.е.
ВолгаТелеком. Т.к. изначально работающие настройки не могут просто так
перестать работать.
Данная проблема была пол года назад (с несто во не сего перестал linux
в инет ходить, при этом винда спокойна работала с инетом), Киров Электросвязь
признало что
это была их ошибка.

Ответить   Jobcenter Sat, 8 Nov 2003 20:43:03 +0300 (#18179)

 

On Sat, Nov 08, 2003 at 08:43:03PM +0300, Jobcenter wrote:

вариант конечно, но у меня то работает... и как раз в
ВолгаТелекомом.

Ответить   Sat, 8 Nov 2003 22:03:04 +0300 (#18185)

 

i686-pc-linux-gnu)

On Sat, 8 Nov 2003 20:43:03 +0300
Jobcenter <iv***@j*****.ru> wrote:

Имхо неча на провайдера пенять, коли руки кривы.У меня и сотоварищей
ведь все работает? Или ВТ специально для Александра строит "злые козни"?
Ну бред ведь, согласитесь...

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

;) интересно, в лице кого "признало"? И насколько официально.

(Словосочетание интересное: ""Электросвязь" признало". Возьму
пожалуй на заметку);))

P.S. Быть может и не вполне корректное замечаение, однако, грамотность у
Вас что-то хромает. Троечку в школе по русскому имели?

Ответить   "Konstantin A. Shchekotoff" Sat, 8 Nov 2003 22:27:34 +0300 (#18193)

 

Hello Jobcenter,

Saturday, November 8, 2003, 8:43:03 PM, you wrote:

ВолгаТелекому, конечно, есть за что предъявить претензии, но т.к.
проблема возникла не у всех кировских пользователей Линукса
одновременно, а только у меня, боюсь, что они тут как раз не при чем.

Ответить   Alexander Sun, 9 Nov 2003 12:34:35 +0300 (#18303)

 

On Sat, Nov 08, 2003 at 06:47:41PM +0300, Alexander wrote:

а что говорит iptables -L
и ifconfig после соединения?

Ответить   Sat, 8 Nov 2003 22:05:34 +0300 (#18186)

 

Hello Alexander,

Saturday, November 8, 2003, 10:05:34 PM, you wrote:

Заранее извиняюсь за длинное и неудобочитаемое письмо, но попробую
дать исчерпывающие сведения. Итак, с самого начала:

[alb ~]$ /etc/ppp/ppp-on
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/modem
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x1df83637> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 < 00 04 00 00> <mru 1524> <asyncmap 0x0> <auth pap>
<pcomp> <accomp> <mrru 1524> <endpoint [MAC:00:c0:7b:aa:a2:a8]>]
sent [LCP ConfRej id=0x1 < 00 04 00 00> <mrru 1524>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x1df83637> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0x0> <auth pap> <pcomp> <accomp>
<endpoint [MAC:00:c0:7b:aa:a2:a8]>]
sent [LCP ConfAck id=0x2 <mru 1524> <asyncmap 0x0> <auth pap> <pcomp> <accomp>
<endpoint [MAC:00:c0:7b:aa:a2:a8]>]
sent [PAP AuthReq id=0x1 user="<name>" password="<password>"]
rcvd [PAP AuthAck id=0x1 ""]
PAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0>
<ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 217.9.147.47>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 217.9.147.47>]
rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
rcvd [IPCP ConfNak id=0x1 <addr 217.9.144.235> <ms-dns1 217.9.147.42> <ms-dns3
217.9.148.4>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 217.9.144.235> <ms-dns1 217.9.147.42>
<ms-dns3 217.9.148.4>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 217.9.144.235> <ms-dns1 217.9.147.42>
<ms-dns3 217.9.148.4>]
local IP address 217.9.144.235
remote IP address 217.9.147.47
primary DNS address 217.9.147.42
secondary DNS address 217.9.148.4
Script /etc/ppp/ip-up started (pid 1430)
Script /etc/ppp/ip-up finished (pid 1430), status = 0x0
После того, как соединение установилось:

[alb ~]$ /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:217.9.144.235 P-t-P:217.9.147.47 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:66 (66.0 b) TX bytes:255 (255.0 b)
[alb ~]$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.9.147.47 * 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 * 255.255.0.0 U 0 0 0 lo
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 217.9.147.47 0.0.0.0 UG 0 0 0 ppp0
[alb ~]$ sudo /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
В другом ядре поддержка iptables вообще не была включена и,
соответственно, iptables -L ругалось на невозможность загрузить
соответствующий модуль. Результат тот же.

Теперь про проблемы. Пытаемся сделать пинг remote IP и IP primary
nameserver'а:

[alb ~]$ ping 217.9.147.47
PING 217.9.147.47 (217.9.147.47) 56(84) bytes of data.
217.9.147.47 ping statistics 3 packets transmitted, 0 received, 100% packet loss, time 2025ms

[alb ~]$ ping 217.9.147.42
PING 217.9.147.42 (217.9.147.42) 56(84) bytes of data.
217.9.147.42 ping statistics 3 packets transmitted, 0 received, 100% packet loss, time 2023ms
При этом /usr/sbin/tcpdump -i ppp0 показывает следующую картину:

12:03:42.207797 217.9.144.235 > 217.9.147.47: icmp: echo request (DF)
12:03:43.222730 217.9.144.235 > 217.9.147.47: icmp: echo request (DF)
12:03:44.232843 217.9.144.235 > 217.9.147.47: icmp: echo request (DF)
12:03:46.229634 217.9.144.235 > 217.9.147.42: icmp: echo request (DF)
12:03:47.242709 217.9.144.235 > 217.9.147.42: icmp: echo request (DF)
12:03:48.252792 217.9.144.235 > 217.9.147.42: icmp: echo request (DF)
При попытке lynx'ом зайти на www.kirov.ru по IP (217.9.147.42):

12:04:04.915047 217.9.144.235.1025 > 217.9.147.42.http: S 31603236:31603236(0)
win 5840 <mss 1460,sackOK,timestamp 24789 0,nop,wscale 0> (DF)
12:04:07.912666 217.9.144.235.1025 > 217.9.147.42.http: S 31603236:31603236(0)
win 5840 <mss 1460,sackOK,timestamp 25089 0,nop,wscale 0> (DF)
12:04:13.912692 217.9.144.235.1025 > 217.9.147.42.http: S 31603236:31603236(0)
win 5840 <mss 1460,sackOK,timestamp 25689 0,nop,wscale 0> (DF)
При попытке обратиться по доменному имени (lynx http://www.kirov.ru):

12:04:22.571495 217.9.144.235.1025 > 217.9.147.42.domain: 3386+ AAAA? www.kirov.ru.
(30) (DF)
12:04:22.572726 217.9.247.149 > 217.9.144.235: icmp: echo request
12:04:22.573238 217.9.144.235 > 217.9.247.149: icmp: echo reply
12:04:22.582650 217.9.147.42.http > 217.9.144.235.1025: S 111279780:111279780(0)
ack 31603237 win 57344 <mss 1460> (DF)
12:04:22.582788 217.9.144.235.1025 > 217.9.147.42.http: R 31603237:31603237(0)
win 0 (DF)
12:04:22.592647 217.9.147.42.http > 217.9.144.235.1025: S 111279780:111279780(0)
ack 31603237 win 57344 <mss 1460> (DF)
12:04:22.592746 217.9.144.235.1025 > 217.9.147.42.http: R 31603237:31603237(0)
win 0 (DF)
12:04:22.602647 217.9.147.42.http > 217.9.144.235.1025: S 111279780:111279780(0)
ack 31603237 win 57344 <mss 1460> (DF)
12:04:22.602742 217.9.144.235.1025 > 217.9.147.42.http: R 31603237:31603237(0)
win 0 (DF)
12:04:22.662659 61.232.83.31.1075 > 217.9.144.235.ms-sql-m: udp 376
12:04:22.662836 217.9.144.235 > 61.232.83.31: icmp: 217.9.144.235 udp port ms-sql-m
unreachable [tos 0xc0]
12:04:22.672651 217.9.147.42.http > 217.9.144.235.1025: S 111279780:111279780(0)
ack 31603237 win 57344 <mss 1460> (DF)
12:04:22.672743 217.9.144.235.1025 > 217.9.147.42.http: R 31603237:31603237(0)
win 0 (DF)
12:04:22.682654 217.9.147.42.http > 217.9.144.235.1025: S 111279780:111279780(0)
ack 31603237 win 57344 <mss 1460> (DF)
12:04:22.682749 217.9.144.235.1025 > 217.9.147.42.http: R 31603237:31603237(0)
win 0 (DF)
12:04:22.922636 217.9.147.47 > 217.9.144.235: icmp: parameter problem - octet
0
И, наконец, завершение соединения:

Terminating on signal 2.
Script /etc/ppp/ip-down started (pid 1440)
sent [LCP TermReq id=0x2 "User request"]
rcvd [LCP TermAck id=0x2]
Connection terminated.
Connect time 1.9 minutes.
Sent 2651 bytes, received 838 bytes.
Waiting for 1 child processes...
script /etc/ppp/ip-down, pid 1440
Script /etc/ppp/ip-down finished (pid 1440), status = 0x0
Connect time 1.9 minutes.
Sent 2651 bytes, received 838 bytes.
P.S. На Google Groups нашел в архивах самых различных usenet
конференций описания подобной проблемы, как с линуксом, так и с бсд. В
одном случае действительно был виноват firewall, в другом
спрашивавшему помогло изменение скорости порта с командной строке pppd
(танцы с бубном какие-то; однако, я попробовал и так - не помогает).
Во всех остальных случаях вопрос так и остался без ответа :(

Ответить   Alexander Sun, 9 Nov 2003 12:40:17 +0300 (#18304)

 

Hello.

Все, отбой :)
Извиняюсь перед всеми, кто пытался мне помочь, за отнятое время.

Проблема локализована и устранена. Правда, убей Бог, не понимаю, как
такое могло быть. Все дело было в строке инициализации модема,
прописанной в /etc/ppp/ppp-on-dialer. После добавления в ее начало
"&F" все заработало. Я не знаю, что конкретно в настройках модема
нужно было для успешной работы соединения, но факт, что дело было в
этом. Соответственно, причиной, по которой все перестало работать,
видимо, и стала замена модема.

Остается вопрос: какая разница модему, какие данные передавать? Ведь
PPP-соединение установилось нормально, LCP и IPCP пакеты проходили без
проблем...

Ответить   Alexander Sun, 9 Nov 2003 23:12:41 +0300 (#18492)

 

On Sun, Nov 09, 2003 at 11:12:41PM +0300, Alexander wrote:

поздравляю с успешным решением проблеммы

Ответить   Mon, 10 Nov 2003 15:51:24 +0300 (#18764)