Lỗi 'ip-config-không khả dụng' khi modem USB cố gắng kết nối

Tôi đã có một modem ZTE MF-193E hoạt động tốt trước đây. Khi tôi mua modem này hơn một năm trước, nó đã hoạt động dễ dàng. Bây giờ, khi Ubuntu đang phát triển trong phiên bản, mọi thứ trở nên khó khăn hơn đối với tôi.

Modem này thậm chí đã hoạt động được vài tháng trở lại với Ubuntu 15.04 (64-bit). Bây giờ, trong Ubuntu 15.10 (64-bit), nó không thể kết nối.

Tôi đã thiết lập một kết nối băng thông rộng di động . Tôi đã thử các chuỗi khác nhau cho APN, nhưng điều này không phải là một vấn đề trước đây.

(Modem hoạt động tốt trong Windows 10, do đó, đây hoàn toàn không phải là vấn đề về phần cứng. Ngoài ra, GUI của Trình quản lý Modem phát hiện độc đáo thiết bị này. SMS có thể được gửi và nhận mà không gặp sự cố nào.)

Khi tôi chèn modem, nó sẽ được phát hiện, một biểu tượng CD được hiển thị trong Unity với tên của modem. Vài giây sau, tôi nhận được một hộp tin nhắn

Mobile Broadband Network: you are registered on the home network

gần biểu tượng mạng.

Khi tôi cố gắng kết nối, biểu tượng không dây trong applet của trình quản lý mạng sẽ khởi động các chuyển động ly tâm đó, nhưng cuối cùng nó không kết nối được và một thông báo cho tôi biết rằng tôi đang ngoại tuyến.

Dòng tôi có thể cô lập /var/log/sysloglà đây,

NetworkManager[628]: <info>  (ttyUSB1): device state change: ip-config
> -> failed (reason 'ip-config-unavailable') [70 120 5]

Mặc dù vậy, tôi không chắc liệu đây có phải là cái có liên quan hay không.

Nhiều dòng từ /var/log/syslogcó thể được tìm thấy ở đây .

Cập nhật ngày 1 - 06 tháng 12 năm 2015

Như được chỉ ra bởi một thành viên loại, đã thử nf_conntrack_pptpcách tiếp cận mô-đun.

Thực hiện các lệnh sau,

$ lsmod | grep nf_conntrack_pptp | wc -l
0

$ sudo modprobe nf_conntrack_pptp
lsmod | grep nf_conntrack_pptp
nf_conntrack_pptp      20480  0
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          106496  2 nf_conntrack_proto_gre,nf_conntrack_pptp

Sau đó thử modem của tôi, cùng một thất bại. Không có thay đổi rõ rệt trong nhật ký.

Cập nhật 2 - 06/12/2015

Được thực thi như root,

systemctl restart network-manager.service

Không có đầu ra trên màn hình (thiết bị đầu cuối).

Nhật ký tương ứng từ điểm trên đến một nỗ lực kết nối bằng modem có thể được tìm thấy ở đây .

Cập nhật 3 - 06/12/2015

Cài đặt ofonovà sau đó thử lại modem.

Xin vui lòng xem nhật ký ở đây .

Cập nhật ngày 4 - 06 tháng 12 năm 2015

Một lần nữa thực thi như root,

systemctl restart network-manager.service

Nhật ký tương ứng từ điểm trên đến một nỗ lực kết nối bằng modem có thể được tìm thấy ở đây .

Cập nhật ngày 5 - 06 tháng 12 năm 2015

Đã thay đổi tất cả "từ chối" thành "cho phép" trong /etc/dbus-1/system.d/nm-dispatcher.conf.

Đã thử kết nối. Không may mắn.

Một vài mạng kết nối và ngắt kết nối với kết nối Ethernet.

Tiếp theo là sudo systemctl restart network-manager.service.

Modem cắm ra và cắm vào.

Đã thử kết nối lại. Không kết nối.

Nhật ký ở đây .

Cập nhật ngày 6 - 06 tháng 12 năm 2015

Thực thi

sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt

và

export NM_PPP_DEBUG=1
sudo NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt

Không thể chạy mm-test.pydo nhiều lỗi. Đã tìm thấy các tập tin tại vị trí được chỉ định. Nhận được điều này từ, https://github.com/openshine/ModemManager/blob/master/test/mm-test.py .

Các lệnh trên có phần khác với các lệnh trong Wiki.

Các tập tin nhật ký ở đây .

Cập nhật ngày 7 - 07 tháng 12 năm 2015

Được thực hiện lại (sau khi thay đổi được đề xuất /lib/udev/rules.d/40-usb_modeswitch.rulesvà khởi động lại)

sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee /tmp/modem.log.txt

và

sudo NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --log-level=debug --no-daemon > /tmp/nm.log.txt

Các /var/log/syslogđược bao gồm như là tốt.

Các tập tin nhật ký ở đây .

Cập nhật ngày 8 tháng 8 năm 2015

Bộ nhật ký cập nhật ở đây .

Cập nhật ngày 9 - 08 tháng 12 năm 2015

