anonymous
написал 11 августа 2004 года в 21:36 (647 просмотров)
Ведет себя
неопределенно; открыл 1814 темы в форуме, оставил 5575 комментариев на сайте.
в Fedora Core 2 почему то при соединении с помощью kppp соединение устанавливается но данные не передаются. с system-config-network все работает но он очень неудобный. Собственно как сделать чтобы из kppp соединялось нормально
Последние комментарии
- OlegL, 17 декабря в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Посмотри может дело в firewall’e?
это было первое что я подумал но фаерволл я настраивал и там всё в порядке.
$ netstat -nr
после установления соединения
ну и
$ ifconfig -a
не помешает
через system-config-network
Destination Gateway Genmask Flags MSS Window irtt Iface
62.33.112.122 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 62.33.112.122 0.0.0.0 UG 0 0 0 ppp0
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1194 errors:0 dropped:0 overruns:0 frame:0
TX packets:1194 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:866900 (846.5 Kb) TX bytes:866900 (846.5 Kb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.5.3 P-t-P:62.33.112.122 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:1 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:66 (66.0 b) TX bytes:1935 (1.8 Kb)
tunl0 Link encap:IPIP Tunnel HWaddr
NOARP MTU:1480 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:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
через kppp
Destination Gateway Genmask Flags MSS Window irtt Iface
62.33.112.122 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 62.33.112.122 0.0.0.0 UG 0 0 0 ppp0
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1196 errors:0 dropped:0 overruns:0 frame:0
TX packets:1196 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:867000 (846.6 Kb) TX bytes:867000 (846.6 Kb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.5.7 P-t-P:62.33.112.122 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:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:66 (66.0 b) TX bytes:1515 (1.4 Kb)
tunl0 Link encap:IPIP Tunnel HWaddr
NOARP MTU:1480 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:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
помогите.. кто знает как заставить работать через kppp ???
Вообще-то странно вот что:
т.е. адрес как-то странно выдаётся…
проверить, работает ли
$ ping 62.33.112.122
и что показывает
$ mtr www.ru
(к примеру www.ru, можно что-нить другое, общеизвстное)
((ну, или не mtr, а traceroute))
ну странность может быть потому что там доступ ограничен только одним ресурсом..
а пинговать пробовал результат писать небуду скажу лишь что через system-config-network все нормально пингуется
а через kppp ответ один unknown host
я так чую у меня система вообще не чует подключения через kppp а чем такое вызвано я уже фаерволл отключил все и все равно не помогает.
Как это у меня… Настройка моего соединения — тут. Не через kppp, но всё же — мне для него ставить весь kde как-то лениво малость ;)
Вот что и как у меня, опять же:
И mtr не показал ни одной ошибки.
В общем — смотрить тогда настройки kppp. Либо — полльзоваться pppd ;)
Что тебе странного в этом почудилось?
Люди подскажите еще то что можно сделать ??? а то я уже все переискал и перерыл. Фаерволл настроен правильно. Подскажите что еще попробовать и где порыться
Что ещё попробовать?
Установить уровень отладик ошибок в настройках kppp чтобы pppd выводил диагностику в лог. Смотреть, как именно усьановилось соединение. И думать, что же там могло быть не так.
А гадать никому на кофейной гуще резону нет. Дело это неблагодарное.
Ни дистрибутив, ни его версия, ни версия ядра, ни версия pppd, ни настройки kppp, ни… Вот и именно, что ничего этого не описано. И даже на вопрос, что выдаёт пинг отвечено:
Получается, что тут — лига телепатов, и этого ответа достаточно, чтобы понять эту проблему по не предоставленным данным дать точный ответ, что не так с настройками.
В общем, будем дальше умалчивать?
Лично у меня как-то уже и желания не наблюдается думать что и как (в свете вышеописанного).
Дистр. Fedora Core 2. Ядро 2.6.7. pppd 2.4.2 настройки kppp стандартные.
подключаюсь через kppp
ping -c 10 212.94.102.77
PING 212.94.102.77 (212.94.102.77) 56(84) bytes of data.
64 bytes from 212.94.102.77: icmp_seq=0 ttl=255 time=181 ms
64 bytes from 212.94.102.77: icmp_seq=1 ttl=255 time=172 ms
64 bytes from 212.94.102.77: icmp_seq=2 ttl=255 time=194 ms
64 bytes from 212.94.102.77: icmp_seq=3 ttl=255 time=215 ms
64 bytes from 212.94.102.77: icmp_seq=4 ttl=255 time=273 ms
64 bytes from 212.94.102.77: icmp_seq=5 ttl=255 time=198 ms
64 bytes from 212.94.102.77: icmp_seq=6 ttl=255 time=222 ms
64 bytes from 212.94.102.77: icmp_seq=7 ttl=255 time=271 ms
64 bytes from 212.94.102.77: icmp_seq=8 ttl=255 time=211 ms
64 bytes from 212.94.102.77: icmp_seq=9 ttl=255 time=271 ms
— 212.94.102.77 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9002ms
rtt min/avg/max/mdev = 172.009/221.378/273.934/36.147 ms, pipe 2
mtr и traceroute
lookup failure
через system-config-network
ping -c 10 212.94.102.77
PING 212.94.102.77 (212.94.102.77) 56(84) bytes of data.
64 bytes from 212.94.102.77: icmp_seq=0 ttl=255 time=320 ms
64 bytes from 212.94.102.77: icmp_seq=1 ttl=255 time=180 ms
64 bytes from 212.94.102.77: icmp_seq=2 ttl=255 time=167 ms
64 bytes from 212.94.102.77: icmp_seq=3 ttl=255 time=283 ms
64 bytes from 212.94.102.77: icmp_seq=4 ttl=255 time=266 ms
64 bytes from 212.94.102.77: icmp_seq=5 ttl=255 time=252 ms
64 bytes from 212.94.102.77: icmp_seq=6 ttl=255 time=261 ms
64 bytes from 212.94.102.77: icmp_seq=7 ttl=255 time=251 ms
64 bytes from 212.94.102.77: icmp_seq=8 ttl=255 time=368 ms
64 bytes from 212.94.102.77: icmp_seq=9 ttl=255 time=203 ms
— 212.94.102.77 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 167.968/255.819/368.998/58.287 ms, pipe 2
traceroute www.ru
traceroute www.ru
traceroute to www.ru (194.87.0.50), 30 hops max, 38 byte packets
1 access1.biysk.ru (212.94.102.77) 173.811 ms 172.853 ms 152.968 ms
2 cisco-gw.biysk.ru (212.94.102.65) 186.046 ms 168.879 ms 159.924 ms
3 212.94.98.41 (212.94.98.41) 179.912 ms 119.888 ms 160.928 ms
4 barnaul-car0-fa0-1.rt-comm.ru (217.106.28.193) 177.921 ms 171.886 ms 169.920 ms
5 217.106.21.201 (217.106.21.201) 246.899 ms 217.106.21.213 (217.106.21.213) 306.657 ms 217.106.21.209 (217.106.21.209) 243.868 ms
MPLS Label=76 CoS=3 TTL=1 S=0
6 kochenevo-bbn0-po3-2.rt-comm.ru (217.106.6.133) 412.805 ms 454.946 ms 455.710 ms
MPLS Label=12423 CoS=3 TTL=1 S=0
7 tschelkun-bbn0-po1-1.rt-comm.ru (217.106.6.129) 245.889 ms 289.850 ms 458.868 ms
MPLS Label=12358 CoS=3 TTL=1 S=0
8 shigony-bbn0-po2-2.rt-comm.ru (217.106.6.121) 292.883 ms 229.971 ms 315.779 ms
MPLS Label=12425 CoS=3 TTL=1 S=0
9 msk-bbn0-po1-6.rt-comm.ru (217.106.6.65) 289.886 ms 289.879 ms 298.821 ms MPLS Label=12356 CoS=3 TTL=1 S=0
10 lnd-bgw0-po1-0-0-0.rt-comm.ru (217.106.6.166) 289.886 ms 275.900 ms 268.862 ms
11 POS2-0.GW1.LND9.ALTER.NET (146.188.66.49) 291.886 ms 230.861 ms 228.909 ms
12 ge5-0.cr2.lnd8.gbb.uk.uu.net (158.43.188.193) 281.905 ms 235.858 ms 299.031 ms
13 pos4-0.cr2.lnd5.gbb.uk.uu.net (158.43.253.133) 276.761 ms 277.894 ms 288.858 ms
14 so-7-0-0.XR2.lnd2.alter.net (158.43.233.246) 262.898 ms 275.861 ms 289.897 ms
15 so-1-1-0.TR2.LND2.ALTER.NET (146.188.7.234) 278.893 ms 223.869 ms 286.916 ms
16 so-6-0-0.TR1.STK2.ALTER.NET (146.188.7.30) 305.867 ms 295.784 ms 302.872 ms
17 ge-0-3-0.XR2.STK3.ALTER.NET (146.188.11.241) 302.934 ms 288.795 ms 275.904 ms
18 POS12-0-0.GW8.STK3.ALTER.NET (146.188.2.221) 289.880 ms 289.850 ms 289.890 ms
19 Demos-gw.customer.ALTER.NET (146.188.65.230) 478.972 ms 460.855 ms 497.801 ms
20 m9-3-GE4-0-0-vl10.Demos.net (194.87.0.66) 318.885 ms 255.345 ms 255.467 ms
21 * * *
22 * * *
вот. собственно почему не пускает в инет через kppp ведь пинги то идут.
поискать в настройках kppp что-то типа «получать адреса dns-серверов»
либо ручками прописать оные в /etc/resolv.conf:
прописал ручками. После подключения начинает искать и ищет ищет… ответа никакого. :(
Попробуй прописать в resolv.conf адреса внешних DNS серверов.
Например у меня так:
nameserver 217.106.70.119
nameserver 80.82.190.78
Почитай man resolv.conf
Спасибо всем огромное. Надыбал у одного из провов ДНСки и теперь и глобал и интра работают :) Но меня все таки интересует вопрос почему этот процесс не происходит автоматически ? баг или фича ? во всех дистрах которые у меня были до этого всё было нормально. И главное что kppp не определяет а system-config-network нормально. В общем кто что думает ?
Ох.. ну, я надеюсь, не пытались прописывать именно как у меня?
просто у меня поднят локальный кеширующий как на моём компе, та и не сервере.
А дело было в том, что в kppp не указано брать настройку dns--сервера у провайдера. system-config-network эти настройки воспринимаются (путём указания peerdns опции при вызове pppd). соответственно такую же точно настройку надо искать у kppp.
не могу её точно назвать, поскольку… kde вообще не использую. соответственно и настроено всё через pppd. так оно удобнее — нажал комбинацию кнопок, `pppd call beeline` запустился, и мне большего — не нада ;)