Utel + Huawei E220 Modem

[Sergii Galashyn]

Доброго дня. Ця тема частково перегукується з цією, але там проблему досі не вирішено, тому спробую сформулювати її зі свого боку. До того ж, якщо буде знайдене рішення, то на базі цього посту можна буде створити ЯкЦе, скажімо в розділ Поради.

Отже, по порядку.

Задача: бездротовий інтернет від Utel через USB модем Huawei E220 на ноутбуці Dell Inspiron 1501 зі встановленою Kubuntu 8.04.

При підключенні модема, успішно роспізнаються наступні пристрої:

Код: [Вибрати]

trovich@neformat:~$ ls /dev/ttyUSB*
/dev/ttyUSB0  /dev/ttyUSB1
Налаштування kppp:

Рахунок Utel
Номер телефону: *99# (або *99***1#)
Автентифікація: PAP/CHAP
IP: динамічна
Шлюз: Типовий + Встановити типовий через цей шлюз (+ див. примітки нижче)
Решта за умовчанням.

Модем Huawei
Пристрій: /dev/ttyUSB0
Керування потоком: Апаратне
Закінчення рядка: CR
Швидкість: 921600
Вжити файл блокування: так
Чекати на гудок перед набором: ні
Команди модему:
Рядок ініц. 1: AT+CPIN=XXXX (XXXX - це PIN-код USIM картки)
Рядок ініц. 2: AT+CGDCONT=1,"IP","internet"
Решта за умовчанням.

При з'єднанні:

Примітка: попередньо роблю ifconfig eth1 down.

Код: [Вибрати]

trovich@neformat:~$ tail -f /var/log/messages
Aug 12 22:46:17 neformat pppd[13941]: pppd 2.4.4 started by trovich, uid 1000
Aug 12 22:46:17 neformat pppd[13941]: Using interface ppp0
Aug 12 22:46:17 neformat pppd[13941]: Connect: ppp0 <--> /dev/ttyUSB0
Aug 12 22:46:17 neformat pppd[13941]: CHAP authentication succeeded
Aug 12 22:46:17 neformat pppd[13941]: CHAP authentication succeeded
Aug 12 22:46:25 neformat pppd[13941]: [glow]Could not determine remote IP address: defaulting to 10.64.64.64[/glow]
Aug 12 22:46:25 neformat pppd[13941]: local  IP address 10.193.3.212
Aug 12 22:46:25 neformat pppd[13941]: remote IP address 10.64.64.64
Aug 12 22:46:25 neformat pppd[13941]: primary   DNS address 10.11.12.13
Aug 12 22:46:25 neformat pppd[13941]: secondary DNS address 10.11.12.14

Питання #1: чи нормальна ситуація з підсвіченим текстом?

Інтерфейс успішно піднявся і виглядає так:

Код: [Вибрати]

trovich@neformat:~$ ifconfig
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:77 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6874 (6.7 KB)  TX bytes:6874 (6.7 KB)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.192.236.240  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:262 (262.0 B)  TX bytes:193 (193.0 B)


Далі, власне, проблема: з'єднання є -- зв'язку немає.


Два варіянти підключеня дають наступну картину маршрутів.

З assign the default route to this gateway:

Код: [Вибрати]

trovich@neformat:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     *               255.255.255.255 UH    0      0        0 ppp0
default         *               0.0.0.0         U     0      0        0 ppp0
без assign the default route to this gateway

Код: [Вибрати]

trovich@neformat:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     *               255.255.255.255 UH    0      0        0 ppp0

Пробую встановити маршрут за умовчанням:

Код: [Вибрати]

trovich@neformat:~$ sudo route add default gw 10.64.64.64
trovich@neformat:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     *               255.255.255.255 UH    0      0        0 ppp0
default         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
Різниці жодної.
Окрім того, дуже довго відобрається список маршрутів. Від уведення команди до відображення списку може пройти кілька хвилин, що видається підозрілим.

Спроба переглянути трасу до 10.64.64.64 загинається на першому ж кроці.

Чи є якісь думки/поради? Яку ще інформацію надати?

Дуже вдячний за будь-які пропозиції.

[Praporshic]

Окрім того, дуже довго відобрається список маршрутів. Від уведення команди до відображення списку може пройти кілька хвилин, що видається підозрілим.

Схоже на проблеми з DNS. Який вміст /etc/resolv.conf?

[Sergii Galashyn]

Окрім того, дуже довго відобрається список маршрутів. Від уведення команди до відображення списку може пройти кілька хвилин, що видається підозрілим.

Схоже на проблеми з DNS. Який вміст /etc/resolv.conf?

Код: [Вибрати]