Kiểm tra 1

1. Lần này khởi động máy tính từ DVD Ubuntu 14.04 32 bit. Ngay khi máy tính khởi động, bắt đầu ghi nhật ký MM.

2. Chèn modem. lsusbcho thấy rằng nó đã được công nhận là thiết bị 19d2: 1232 cần được chuyển sang thiết bị 19d2: 2003. Do cài đặt usb-modewitch yêu cầu khởi động lại máy (và do đó mất cài đặt để chạy DVD), tôi đã chuẩn bị một tệp chuyển đổi tùy chỉnh và chuyển modem từ dòng lệnh ( sudo usb_modeswitch -I -c 19d2:2003).

3. Ngay sau khi chuyển đổi được hoàn thành, tôi được thông báo rằng tôi đã bật Mobile Broadband Networkvà một ứng dụng kết nối băng thông rộng mới trong menu quản lý mạng.

4. Tôi thiết lập kết nối trên theo cách thông thường (tên APN không phải là vấn đề) và kết nối được thiết lập tự động.

5. Tôi ngắt kết nối và đẩy modem.

6. Dừng chụp nhật ký MM.

Có thể tìm thấy nhật ký MM và nhật ký hệ thống hoàn chỉnh cho phiên bắt đầu phiên bản modem ở đây .

Kiểm tra 2

Thử nghiệm tương tự với DVD Ubuntu 14.04 64 bit.

Các bản ghi có thể được tìm thấy ở đây .

Cập nhật ngày 10 - 09 tháng 12 năm 2015

Lần này đã thử nghiệm wvdialvà thấy rằng nếu wvdialđược chạy dưới quyền root, chúng ta sẽ có được kết nối thành công .

Các wvdialconf và nhật ký, và tương ứng syslog là đây

Phỏng đoán chính: tình huống có thể có liên quan đến nhóm người dùng của người dùng tương ứng.

Nhưng như được chỉ ra ở đây ,

Với tất cả các công cụ này, để thiết lập kết nối quay số, người dùng phải là thành viên của nhóm "nhúng" và "quay số", vì vậy hãy đặt tất cả người dùng có nghĩa vụ kết nối qua quay số vào các nhóm này.

Nhưng như chúng ta có thể tìm thấy,

$ groups masroor
masroor : masroor adm dialout cdrom sudo dip plugdev lpadmin sambashare family wireshark

Vì vậy, người dùng đã là thành viên của các nhóm được chỉ định.

Bây giờ, có lẽ vấn đề sôi nổi ở một trong hai điểm này,

1. Những nhóm bổ sung nào người dùng cần phải là?
2. Làm thế nào để chúng tôi chạy quá trình thiết lập kết nối băng thông rộng di động như root? (vấn đề an ninh?)

Cập nhật 11 - 09/12/2015

wvdialhoạt động với USB3 và không hoạt động với USB1.

Vui lòng tìm syslog ở đây .

Cũng bao gồm là đầu ra của dmesg | grep tty > /tmp/dmesg.tty.txt. Nhưng xem bốn dòng gần bắt đầu của tập tin?

Cập nhật 12 - 10 tháng 12 năm 2015

1. Nhận xét dòng 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") trong /lib/udev/rules.d/77-mm-zte-port-types.rules.

2. Khởi động lại máy của tôi. Mềm ngắt kết nối cáp và cắm modem.

3. Đã thử kết nối. Không thành công.

Các tập tin syslog là ở đây .

Cập nhật ngày 13 - 10 tháng 12 năm 2015

Vì tuyệt vọng, để xem liệu một số thay đổi cục bộ có ảnh hưởng đến kết nối hay không, đã thử nghiệm máy với DVD Ubuntu 15.04 và 15.10.

1. Khởi động máy với DVD Xubfox 15.04 64 bit. Kết nối đã thành công như một lá bùa.
2. Đã khởi động máy với Ubuntu 15.10 64 bit DVD. Kết nối thất bại giống như trước đây.

Điều gì đã xảy ra giữa 15.04 và 15.10?

Rất bực bội.

Cập nhật 14 - 10 tháng 12 năm 2015

1. Tạo một tập tin mới /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulestheo hướng dẫn trong câu trả lời.

2. Khởi động lại máy của tôi (hoặc thực hiện sudo udevadm control --reload, thực sự đã thử cả hai). Chèn modem.

3. Modem đã được công nhận.

   $ lsusb
   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

4. Mềm ngắt kết nối cáp và cố gắng kết nối bằng modem. Không thành công.

5. Đã đẩy modem.

Máy bị treo một lần, đó có phải là sự kiện ngẫu nhiên không? Máy của tôi thường không treo một lần trong năm.

Tệp syslog và các tệp quy tắc được tạo ở đây .

Cập nhật 15 - 11 tháng 12 năm 2015

1. Đã thêm các dòng sau vào /lib/udev/rules.d/40-usb_modeswitch.rules.

   # ZTE MF193E
   ATTR{idVendor}=="19d2", ATTR{idProduct}=="1232", RUN+="usb_modeswitch '%b/%k'"
   

2. Giữ /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesnguyên tệp .

3. Khởi động lại máy của tôi. Chèn modem.

4. Modem đã được công nhận.

   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

5. Mềm ngắt kết nối cáp và cố gắng kết nối. Không thành công.

6. Đã đẩy modem.

7. Đã xóa /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rules.

8. Khởi động lại và thử lại toàn bộ quá trình. Không thành công nữa.

Tệp nhật ký hệ thống (hoàn tất, tôi không có nguy cơ bỏ lỡ bất kỳ phần quan trọng nào) và tệp quy tắc được đề cập (40) có ở đây .

Cập nhật 16 - 11 tháng 12 năm 2015

1. Chỉ còn lại một quy tắc 1232 /lib/udev/rules.d/40-usb_modeswitch.rules, loại bỏ quy tắc khác.

2. Thi công sudo udevadm control --reload.

3. Chèn modem.

4. Modem đã được công nhận.

   Bus 001 Device 005: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

5. Mềm ngắt kết nối cáp và cố gắng kết nối. Không thành công.

6. Đã đẩy modem.

Nhưng không phải chúng tôi đã kiểm tra hệ thống mặc định ở trên sao? Bạn có nghĩa là để lại /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesở vị trí của nó?

Tệp nhật ký hệ thống (hoàn tất, tôi không có nguy cơ bỏ lỡ bất kỳ phần quan trọng nào) và tệp quy tắc được đề cập (40) có ở đây

Cập nhật 17 - 11 tháng 12 năm 2015

1. Nhận xét quy tắc 1232 trong /lib/udev/rules.d/40-usb_modeswitch.rules, thêm một quy tắc cho năm 2003.

   # ZTE MFxxx
   # Added on December 11 2015
   ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"
   

2. Thi công sudo udevadm control --reload.

3. Chèn modem.

4. Modem được công nhận là thiết bị 1232 . Tôi không được đề nghị thử kết nối (theo như hiểu biết của tôi, nó sẽ không được đăng ký vào mạng băng thông rộng trừ khi việc chuyển đổi đã xảy ra đến năm 2003)

   Bus 001 Device 008: ID 19d2:1232 ZTE WCDMA Technologies MSM
   

5. Đã đẩy modem.

Tệp nhật ký hệ thống và tệp quy tắc được đề cập (40) có tại đây

Cập nhật 18 - 11 tháng 12 năm 2015

1. Đặt tất cả các tệp quy tắc ở dạng ban đầu của họ.

2. Đã xem lsusb đầu ra mỗi một giây bằng cách sử dụng tập lệnh shell. Đầu ra bị bắt trong các tập tin đóng dấu thời gian.

3. Chèn modem. (Modem đầu tiên xuất hiện trong tệp lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt). Như chúng ta có thể tìm thấy từ các ảnh chụp, rõ ràng là nó chuyển từ thiết bị 1232 sang thiết bị 2003.

4. Đã thử kết nối. Không thành công.

5. Đã đẩy modem.

Tệp nhật ký hệ thống, lsusbđầu ra được đóng dấu thời gian và các tệp quy tắc được đề cập ở đây .

Bây giờ, bạn có thể muốn khớp các đầu ra syslog với tem thời gian.

Cập nhật ngày 19 - 11 tháng 12 năm 2015

Thực hiện thử nghiệm này theo hướng hoàn toàn mới với mong muốn tôi có thể cô lập các vấn đề.

1. Lưu trong một phương tiện di động /lib/udev/rules.d/40-usb-media-players.rulesvà/lib/udev/rules.d/77-mm-zte-port-types.rules (từ máy Ubuntu 15.10).

2. Khởi động máy bằng DVD Xubfox 15.04 64 bit.

3. Thi công diff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txt. Tệp đầu tiên là từ tệp được lưu từ 15.10.

   Kiểm tra tệp diff cho thấy không có idProduct1232 hay 2003.

4. Thi công diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txt. Một lần nữa, tệp đầu tiên là từ tệp được lưu từ 15.10.

   Một lần nữa, kiểm tra tệp diff cho thấy không có idProduct1232 hoặc 2003.

5. Chèn modem. Modem được công nhận là modem.

   $ lsusb
   Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
   

6. Có thể kết nối dễ dàng sau khi thiết lập kết nối băng thông rộng di động.

7. Đã đẩy modem.

8. Đã cài đặt USB_ModeSwitch mới nhất.

   diff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules
   

   Bây giờ trả về NULL, như mong đợi.

9. Thi công sudo udevadm control --reload-rules.

10. Chèn modem. Modem được công nhận là modem.

    $ lsusb
    Bus 001 Device 008: ID 19d2:2003 ZTE WCDMA Technologies MSM
    

11. Có thể kết nối dễ dàng.

Tôi có thể đã thử nâng cấp MM và NM lên Ubuntu 15.10, để xem nó bị hỏng ở đâu. Tôi thực sự đã cố gắng nhưng đã từ bỏ do vấn đề phụ thuộc vô tận.

Tất cả các tập tin khác nhau được đề cập ở trên là ở đây .