trovich@neformat:~$ cat /etc/resolv.conf
nameserver 10.11.12.13
nameserver 10.11.12.14
search ziost
nameserver 10.11.12.13  #kppp temp entry
nameserver 10.11.12.14  #kppp temp entry
~20 секунд для відображення route

Код: [Вибрати]

trovich@neformat:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     *               255.255.255.255 UH    0      0        0 ppp0
default         *               0.0.0.0         U     0      0        0 ppp0

Спроби достукатися до DNS:

Код: [Вибрати]

trovich@neformat:~$ ping 10.11.12.13
PING 10.11.12.13 (10.11.12.13) 56(84) bytes of data.

--- 10.11.12.13 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4010ms

Код: [Вибрати]

trovich@neformat:~$ ping 10.11.12.14
PING 10.11.12.14 (10.11.12.14) 56(84) bytes of data.

--- 10.11.12.14 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

Код: [Вибрати]

trovich@neformat:~$ traceroute 10.11.12.14
traceroute to 10.11.12.14 (10.11.12.14), 30 hops max, 40 byte packets
send: No buffer space available

[Olehkh]

перепрошую, який лінукс?

[Praporshic]

перепрошую, який лінукс?

По-перше, це не дуже й то має значення
По-друге, варто читати підписи

Взагалі виникають питання що до налаштувань iptables та взагалі мережевого стеку у системі. Хоча подібні проблеми можна отримати лише добряче покопирсавшись у налаштуваннях (я подібні налаштування якщо роблю, то лише дивлячись у довідник).

А що каже спроба пропінгувати шлюз? Може десь він не пропускає....

[Sergii Galashyn]

Взагалі виникають питання що до налаштувань iptables та взагалі мережевого стеку у системі. Хоча подібні проблеми можна отримати лише добряче покопирсавшись у налаштуваннях (я подібні налаштування якщо роблю, то лише дивлячись у довідник).

З налаштуваннями мережевого стеку все гаразд, бо WiFi працює відмінно, просто я його вимикаю коли з'єднуюсь через модем. Якщо не вимикати, то маршрути показує наступні:

Код: [Вибрати]

trovich@neformat:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     *               255.255.255.255 UH    0      0        0 ppp0
192.168.8.0     *               255.255.255.0   U     0      0        0 eth1
link-local      *               255.255.0.0     U     1000   0        0 eth1
default         192.168.8.1     0.0.0.0         UG    100    0        0 eth1

Я пробував вручну видалити default та поставити 10.64.64.64 (?). Нічого.

А що каже спроба пропінгувати шлюз? Може десь він не пропускає....

Питання в тому, який IP у шлюза?
Відомі тільки 2 DNS: 10.11.12.13 та 10.11.12.14 Вони не пінгуються.

Якщо ж це 10.64.64.64 (нагадаю, було повідомлення, що це за умовчанням адреса, виділене жовтим в першому пості), то вона теж не пінгується.

[Praporshic]

Якщо ж це 10.64.64.64 (нагадаю, було повідомлення, що це за умовчанням адреса, виділене жовтим в першому пості), то вона теж не пінгується.

Так, це шлюз і має бути. Взагалі, варто встановити закінчення рядка у CR/LF та перевірити, чи зазначено встановлювати після з'єднання ppp0 як стандартний маршрут. Більше нічого поки що в голову не лізе. Що стосується того рядка у логах - там щось цікавіше, бо pppd не може визначити з яким IP він з'єднався. Власне, через це і може бути проблема.

[Sergii Galashyn]

Якщо ж це 10.64.64.64 (нагадаю, було повідомлення, що це за умовчанням адреса, виділене жовтим в першому пості), то вона теж не пінгується.

Так, це шлюз і має бути. Взагалі, варто встановити закінчення рядка у CR/LF та перевірити, чи зазначено встановлювати після з'єднання ppp0 як стандартний маршрут.

Встановив CR/LF, різниці жодної. Стандартний маршрут зазначено.

Що стосується того рядка у логах - там щось цікавіше, бо pppd не може визначити з яким IP він з'єднався. Власне, через це і може бути проблема.

Еге ж... я так відразу й подумав. Задля того й звернувся до громади.

[Praporshic]

До речі, а не намагались зробити так, як вказано тут:
http://utel.ua/private/services.php?show=mobile_internet

[Sergii Galashyn]

До речі, а не намагались зробити так, як вказано тут:
http://utel.ua/private/services.php?show=mobile_internet

То ж для телефонів... Інфу позбирав по інтернетах.

[Praporshic]

То ж для телефонів...

Все, треба у відпустку. Однозначно.

[Olehkh]

"Рядок ініц. 1: AT+CPIN=XXXX (XXXX - це PIN-код USIM картки)
Рядок ініц. 2: AT+CGDCONT=1,"IP","internet""