Cập nhật ngày 20 - 12 tháng 12 năm 2015

Kiểm tra 1

1. Trong /lib/udev/rulestình trạng ban đầu.

2. Thiết bị modem chưa được chèn trong phiên này.

3. Thiết lập ModemManager để gỡ lỗi và thiết lập chụp udevadm.

   sudo udevadm monitor --e |& tee udevadm.update20.WITHOUT78.log
   sudo killall ModemManager; sudo ModemManager --debug 2>&1 | tee MM.update20.WITHOUT78.log
   

4. Cắm modem và đợi cho đến khi nó nói rằng nó được đăng ký trong mạng băng thông rộng.

5. Đã thử kết nối không thành công.

6. Đã đẩy modem.

7. Đóng gói các tập tin nhật ký.

Kiểm tra 2

Lặp lại thử nghiệm trên với /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulestại chỗ.

Tên tệp nhật ký là tự giải thích.

Tất cả các tệp nhật ký trên cộng với syslog và các tệp quy tắc 78 đều có ở đây .

Tôi muốn tất cả các tệp nhật ký đi kèm với dấu thời gian, làm cho khớp dễ dàng hơn.

Cập nhật ngày 21 - 15 tháng 12 năm 2015

1. Thay đổi tệp quy tắc theo đề xuất.
2. Khởi động lại máy của tôi.
3. Chèn modem và thử kết nối. Nó không hoạt động.

Các tập tin quy tắc và sysloglà đây .

Cập nhật ngày 22 - 16 tháng 12 năm 2015

Theo lời khuyên trong một nhận xét, đã cài đặt các hạt nhân khác nhau từ http://kernel.ubfox.com/~kernel-ppa/mainline/ và thử kết nối bằng modem sau khi khởi động từng cái.

1. 4.2.8-040208 - chung chung, thất bại.

2. 4.1.15-040115 - chung chung, thất bại.

3. 4.0.9-040009-chung, thất bại.

Vì vậy, có lẽ, chúng ta có thể loại trừ vấn đề kernel.

Cập nhật ngày 23 - 16 tháng 2 năm 2016

Modem đã bắt đầu hoạt động trong Ubuntu 16.04. Phiên bản này vẫn ở Alpha 1, nhưng hoạt động tốt trong máy tính xách tay của tôi.

Tải ofonogói đã làm tốt, có thể, nhưng rõ ràng mô hình modem của bạn, ZTE MF193E, không có trong danh sách ZTE. So sánh nó với các modem ZTE khác, ví dụ như MF190J, modem này có thể cần cùng một udevquy tắc đặc biệt , để chạy usb_modeswitchkhi dongle được chèn và để đạt được, bạn có thể, thêm một udevquy tắc mới vào tệp
/lib/udev/rules.d/40-usb_modeswitch.rules
với hai điều sau đây dòng ví dụ, một nơi nào đó gần # ZTE MF190Jbình luận:

# ZTE MF193E
ATTR{idVendor}=="19d2", ATTR{idProduct}=="2003", RUN+="usb_modeswitch '%b/%k'"

cộng với một dòng trống, vì vậy nó trông dễ chịu cho mắt.

Có lẽ nên khởi động lại sau đó, chỉ để thấy tất cả đều hoạt động như ma thuật :-)

Hay không. Như bạn đã biết, đây là nước sâu đối với tôi, nhưng nếu nó vẫn không hoạt động, một nhật ký gỡ lỗi ModemManager sẽ là cần thiết, cho một phỏng đoán hoang dã khác.

BIÊN TẬP:

Bây giờ tôi đang xem hai dòng trong modemmanager.txt:

[mm-broadband-bearer.c:1254] connect(): Launching 3GPP connection attempt with APN 'WAP'

và

[mm-broadband-bearer.c:994] parse_pdp_list(): Found PDP context with CID 1 and PDP type ipv4 for APN 'wap'

Tôi đoán đầu tiên đề cập đến băng thông rộng của bạn được thiết lập, trong khi cái sau đề cập đến ràng buộc bên trong với "bối cảnh PDP" (bất kể đó là gì). Nhìn bề ngoài, modem cung cấp 9 bối cảnh thay thế, bao gồm một bối cảnh apn='WAP', nhưngModemManager giải quyết cho một trường hợp không nhạy cảm.

Sự khác biệt trường hợp có thể là nguyên nhân của vấn đề tiếp theo: ví dụ: ppp muốn 'wap'cấu hình (chứ không phải 'WAP') và không tìm thấy nó, hoặc kết thúc từ xa mong đợiapn='WAP' , nhưng bị 'wap' mà nó bị nghẹt.

Tùy chọn đầu tiên có thể dễ dàng được kiểm tra (và có thể loại trừ, có thể) bằng cách thay đổi cấu hình của bạn để sử dụng 'wap' thay vì 'Wap'. Bạn có thể đã thử điều này trước đây, nhưng tại thời điểm đó không có ofonogói, vì vậy một thử nghiệm khác sẽ không bị tổn thương, mặc dù tùy chọn thứ hai có nhiều khả năng.

Tùy chọn thứ hai cũng là một vấn đề, với điều kiện là có một "PDP bối cảnh" chữ hoa có sẵn từ modem. Giải quyết vấn đề này, có vẻ như trường hợp không nhạy cảm là chính xác theo thông số (rõ ràng có liên quan) "3GPP TS 23.003 chương 9.1" và một bản vá để thực hiện điều này đã được thêm ModemManagervào tháng 11 năm ngoái (vào phiên bản mm-1-4, Tôi có thể tập hợp). Vì vậy, trong trường hợp này, modem của bạn đã không được thông báo và nó mong đợi kết ModemManagerhợp phân biệt chữ hoa chữ thường , trong khi không may sử dụng khớp không phân biệt chữ hoa chữ thường chứ không phải là dự phòng.

Tất nhiên, một giải pháp cho vấn đề thứ hai là sử dụng một cách khác ModemManager: bằng cách tìm và cài đặt một phiên bản trước bản vá này, hoặc (với đủ thời gian rảnh rỗi), hãy tự lăn ModemManager. Nhưng không phải là một cái gì đó để làm bất cứ điều gì, vì vậy có lẽ chúng ta cần duyệt qua một chút để có thêm bằng chứng cho thấy đây là (bây giờ) vấn đề, và nếu có thể hãy tìm cách khác để giải quyết. Hoặc với một chút may mắn, một người biết điều gì đó rơi xuống ...

CHỈNH SỬA 2

Có, rollback phiên bản không dễ dàng do phụ thuộc. Và lăn của riêng bạn là xa niềm vui là tốt.

Hai công cụ hữu ích có thể có: lệnh mmclivà ( http://m2msupport.net/m2msupport/module-tester/ ).

Vấn đề, tôi nghĩ, đó là ModemManager chọn bối cảnh PDP 1 với apn = 'wap' trong đó nên chọn bối cảnh PDP 9 với apn = 'Wap'. Có lẽ điều này có thể được giải quyết bằng cách sử dụng một trong những công cụ đó. Có thể buộc lựa chọn 9 trong khi kết nối hoặc bằng cách xóa các bối cảnh 'wap' xấu khỏi modem, công cụ kiểm tra mô-đun được quảng cáo là có khả năng.

Công cụ kiểm tra modem dường như là một công cụ java trong trình duyệt, vì vậy bạn cần trình duyệt của mình được thiết lập để biết java của bạn ở đâu và bạn cần biết java đó. Sau đó, hãy khám phá cách tiếp cận đó; Tôi đã không sử dụng nó cho mình, nhưng nhìn thấy các ảnh chụp màn hình, tôi đoán nó sẽ hiển thị bối cảnh PDP dưới dạng tab 'Cuộc gọi dữ liệu', nơi đầu tiên bạn ghi chú mọi thứ nó hiển thị, sau đó chỉnh sửa các mục 'wap' làm biến dạng các nhãn apn 'wap' thành 'wap1' và 'wap2' (để "ẩn" chúng khi tìm kiếm 'Wap'). Sau đó lưu và đóng lại, và tung ra dongle một lần nữa. Lấy một bản ghi; Bây giờ có vẻ như syslog là đủ, trong trường hợp nó vẫn không chịu chơi.

Các mmclilệnh cũng có vẻ hữu ích trong câu chuyện này; làm man mmcliđể đọc về nó, nhưng tôi không thấy gì về bối cảnh PDP ở đó.

EDIT 3

Cuộc gọi tốt để kiểm tra từ DVD. Điều đó nói với chúng tôi rằng tôi đang đi sai hướng với APN, và tất cả nằm ở việc đưa ppp đi lên. Ít nhất, đó sẽ là cây mới của tôi sủa.

Trước tiên, chúng tôi lưu ý rằng có một sự khác biệt về phiên bản cho pppd (từ 2.4.5 đến 2.4.6), nhưng đó có lẽ không phải là vấn đề, vì khi đó mọi người trên dongle sẽ tham gia chuyến đi này.

Hừm, ppp; Tôi cần khuấy động những ký ức thiên niên kỷ trước :-). Thật không may hôm nay tôi bận, nhưng tôi sẽ chạm vào căn cứ khi tôi có thời gian, để xem bạn đã đi được bao xa. Những con hẻm đầu tiên của tôi để xem xét sẽ là: 1) người dùng có đúng nhóm không? 2) là các thông tin phải không? 3) các mod tập tin cấu hình ppp / chat phải không? Nhật ký gỡ lỗi ppp xuất hiện trong nm.txt (như một vài ngày trước), nhưng cũng nên có một cách để yêu cầu nó đăng nhập chi tiết hơn.

CHỈNH SỬA 4

Đảm bảo /etc/ppp/pap-secretsvà /etc/ppp/chap-secretscó nhóm dip(sử dụng chgrpkhi cần thiết) và chế độ 740(hoặc -rw-r-----) (sử dụng chmodkhi cần thiết). Của tôi thì không.

CHỈNH SỬA 5