запит пінкоду краще зняти
рядок шн. для Utel тоді буде AT+CGDCONT=1,"IP","3g.utel.ua"

перепрошую, який лінукс?

По-перше, це не дуже й то має значення
По-друге, варто читати підписи

Взагалі виникають питання що до налаштувань iptables та взагалі мережевого стеку у системі. Хоча подібні проблеми можна отримати лише добряче покопирсавшись у налаштуваннях (я подібні налаштування якщо роблю, то лише дивлячись у довідник).

А що каже спроба пропінгувати шлюз? Може десь він не пропускає....

в Maндріві дану проблему, після налаштування kppp, вирішив наступним чином: Центр керування - мережа та інтернет - встановити новий мережний інтерфейс - Analog telephone modem

[Sergii Galashyn]

"Рядок ініц. 1: AT+CPIN=XXXX (XXXX - це PIN-код USIM картки)
Рядок ініц. 2: AT+CGDCONT=1,"IP","internet""

запит пінкоду краще зняти
рядок шн. для Utel тоді буде AT+CGDCONT=1,"IP","3g.utel.ua"

Зняти перевірку піну поки немає можливості, бо немає телефону для того.
Така зміна рядку ін. в даному випадку не грає ролі, я думаю. Зрештою, вона нічого не змінила.

в Maндріві дану проблему, після налаштування kppp, вирішив наступним чином: Центр керування - мережа та інтернет - встановити новий мережний інтерфейс - Analog telephone modem

Немає нічого подібного у мене. ppp0 не з'являється серед інтерфейсів у графічних засобах налаштування.
Тільки ifconfig його показує.

[Olehkh]

"Рядок ініц. 1: AT+CPIN=XXXX (XXXX - це PIN-код USIM картки)
Рядок ініц. 2: AT+CGDCONT=1,"IP","internet""

запит пінкоду краще зняти
рядок шн. для Utel тоді буде AT+CGDCONT=1,"IP","3g.utel.ua"

Зняти перевірку піну поки немає можливості, бо немає телефону для того.
Така зміна рядку ін. в даному випадку не грає ролі, я думаю. Зрештою, вона нічого не змінила.

в Maндріві дану проблему, після налаштування kppp, вирішив наступним чином: Центр керування - мережа та інтернет - встановити новий мережний інтерфейс - Analog telephone modem

Немає нічого подібного у мене. ppp0 не з'являється серед інтерфейсів у графічних засобах налаштування.
Тільки ifconfig його показує.

зняти пінкод можна всунувши карточку в любий телефен, навіть без підтримки 3G. Або під віндовсом, використавши стандартне програмне забезпечення модему

[Sergii Galashyn]

Дякую за підказку щодо PIN.
Далі шаманство від УТ.
Вперше спробувавши приєднатися з опісля вимкнення перевірки PIN, побачив трохи іншу картину в лозі:

Код: [Вибрати]

trovich@neformat:~$ tail -f /var/log/messages
Aug 14 12:55:32 neformat pppd[26098]: pppd 2.4.4 started by trovich, uid 1000
Aug 14 12:55:32 neformat pppd[26098]: Using interface ppp0
Aug 14 12:55:32 neformat pppd[26098]: Connect: ppp0 <--> /dev/ttyUSB0
Aug 14 12:55:32 neformat pppd[26098]: CHAP authentication succeeded
Aug 14 12:55:32 neformat pppd[26098]: CHAP authentication succeeded
Aug 14 12:55:33 neformat pppd[26098]: Could not determine remote IP address: defaulting to 10.64.64.64
Aug 14 12:55:33 neformat pppd[26098]: local  IP address 10.192.49.136
Aug 14 12:55:33 neformat pppd[26098]: remote IP address 10.64.64.64
Aug 14 12:55:33 neformat pppd[26098]: primary   DNS address 195.5.46.12
Aug 14 12:55:33 neformat pppd[26098]: secondary DNS address 195.5.46.10

Вказало інші DNS'и!
І вони пінгувалися, на відміну від попередніх.
nslookup показав, що 195.5.46.10 це ns3.ukrtelecom.ua

Ну, думаю, добре. Поки узявся глядіти route, бо знов нічо не працювало, kppp сам від'єднавси та з'єднавси наново. І DNS'и стали знову старі! І знову настав гаплик.

Я настирно відредагував вручну /etc/resolv.conf, вписавши туди IP 195... Та встановив default route 10.64.64.64

Вуаля,



Поки спостерігається проблема на старті показу сторінки. Певне, довжеленько резолвиться адреса.
Плюс ще невідомо, як воно далі буде все, бо перспектива правити кожен раз resolv.conf не смалить. Адже на роботі WiFi з DHCP, а вдома знов 3G.

Подивимося, словом.

Всім дякую за допомогу.