Thế còn cây này thì sao: So sánh wvdialsyslog đang hoạt động với syslog không hoạt động, có vẻ như vì một lý do nào đówvdial được sử dụng ttyUSB3trong khi không làm việc ModemManagertiếp tục sử dụng ttyUSB1. Tôi không chắc chắn nếu nó ở tất cả các ý nghĩa, nhưng dường nhưng ttyUSB1và ttyUSB3cả phản ứng như modem có khả năng AT.

Vì vậy, như một bài kiểm tra, có lẽ bạn có thể chỉnh sửa /etc/wvdial.conf để nó [Dialer Defaults]bao gồm dòng:

Modem = /dev/ttyUSB1

cho một bài kiểm tra, và ttyUSB3cho một bài kiểm tra khác; Cả hai đều chạy như root; chỉ để xem nếu có một hành vi khác nhau. Đặc biệt, nếu việc sử dụng ttyUSB1là một vấn đề trong khi sử dụng ttyUSB3 thì không, vậy thì cũng nên xem xét cách làm cho ModemManager sử dụng ttyUSB3. Đối với bất kỳ kết quả thử nghiệm nào khác, tôi muốn nói rằng chúng tôi sẽ quay trở lại để đuổi theo những con chồn trong vùng đất ppp.

CHỈNH SỬA 6

Nhật ký dmesg có thể bị bỏ qua tôi nghĩ; nó là như thế trong tất cả các bản ghi. Syslog mới chỉ hiển thị thử nghiệm ttyUSB3, nhưng có lẽ chúng ta có thể cho rằng cuộc sống sẽ tốt hơn nếu NetworkManagercó thể sử dụng ttyUSB3 và bỏ qua ttyUSB1 (cho modem này).

Tôi cũng đã tìm thấy ( https://bugs.launchpad.net/ubfox/+source/modemmanager/+orms/819784 ) với bài đăng đặc biệt # 10 disconcerting :-(

udevQuy tắc áp dụng rõ ràng /lib/udev/rules.d/77-mm-zte-port-types.ruleskhông áp dụng, nhưng được cho là sẽ đi đâu. Và, chỉ với một cái nhìn sâu sắc rất thô sơ, trước 101 về udevma thuật, dù sao tôi cũng sẽ xem xét việc đặt câu hỏi cho dòng thứ 4 của nó, trong đó nói:

SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end"

Tôi nghĩ rằng dòng đó cần một sự khởi đầu # cái để được nhận xét. Cụ thể, việc đọc tệp của tôi là nó yêu cầu trạng thái gọi là SUBSYSTEM == "tty" và SUBSYSTEMS = "usb" để sử dụng các bit tốt, bao gồm các quy tắc sản phẩm "2003" và ít nhất là để kiểm tra, Sẽ an toàn khi bỏ qua bộ lọc "tty". Và tôi không có gì tốt hơn ngay bây giờ.

EDIT 7

Sau khi dành một chút thời gian chất lượng với công cụ tìm kiếm yêu thích của tôi, tôi tin thêm một chút rằng sự lựa chọn ttyUSB là một vấn đề gốc ở đây. Quy tắc udev tôi đã chỉ là ok, và bạn nên hoàn nguyên chỉnh sửa đó.

Tuy nhiên, tôi đã bắt đầu tin rằng các quy tắc cấu hình vào cuối tệp đó, đối với id sản phẩm "2003" là sai lệch. Từ nhật ký, theo tôi, id sản phẩm "2003" thực sự là phía thiết bị bộ nhớ của dongle, trong khi phía modem có id sản phẩm "1232". Bạn có thể kiểm tra điều này bằng cách sao chép hai quy tắc "2003" cho id sản phẩm "1232", trong tệp/lib/udev/rules.d/77-mm-zte-port-types.rules

ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="1232", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"

hoặc tốt hơn, thêm một tệp mới bên cạnh nó, ví dụ như được đặt tên 78-ralph.rules, nhưng sau đó bạn cũng cần thêm bảo vệ SUBSYSTEM và SUBSYSTEMS xung quanh nó.

Sau đó, rút ​​khóa, chạy udevadm control --reload(hoặc khởi động lại) và chèn khóa. Và sau đó một lần syslogchụp khác , trừ khi nó xảy ra để làm việc.

Tuy nhiên, vấn đề hiệu quả là ModemManager loại bỏ plugin libmm-plugin-zte.sokhi thử nghiệm trước và kết thúc bằng trình xử lý modem chung. Nếu tôi đúng về id sản phẩm, thì đây có thể là lý do; việc thăm dò trước đó tìm kiếm một sự ID_MM_ZTE_PORT_TYPE_MODEMghi nhận và điều này thiếu cho id sản phẩm "1232" (trước bản vá), với hiệu ứng mà plugin zte bị loại bỏ.

CHỈNH SỬA 8

Các syslogbản ghi là một chút ngắn; thiếu phần mở đầu khi ModemManager không cài đặt được plugin zte. Tuy nhiên, rõ ràng là plugin Modem chung được sử dụng bằng mọi cách. Bây giờ, có thể usb_modeswitchquy tắc tôi đưa ra cho bạn sớm cũng sai; nó quyết định chuyển sang "2003" khi tôi nghĩ nó đã chuyển từ "2003". Nhưng, man usb_modeswitch(mà tôi nên xem xét trước đây) loại gợi ý rằng nó chuyển sang id sản phẩm hơn là từ nó. Trong mọi trường hợp, nhật ký cho thấy điều đó xảy ra. Do đó, vui lòng thay đổi quy tắc đó để sử dụng "1232" thay vào đó và thử lại.

Nếu không có gì khác, ít nhất tôi đã phải tìm hiểu một chút về udev.

CHỈNH SỬA 9

Tốt Vấn đề vẫn là (hoặc cũng) rằng ModemManager bỏ plugin ZTE khi thăm dò trước. Nhật ký gỡ lỗi ModemManager cho 15.10 (bộ nhật ký "gỡ lỗi *") đều nói lên câu chuyện rằng plugin ZTE bị loại bỏ do kiểm tra id nhà cung cấp / sản phẩm-id.

Về nguồn, Luke!Tôi đã nhân cơ hội này để xem nhanh mã nguồn ModemManager và nó chỉ ra rằng plugin dưới dạng bảng vid / pid không bao gồm 19d2 / 2003 ... mặc dù vậy, tôi không tìm thấy nguồn bảng đó, vì vậy tôi không thể xác minh

Hoặc có thể có một vấn đề thời gian ở đây. Ví dụ, ModemManager chạy thử nghiệm trước trong khi thiết bị là 19d2 / 1232. Suy nghĩ đó phù hợp với quan sát rằng việc có các quy tắc RALPH.rules udev 78-mm-zte-port-type-RALPH.rules làm cho ModemManager vui hơn một chút với thiết bị. Nhưng sau đó, tại sao nó không vui và sử dụng plugin đó khi thiết bị được chuyển sang 19d2 / 2003?

Có thể cần thêm nhật ký :-) Với gỡ lỗi ModemManager và cũng có thể bắt lệnh udevadm monitor --e |& tee udevadm.log(trong một thiết bị đầu cuối khác) khi bạn cắm thiết bị. Tôi đã nhận lệnh đó từ ( https://wiki.ubfox.com/DebuggingUdev )

Làm điều này hai lần: một lần mà không 78-mm-zte-port-types-RALPH.rulesvà một lần với các quy tắc ... cả hai lần từ lần khởi động lại mới. I E

1. thiết lập /lib/udev/rules.dcó hoặc không có *-RALPH.rulestập tin
2. rút thiết bị ra
3. khởi động lại
4. thiết lập ModemManager để gỡ lỗi và thiết lập chụp udevadm
5. cắm thiết bị và đợi một phút
6. đóng gói các tập tin nhật ký
7. lặp lại từ 1 với bài kiểm tra tiếp theo

Việc ghi nhật ký đó sẽ cho biết nơi plugin ZTE bị bỏ và theo tôi hiểu, nó cũng sẽ nói về việc xử lý sự kiện udev.

CHỈNH SỬA 10

(Tôi sắp hết dây buộc ở đây, nhưng tôi còn một hoặc hai hơi thở nữa :-)

Đầu tiên, tất cả các udevtrang trí dường như kết thúc như họ nên, chỉ với một vài dấu hỏi trong một vài thuộc tính. Đặc biệt, 78-*-RALPH.rulesnên vứt bỏ; nó không hữu ích

Tôi nghĩ rằng tôi có thể đọc được thứ gì đó từ cái này, nhưng tôi không chắc chắn chính xác nó nên được sửa như thế nào. Về cơ bản, như tôi thấy, khi dongle được cắm vào, có một loạt các sự kiện udev. Tập trung vào những vấn đề liên quan đến ttyUSB1, có một sự kiện "sớm":

KERNEL[3867.310990] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1 (usb)

Điều này làm cho usb_serialtrình điều khiển được tải, và /dev/ttyUSB1xuất hiện. Điều đó đặc biệt gây ra một sự kiện khác:

KERNEL[3867.435102] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

Tôi nghĩ rằng cũng kích hoạt ModemManager. Bạn phải đi để syslogxem bằng chứng về điều này, vì không có mối tương quan chặt chẽ giữa các bản ghi. Sự kiện này được đóng dấu thời gian 3867.435102và syslogtrình bày ModemManagerdòng nhật ký tiếp theo gần nhất ngay sau khi dòng nhật ký kernel được đóng dấu 3867.437412.

Theo dòng suy nghĩ của tôi, ModemManagerkhông nên được kích hoạt mà chỉ sau sự kiện ttyUSB1 tiếp theo:

UDEV  [3867.580427] add      /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.1/ttyUSB1/tty/ttyUSB1 (tty)

đã gắn các thuộc tính ZTE.

Trong nhật ký MM, chúng ta sẽ ở dòng được đóng dấu 1449934745.363291, rõ ràng là tem thời gian "thời gian thực" chứ không phải là tem "thời gian hạt nhân".

ModemManagersau đó được thực hiện với việc thăm dò trước tại 1449934745.450398, tức là 87ms sau đó, theo thuật ngữ thời gian hạt nhân sẽ gần3867.524519 và 55ms trước báo cáo sự kiện UDEV "tốt" ở trên.

Lưu ý rằng syslog, trong các ModemManagerkhiếu nại ttyUSB1không có thuộc tính được đặt và có thể khiếu nại đó có liên quan đến "đánh dấu" xảy ra 80-mm-candidate.rules. Theo nhận xét trong tập tin đó, việc đánh dấu đó dường như là một nỗ lực để giải quyết chính xác vấn đề này, nhưng nếu vậy, nó dường như không hoạt động trong trường hợp này.

Có lẽ một khả năng để giải quyết điều này sẽ là thay đổi quy tắc "tty" 80-mm-candidate.rulesthành:

ENV{.ID_PORT}=="?*", SUBSYSTEM=="tty", ENV{ID_MM_CANDIDATE}="1"

Trong tâm trí của tôi, điều đó sẽ đảm bảo rằng ID_MM_CANDIDATEcài đặt bị trì hoãn cho đến khi các thuộc tính ZTE được đặt. Các .ID_PORTthiết lập là kết quả của một 60-serial.rulesquy tắc (gọi 60-persistent-serial.rulestrước đó), và các điều kiện bổ sung vào quy tắc đánh dấu đơn giản là nó có một giá trị.

Điều kiện không chính xác là một thuộc tính ZTE, chỉ để giữ cho quy tắc chung chung hơn. ENV{.MM_USBIFNUM}="?*"Thay vào đó, một bước cụ thể hơn là yêu cầu thay vì việc chuyển nhượng ở đây xảy ra 77-mm-zte-port-types.rules.

Nói chung, tôi không chắc lắm về udevthứ tự quy tắc, và tôi cũng không chắc chắn rằng điều này thực sự dừng ModemManagerhành động quá nhanh. Tuy nhiên, nếu không, thì 80-mm-candidate.rulessẽ có rất ít chức năng, và có lẽ sau đó tất cả sẽ chuyển sang "cải tiến" ModemManagertừ ngày 15.04.

EDIT 21

thở dài. Có thể không liên quan, nhưng bạn có thể muốn kiểm tra7-zte-mutil_port_device.rules tệp ; đó có phải là tàn dư từ thí nghiệm khác không? Nhưng dù sao, không liên quan ở đây.

Vẫn còn gần một giây giữa 515.558184và 516.381549nơi ModemManagerháo hức và lấy nhầm /dev/ttyUSB1, và trong khi phàn nàn về việc nó không được thiết lập, vẫn trải qua quá trình thăm dò trước và loại bỏ plugin ZTE. Nói cách khác, bản vá quy tắc không làm cho ModemManagerchờ đợi.

Tôi cho rằng bạn cũng đã thử nghiệm bằng cách sử dụng ENV{.MM_USBIFNUM}="?*"thay vìENV{.ID_PORT}=="?*" .

Trên thực tế, để xác nhận xem cài đặt ENV{ID_MM_CANDIDATE}=1có quan trọng hay không , bạn nên tạm thời di chuyển đi 80-mm-candidate.rules, sau đó xem (trong syslog) nếu sau đó ModemManagerbỏ qua/dev/ttyUSB1 hay không. Tôi nghi ngờ "không".

Và sau đó, có lẽ bạn có thể sử dụng một phiên bản hoạt động, chẳng hạn như 14.04, và nếu bạn cần, có thể chạy 15.10 trong một hộp ảo, trừ khi tất nhiên đó là tất cả trong một hộp ảo.

Tôi nghĩ rằng tôi cần phải nhận thất bại tại thời điểm này.

Modem đã bắt đầu hoạt động trong Ubuntu 16.04. Phiên bản này vẫn đang trong giai đoạn phát triển, nhưng hoạt động tốt trong máy tính xách tay của tôi.

Tôi ước tôi có thể cung cấp thêm chi tiết kỹ thuật về cách nó bắt đầu hoạt động.

Sau khi nhìn thoáng qua, có vẻ như đây không phải là lần đầu tiên con rồng này được xử lý đúng cách. Đó là một lỗi trước đó vào ngày 12.10 và 13.04 có lẽ lỗi không bao giờ được sửa hoặc một bản vá mới đã phá vỡ thứ gì đó hoạt động chính xác trước đó.

Hy vọng rằng, nếu tôi đang đọc chính xác thông số kỹ thuật của bạn, tôi sẽ cần chỉ cho bạn hướng này (MF190J):

Modem 3G (ZTE MF190J) vẫn yêu cầu tinh chỉnh thủ công.

Bạn đã thử điều này:

 rfkill list up

và sau đó tạo tập lệnh này và chạy nó:

 #/bin/sh

     Case [!$] in
        /bin/sh
        networkname="true"
        networkname="the ip adr type in here"
        nmcli nm networkname --force-yes
        resolve.conf the ip adr type in here
     endl

và nó có thể hoạt động tốt theo cách này.