ข้อผิดพลาด 'ip-config-ไม่พร้อมใช้งาน' เมื่อโมเด็ม USB พยายามเชื่อมต่อ

ฉันมีโมเด็ม ZTE MF-193E ซึ่งใช้งานได้ดีมาก่อน เมื่อฉันซื้อโมเด็มนี้มานานกว่าหนึ่งปีมันใช้ได้ทันทีจากกล่อง ตอนนี้เมื่ออูบุนตูกำลังก้าวหน้าในเวอร์ชั่นสิ่งต่าง ๆ ก็เริ่มยากขึ้นสำหรับฉัน

โมเด็มนี้ใช้งานได้สองสามเดือนกับ Ubuntu 15.04 (64 บิต) ตอนนี้ใน Ubuntu 15.10 (64 บิต) ก็ไม่สามารถเชื่อมต่อได้

ฉันได้ตั้งค่าการเชื่อมต่อบรอดแบนด์มือถือแล้ว ฉันได้ลองใช้สตริงต่าง ๆ สำหรับ APN แล้ว แต่ยังไม่เคยมีปัญหามาก่อน

(โมเด็มทำงานได้ดีใน Windows 10 ดังนั้นนี่ไม่ใช่ปัญหาฮาร์ดแวร์เลยนอกจากนี้Modem Manager GUIตรวจจับอุปกรณ์นี้ได้ดีสามารถส่งและรับ SMS ได้โดยไม่มีปัญหาใด ๆ )

เมื่อฉันใส่โมเด็มมันจะตรวจพบไม่เป็นไรไอคอนซีดีจะแสดงใน Unity พร้อมชื่อของโมเด็ม ไม่กี่วินาทีต่อมาฉันได้รับกล่องข้อความ

Mobile Broadband Network: you are registered on the home network

ใกล้กับไอคอนเครือข่าย

เมื่อฉันพยายามเชื่อมต่อไอคอนไร้สายในแอปเพล็ตผู้จัดการเครือข่ายจะเริ่มการเคลื่อนไหวแบบแรงเหวี่ยง แต่ในที่สุดมันก็ล้มเหลวในการเชื่อมต่อและมีข้อความบอกว่าฉันออฟไลน์

เส้นที่ฉันสามารถแยกได้/var/log/syslogคือ

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

แม้ว่าฉันไม่แน่ใจว่านี่เป็นสิ่งที่เกี่ยวข้องหรือไม่

บรรทัดที่มากขึ้นจากการ /var/log/syslogที่สามารถพบได้ที่นี่

อัปเดต 1 - 06 ธันวาคม 2558

ตามที่สมาชิกประเภทหนึ่งชี้ให้เห็นลองใช้nf_conntrack_pptpวิธีการของโมดูล

ดำเนินการคำสั่งต่อไปนี้

$ 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

จากนั้นลองโมเด็มของฉันล้มเหลวแบบเดียวกัน ไม่มีการเปลี่ยนแปลงที่สังเกตเห็นได้ในบันทึก

อัปเดต 2 - 06 ธันวาคม 2558

ดำเนินการเป็นราก

systemctl restart network-manager.service

ไม่มีเอาต์พุตบนหน้าจอ (เทอร์มินัล)

ที่สอดคล้องกับการเข้าสู่ระบบจากจุดดังกล่าวข้างต้นที่จะพยายามที่จะเชื่อมต่อโดยใช้โมเด็มที่สามารถพบได้ที่นี่

อัปเดต 3 - 06 ธันวาคม 2558

ติดตั้งofonoแล้วลองโมเด็มอีกครั้ง

โปรดดูบันทึกที่นี่

อัปเดต 4 - 06 ธันวาคม 2558

ดำเนินการอีกครั้งเป็นราก

systemctl restart network-manager.service

ที่สอดคล้องกับการเข้าสู่ระบบจากจุดดังกล่าวข้างต้นที่จะพยายามที่จะเชื่อมต่อโดยใช้โมเด็มที่สามารถพบได้ที่นี่

อัปเดต 5 - 06 ธันวาคม 2558

การเปลี่ยนแปลงทั้งหมด "ปฏิเสธ" เป็น "อนุญาตให้" /etc/dbus-1/system.d/nm-dispatcher.confใน

พยายามเชื่อมต่อ ไม่มีโชค.

เครือข่ายบางอย่างเชื่อมต่อและยกเลิกการเชื่อมต่อกับการเชื่อมต่ออีเธอร์เน็ต

sudo systemctl restart network-manager.serviceตามมาด้วย

โมเด็มเสียบและเสียบปลั๊กแล้ว

พยายามเชื่อมต่ออีกครั้ง ไม่ได้เชื่อมต่อ

บันทึกเป็นที่นี่

อัปเดต 6 - 06 ธันวาคม 2558

ดำเนินการ

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

และ

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

ไม่สามารถทำงานได้mm-test.pyเนื่องจากข้อผิดพลาดหลายอย่าง ค้นหาไฟล์ที่ตำแหน่งที่ระบุ ได้รับนี้จากhttps://github.com/openshine/ModemManager/blob/master/test/mm-test.py

คำสั่งดังกล่าวค่อนข้างแตกต่างจากคำสั่งใน Wiki

แฟ้มบันทึกอยู่ที่นี่

อัพเดท 7 - 07 ธันวาคม 2558

ดำเนินการอีกครั้ง (หลังจากการเปลี่ยนแปลงที่แนะนำใน/lib/udev/rules.d/40-usb_modeswitch.rulesและรีบูต)

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

และ

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

/var/log/syslogจะรวมเป็นอย่างดี

แฟ้มบันทึกอยู่ที่นี่

อัปเดต 8 - 8 ธันวาคม 2558

ชุดปรับปรุงของล็อกที่นี่

อัปเดต 9 - 8 ธันวาคม 2558

ทดสอบ 1

1. คราวนี้บูตคอมพิวเตอร์จาก DVD Ubuntu ขนาด 14.04 32 บิต ทันทีที่คอมพิวเตอร์บูตเครื่องเริ่มบันทึก MM

2. ใส่โมเด็ม lsusbแสดงให้เห็นว่ามันได้รับการยอมรับว่าเป็นอุปกรณ์ 19d2: 1232 ซึ่งจำเป็นต้องได้รับการ swithced กับอุปกรณ์ 19d2: 2003 เนื่องจากการติดตั้ง usb-modeswitch ต้องมีการรีบูทเครื่อง (และทำให้การติดตั้ง DVD หลวม) ฉันจึงเตรียมไฟล์สวิตช์แบบกำหนดเองและเปลี่ยนโมเด็มจากบรรทัดคำสั่ง ( sudo usb_modeswitch -I -c 19d2:2003)

3. ทันทีที่การสลับสำเร็จฉันได้รับแจ้งว่าฉันเปิดอยู่Mobile Broadband Networkและมีการเชื่อมต่อบรอดแบนด์ใหม่ในเมนูตัวจัดการเครือข่าย

4. ฉันตั้งค่าการเชื่อมต่อข้างต้นตามปกติ (ชื่อ APN ไม่ใช่ปัญหา) และการเชื่อมต่อนั้นถูกสร้างขึ้นโดยอัตโนมัติ

5. ฉันตัดการเชื่อมต่อและนำโมเด็มออก

6. หยุดการบันทึกล็อก MM

บันทึก MM สมบูรณ์และ syslog สำหรับการเริ่มต้นเซสชั่นกับโมเด็มดีดออกสามารถพบได้ที่นี่

ทดสอบ 2

การทดสอบเดียวกันกับ Ubuntu 14.04 64 บิตดีวีดี

บันทึกสามารถพบได้ที่นี่

อัปเดต 10 - 09 ธันวาคม 2558

เวลานี้ทดสอบwvdialและพบว่าหากwvdialใช้งานเป็น root เราจะได้รับการเชื่อมต่อที่ประสบความสำเร็จ

wvdialconf และเข้าสู่ระบบและสอดคล้องกัน syslog อยู่ที่นี่

การคาดเดาหลัก: สถานการณ์อาจเกี่ยวข้องกับกลุ่มผู้ใช้ของผู้ใช้ที่เกี่ยวข้อง

แต่ตามที่ระบุไว้ที่นี่ ,

ด้วยเครื่องมือเหล่านี้ในการสร้างการเชื่อมต่อแบบ dialup ผู้ใช้จะต้องเป็นสมาชิกของกลุ่ม "dip" และ "dialout" ดังนั้นให้ผู้ใช้ทุกคนที่ควรจะเชื่อมต่อผ่าน dialup ในกลุ่มเหล่านี้

แต่อย่างที่เราสามารถหาได้

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

ดังนั้นผู้ใช้จึงเป็นสมาชิกของกลุ่มที่ระบุแล้ว

ทีนี้ปัญหาอาจจะเดือดร้อนไปจนถึงประเด็นเหล่านี้

1. กลุ่มเพิ่มเติมที่ผู้ใช้ต้องการจะเป็นอย่างไร
2. เราจะเรียกใช้กระบวนการตั้งค่าการเชื่อมต่อบรอดแบนด์ผ่านโทรศัพท์มือถือได้อย่างไร (ปัญหาด้านความปลอดภัย?)

อัปเดต 11 - 09 ธันวาคม 2558

wvdialทำงานได้กับ USB3 และไม่ทำงานกับ USB1

กรุณาหาที่ syslog ที่นี่

dmesg | grep tty > /tmp/dmesg.tty.txtรวมทั้งยังเป็นการส่งออกของ แต่เห็นสี่บรรทัดใกล้จุดเริ่มต้นของไฟล์หรือไม่

อัปเดต 12 - 10 ธันวาคม 2558

1. ออกความเห็นเส้นที่ 4 ( SUBSYSTEM!="tty", GOTO="mm_zte_port_types_end") /lib/udev/rules.d/77-mm-zte-port-types.rulesใน

2. รีบูตเครื่องของฉัน ซอฟต์ถอดสายเคเบิลและเสียบโมเด็ม

3. พยายามเชื่อมต่อ ไม่สำเร็จ

แฟ้ม syslog เป็นที่นี่

อัปเดต 13 - 10 ธันวาคม 2558

เพื่อดูว่าการเปลี่ยนแปลงภายในเครื่องมีผลต่อการเชื่อมต่อหรือไม่ทดสอบเครื่องด้วย Ubuntu 15.04 และ 15.10 ดีวีดี

1. บูตเครื่องด้วย Xubuntu 15.04 64 บิตดีวีดี การเชื่อมต่อนั้นประสบความสำเร็จอย่างมีเสน่ห์
2. บู๊ตเครื่องด้วย Ubuntu 15.10 64 บิตดีวีดี การเชื่อมต่อล้มเหลวเหมือนเมื่อก่อน

เกิดอะไรขึ้นระหว่าง 15.04 ถึง 15.10

น่าผิดหวังมาก

อัปเดต 14 - 10 ธันวาคม 2558

1. สร้างไฟล์ใหม่/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesตามคำแนะนำในคำตอบ

2. รีบูทเครื่องของฉัน (หรือดำเนินการsudo udevadm control --reloadลองทั้งสองอย่าง) ใส่โมเด็ม

3. โมเด็มรับรู้แล้ว

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

4. ซอฟต์ถอดสายเคเบิลออกแล้วพยายามเชื่อมต่อโดยใช้โมเด็ม ไม่สำเร็จ

5. นำโมเด็มออก

เครื่องค้างหนึ่งครั้งนั่นเป็นเหตุการณ์สุ่มหรือเปล่า เครื่องของฉันไม่ปกติแขวนปีละครั้ง

แฟ้ม syslog และไฟล์กฎที่สร้างขึ้นเป็นที่นี่

อัปเดต 15 - 11 ธันวาคม 2558

1. /lib/udev/rules.d/40-usb_modeswitch.rulesเพิ่มบรรทัดต่อไปนี้

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

2. ออกจากไฟล์/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesเหมือนเดิม

3. รีบูตเครื่องของฉัน ใส่โมเด็ม

4. โมเด็มรับรู้แล้ว

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

5. ซอฟต์ถอดสายเคเบิลออกแล้วพยายามเชื่อมต่อ ไม่สำเร็จ

6. นำโมเด็มออก

7. ลบออก/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesแล้ว

8. รีบู๊ตและลองกระบวนการทั้งหมดอีกครั้ง ไม่สำเร็จอีกครั้ง

แฟ้ม syslog (สมบูรณ์ผมไม่ได้เอาความเสี่ยงของการขาดหายไปส่วนหนึ่งที่สำคัญใด ๆ ) และแฟ้มกฎที่กล่าวถึง (40) เป็นที่นี่

อัปเดต 16 - 11 ธันวาคม 2558

1. เหลือกฎข้อเดียว 1232 ข้อ/lib/udev/rules.d/40-usb_modeswitch.rulesเอากฎ อีกข้อหนึ่งออก

2. ดำเนินการsudo udevadm control --reloadแล้ว

3. ใส่โมเด็ม

4. โมเด็มรับรู้แล้ว

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

5. ซอฟต์ถอดสายเคเบิลออกแล้วพยายามเชื่อมต่อ ไม่สำเร็จ

6. นำโมเด็มออก

แต่เราไม่ได้ทดสอบระบบเริ่มต้นด้านบนเหรอ? คุณหมายถึงออก/lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesจากที่นั่นหรือไม่?

ไฟล์ syslog (สมบูรณ์ฉันไม่เสี่ยงที่จะขาดส่วนสำคัญใด ๆ ) และไฟล์กฎที่กล่าวถึง (40) อยู่ที่นี่

อัปเดต 17 - 11 ธันวาคม 2558

1. ใส่ความคิดเห็นในกฎ 1232 /lib/udev/rules.d/40-usb_modeswitch.rulesเพิ่มอีกหนึ่งกฎ สำหรับปี 2003

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

2. ดำเนินการsudo udevadm control --reloadแล้ว

3. ใส่โมเด็ม

4. โมเด็มได้รับการยอมรับว่าเป็นอุปกรณ์1232 ฉันไม่ได้รับการเสนอให้ลองเชื่อมต่อ (เท่าที่ความรู้ของฉันมีต่อมันจะไม่ถูกลงทะเบียนกับเครือข่ายบรอดแบนด์เว้นแต่การสลับเกิดขึ้นกับปี 2003)

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

5. นำโมเด็มออก

ไฟล์ syslog และไฟล์กฎที่กล่าวถึง (40) อยู่ที่นี่

อัปเดต 18 - 11 ธันวาคม 2558

1. วางไฟล์กฎทั้งหมดในรูปแบบดั้งเดิม

2. ดูlsusbเอาต์พุตทุก ๆ วินาทีโดยใช้เชลล์สคริปต์ เอาต์พุตที่บันทึกในไฟล์ที่ประทับเวลา

3. ใส่โมเด็ม (โมเด็มปรากฏขึ้นเป็นครั้งแรกในไฟล์ lssuboutouput.Fri Dec 11 16:56:29 BDT 2015.txt) ดังที่เราสามารถหาได้จากการจับมันเป็นที่ชัดเจนว่ามันเปลี่ยนจากอุปกรณ์ 1232 ไปเป็น 2003

4. พยายามเชื่อมต่อ ไม่สำเร็จ

5. นำโมเด็มออก

แฟ้ม syslog เวลาประทับlsusbเอาท์พุทและแฟ้มกฎที่กล่าวถึงเป็นที่นี่

ตอนนี้คุณอาจต้องการจับคู่เอาต์พุต syslog กับการประทับเวลา

อัปเดต 19 - 11 ธันวาคม 2558

ดำเนินการทดสอบนี้ในทิศทางใหม่ที่สมบูรณ์พร้อมด้วยความปรารถนาที่ฉันสามารถแยกปัญหาได้

1. บันทึกในสื่อแบบพกพา/lib/udev/rules.d/40-usb-media-players.rulesและ/lib/udev/rules.d/77-mm-zte-port-types.rules(จากเครื่อง Ubuntu 15.10)

2. บูตเครื่องโดยใช้ Xubuntu 15.04 64 บิตดีวีดี

3. ดำเนินการdiff 77-mm-zte-port-types.rules /lib/udev/rules.d/77-mm-zte-port-types.rules > diff15.10and15.04_77-mm.txtแล้ว ไฟล์แรกมาจากไฟล์ที่บันทึกจาก 15.10

   การตรวจสอบไฟล์ diff แสดงหมายเลขidProduct1232 หรือ 2003

4. ดำเนินการdiff 40-usb_modeswitch.rules /lib/udev/rules.d/40-usb_modeswitch.rules > diff15.10and15.04_40-usb.txtแล้ว อีกครั้งไฟล์แรกมาจากไฟล์ที่บันทึกจาก 15.10

   การตรวจสอบไฟล์ diff อีกครั้งแสดงว่าไม่มีidProduct1232 หรือ 2003

5. ใส่โมเด็ม โมเด็มได้รับการยอมรับว่าเป็นโมเด็ม

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

6. สามารถเชื่อมต่อได้อย่างง่ายดายหลังจากตั้งค่าการเชื่อมต่อบรอดแบนด์มือถือ

7. นำโมเด็มออก

8. ติดตั้ง USB_ModeSwitch ล่าสุด

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

   ตอนนี้ส่งคืน NULL ตามที่คาดไว้

9. ดำเนินการsudo udevadm control --reload-rulesแล้ว

10. ใส่โมเด็ม โมเด็มได้รับการยอมรับว่าเป็นโมเด็ม

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

11. สามารถเชื่อมต่อได้อย่างง่ายดาย

ฉันสามารถลองอัปเกรด MM และ NM เป็น Ubuntu 15.10 เพื่อดูว่ามันหยุดอยู่ที่ใด จริง ๆ แล้วฉันพยายาม แต่ยอมแพ้เนื่องจากปัญหาการพึ่งพาที่ไม่รู้จบ

ไฟล์ทั้งหมดที่แตกต่างดังกล่าวข้างต้นเป็นที่นี่

อัปเดต 20 - 12 ธันวาคม 2558

ทดสอบ 1

1. /lib/udev/rulesในสภาพเดิม

2. ยังไม่ได้ใส่อุปกรณ์โมเด็มในเซสชันนี้

3. Setup ModemManager สำหรับการดีบักและตั้งค่าการจับ udevadm

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

4. ต่อโมเด็มและรอจนกว่าจะมีข้อความว่าลงทะเบียนในเครือข่ายบรอดแบนด์

5. พยายามเชื่อมต่อไม่สำเร็จ

6. นำโมเด็มออก

7. จัดทำไฟล์บันทึกการทำงาน

ทดสอบ 2

ซ้ำแล้วซ้ำอีกการทดสอบข้างต้นด้วย /lib/udev/rules.d/78-mm-zte-port-types-RALPH.rulesในสถานที่

ชื่อไฟล์บันทึกเป็นแบบอธิบายตนเอง

ทุกไฟล์บันทึกข้างต้นพร้อม syslog และแฟ้มกฎ 78 มี ที่นี่

ฉันหวังว่าไฟล์บันทึกทั้งหมดจะมาพร้อมกับการลงเวลาทำให้การจับคู่ง่ายขึ้น

อัปเดต 21 - 15 ธันวาคม 2558

1. เปลี่ยนไฟล์กฎตามที่แนะนำ
2. รีบูตเครื่องของฉัน
3. ใส่โมเด็มและพยายามเชื่อมต่อ มันไม่ได้ผล.

แฟ้มกฎและsyslogอยู่ที่นี่

อัปเดต 22 - 16 ธันวาคม 2558

ตามคำแนะนำในความคิดเห็นเดียวติดตั้งเคอร์เนลหลากหลายจาก http://kernel.ubuntu.com/~kernel-ppa/mainline/และลองเชื่อมต่อโดยใช้โมเด็มหลังจากบูทในแต่ละครั้ง

1. 4.2.8-040208- ทั่วไป, ความล้มเหลว

2. 4.1.15-040115-generic, failure

3. 4.0.9-040009- ทั่วไป, ล้มเหลว

ดังนั้นบางทีเราสามารถแยกแยะปัญหาเคอร์เนลได้

อัปเดต 23 - 16 กุมภาพันธ์ 2559

โมเด็มเริ่มทำงานใน Ubuntu 16.04 รุ่นนี้ยังอยู่ใน Alpha 1 แต่ใช้งานได้ดีในแล็ปท็อปของฉัน

กำลังโหลดofonoแพคเกจใช้งานได้ดี แต่เห็นได้ชัดว่ารุ่นโมเด็มของคุณคือ ZTE MF193E ไม่ได้อยู่ในรายชื่อ ZTE เมื่อเปรียบเทียบกับโมเด็ม ZTE อื่น ๆ เช่น MF190J โมเด็มนี้มีความจำเป็นที่จะต้องใช้udevกฎพิเศษแบบเดียวกันเพื่อให้ทำงานได้usb_modeswitchเมื่อใส่ด็องเกิลและเพื่อให้ได้รากคุณสามารถเพิ่มกudevฏใหม่ลงในไฟล์ที่
/lib/udev/rules.d/40-usb_modeswitch.rules
มีสองต่อไปนี้ บรรทัดเช่นบางแห่งใกล้กับ# ZTE MF190Jความคิดเห็น:

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

บวกกับบรรทัดว่างดังนั้นจึงดูสบายตา

มันอาจฉลาดที่จะรีบูตหลังจากนั้นเพียงเพื่อจะพบว่ามันใช้งานได้ดีอย่างวิเศษ :-)

หรือไม่. อย่างที่คุณรู้นี่เป็นน้ำลึกสำหรับฉัน แต่ถ้ามันยังใช้งานไม่ได้จะต้องมีการแก้ไขข้อบกพร่องของ ModemManager อีกอันสำหรับการคาดเดาอย่างอื่น

แก้ไข:

ตอนนี้ฉันกำลังดูสองบรรทัดใน modemmanager.txt:

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

และ

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

ฉันเดาว่าสิ่งแรกคือการตั้งค่าบรอดแบนด์ของคุณในขณะที่สิ่งหลังหมายถึงการเชื่อมโยงภายในกับ "บริบท PDP" (อะไรก็ตามที่เป็น) โดยลักษณะของมันที่โมเด็มข้อเสนอ 9 บริบททางเลือกรวมถึงคนที่มีapn='WAP'แต่ModemManagersettles สำหรับกรณีที่ตรงกับความรู้สึก

ความแตกต่างของเคสอาจเป็นสาเหตุของปัญหาที่ตามมา: เช่น PPP นั้นต้องการการ'wap'กำหนดค่า (มากกว่า'WAP') และไม่พบมันหรือว่าปลายทางจากระยะไกลคาดหวังapn='WAP'แต่จะได้รับ 'WAP' ซึ่งทำให้เกิด

ตัวเลือกแรกสามารถทดสอบได้อย่างง่ายดาย (และอาจตัดออก) โดยการเปลี่ยนการกำหนดค่าของคุณเพื่อใช้ 'WAP' แทน 'WAP' คุณอาจเคยลองทำมาก่อน แต่ในเวลานั้นไม่มีofonoแพ็คเกจดังนั้นการทดสอบอื่นจะไม่เจ็บแม้ว่าตัวเลือกที่สองมีแนวโน้มมากกว่า

ตัวเลือกที่สองเป็นปัญหามากกว่าเนื่องจากมีตัวพิมพ์ใหญ่ "บริบท PDP" ที่พร้อมใช้งานจากโมเด็ม Googling ปัญหานี้ปรากฏว่าการจับคู่แบบตรงตามตัวพิมพ์เล็กนั้นถูกต้องตามข้อกำหนด (เห็นได้ชัดว่าเกี่ยวข้อง) "3GPP TS 23.003 ตอนที่ 9.1" และมีการเพิ่มโปรแกรมแก้ไขModemManagerในเดือนพฤศจิกายนปีที่แล้ว (เป็นรุ่น mm-1-4 ฉันสามารถรวบรวม) ดังนั้นในกรณีนี้โมเด็มของคุณยังไม่ได้รับการบอกกล่าวและคาดว่าจะตรงตามModemManagerตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก แต่น่าเสียดายที่ใช้ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ตรงแทนที่จะเป็นทางเลือก

ทางออกหนึ่งสำหรับปัญหาที่สองเป็นของหลักสูตรที่จะใช้ที่แตกต่างกันModemManagerอย่างใดอย่างหนึ่งโดยการค้นหาและติดตั้งเวอร์ชันก่อนแพทช์นี้หรือ (มีเวลาว่างพอ) ModemManagerม้วนของคุณเอง แต่ก็ไม่ได้เป็นสิ่งที่ต้องทำด้วยความตั้งใจดังนั้นเราอาจต้องมองไปรอบ ๆ เพื่อรับหลักฐานเพิ่มเติมว่านี่คือปัญหา (ตอนนี้) และถ้าเป็นไปได้หาวิธีอื่นในการแก้ไข หรือด้วยความโชคดีใครบางคนที่รู้บางสิ่งบางอย่างลดลง ...

แก้ไข 2

ใช่การย้อนกลับเวอร์ชันไม่ใช่เรื่องง่ายเนื่องจากการอ้างอิง และการกลิ้งของคุณเองก็ยังห่างไกลจากความสุขเช่นกัน

เครื่องมือที่มีประโยชน์ที่เป็นไปได้สองประการ: คำสั่งmmcliและ ( http://m2msupport.net/m2msupport/module-tester/ )

ฉันคิดว่าปัญหาคือ ModemManager เลือก PDP บริบท 1 กับ apn = 'wap' ซึ่งควรเลือกบริบท PDP 9 กับ apn = 'WAP' บางทีนี่สามารถแก้ไขได้โดยใช้หนึ่งในเครื่องมือเหล่านั้น สามารถบังคับให้เลือกได้ 9 ระหว่างการเชื่อมต่อหรือลบบริบท 'เสีย' ที่ไม่ดีออกจากโมเด็มซึ่งเครื่องมือทดสอบโมดูลนั้นได้รับการโฆษณาว่ามีความสามารถ

เครื่องมือทดสอบโมเด็มดูเหมือนจะเป็นเครื่องมือจาวาในเบราว์เซอร์ดังนั้นคุณต้องตั้งค่าเบราว์เซอร์ของคุณเพื่อให้ทราบว่าจาวาของคุณอยู่ที่ใดและคุณต้องการทราบจาวานั้น โปรดสำรวจวิธีการนั้น ฉันไม่ได้ใช้ด้วยตัวเอง แต่เมื่อเห็นภาพหน้าจอฉันคาดเดาว่ามันจะนำเสนอบริบท PDP เป็นแท็บ 'Data Calls' ซึ่งคุณจะจดบันทึกทุกสิ่งที่มันแสดงแล้วแก้ไขรายการ 'wap' เพื่อ บิดเบือนป้ายกำกับ 'wap' apn ให้พูด 'wap1' และ 'wap2' (เพื่อ "ซ่อน" พวกเขาเมื่อมองหา 'WAP') จากนั้นบันทึกและปิดและเล่นปนเปดองอีกครั้ง หยิบบันทึก; ดูเหมือนว่า syslog ก็เพียงพอแล้วในกรณีที่มันยังไม่ยอมเล่น

mmcliคำสั่งยังดูเหมือนว่ามีประโยชน์ในเรื่องนี้; ทำman mmcliเพื่ออ่านเกี่ยวกับเรื่องนี้ แต่ฉันไม่เห็นอะไรเกี่ยวกับบริบทของ PDP

แก้ไข 3

โทรดี! เพื่อทดสอบจาก DVD นั่นบอกเราว่าฉันผิดทางกับ APN และมันก็ขึ้นอยู่กับการเรียก ppp ขึ้นมา อย่างน้อยนั่นก็เป็นต้นไม้ใหม่ของฉันที่เห่า

ประการแรกเรารับทราบว่ามีรุ่นที่แตกต่างกันสำหรับ pppd (จาก 2.4.5 ถึง 2.4.6) แต่นั่นอาจไม่ใช่ปัญหาเพราะทุกคนบนดองเกิลจะได้รับการท่องเที่ยวครั้งนี้

อืม ppp; ฉันต้องกระตุ้นความทรงจำในช่วงพันปีสุดท้ายของฉัน :-) น่าเสียดายที่ฉันยุ่งในวันนี้ แต่ฉันจะแตะต้องฐานเมื่อฉันมีเวลาอีกครั้งเพื่อดูว่าคุณมาไกลแค่ไหน ตรอกซอกซอยหลังแรกของฉันที่จะพิจารณาคือ: 1) ผู้ใช้ในกลุ่มใช่ไหม? 2) หนังสือรับรองนั้นถูกต้องหรือไม่ 3) mod ของไฟล์ ppp / chat นั้นถูกต้องไหม? บันทึกการดีบัก ppp ออกมาใน nm.txt (เหมือนเมื่อไม่กี่วันที่ผ่านมา) แต่ก็ควรมีวิธีที่จะขอให้บันทึกรายละเอียดเพิ่มเติม

แก้ไข 4

ตรวจสอบ/etc/ppp/pap-secretsและ/etc/ppp/chap-secretsมีกลุ่มdip(ใช้chgrpตามต้องการ) และโหมด740(หรือ-rw-r-----) (ใช้chmodตามต้องการ) ของฉันไม่ได้

แก้ไข 5

แล้วต้นไม้ต้นนี้: การเปรียบเทียบwvdialsyslog ที่ทำงานกับ syslog ที่ไม่ทำงานดูเหมือนว่าด้วยเหตุผลบางอย่างที่wvdialใช้ttyUSB3ในขณะที่ non-working ModemManagerยังคงใช้งานttyUSB1อยู่ ฉันไม่แน่ใจว่ามันเป็นสิ่งสำคัญ แต่เห็นได้ชัดว่า แต่ttyUSB1และttyUSB3ทั้งสองตอบสนองเป็นโมเด็มที่มีความสามารถ AT

ดังนั้นในการทดสอบบางทีคุณสามารถแก้ไข/etc/wvdial.confได้ภายใต้[Dialer Defaults]มีบรรทัด:

Modem = /dev/ttyUSB1

สำหรับการทดสอบหนึ่งและttyUSB3อีกการทดสอบหนึ่ง; ทั้งทำงานเป็นราก เพียงเพื่อดูว่ามีพฤติกรรมที่แตกต่าง โดยเฉพาะอย่างยิ่งหากการใช้งานttyUSB1เป็นปัญหาในขณะที่ใช้ ttyUSB3 ไม่เป็นเช่นนั้นก็เป็นการดีที่จะตรวจสอบวิธีการทำให้ ModemManager ใช้ ttyUSB3 เช่นกัน สำหรับผลการทดสอบอื่น ๆ ฉันจะบอกว่าเราจะกลับไปไล่ล่าพังพอนใน ppp land

แก้ไข 6

บันทึก dmesg สามารถถูกละเว้นฉันคิดว่า; มันเป็นอย่างนั้นในบันทึกทั้งหมด syslog ใหม่แสดงเฉพาะการทดสอบ ttyUSB3 แต่บางทีเราอาจคิดว่าชีวิตจะดีขึ้นถ้าNetworkManagerสามารถใช้ ttyUSB3 และละเว้น ttyUSB1 (สำหรับโมเด็มนี้)

ฉันยังพบ ( https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/819784 ) พร้อมโพสต์ # 10 โดยเฉพาะอย่างยิ่งทำให้เกิดความสับสน :-(

ดูเหมือนว่าudevกฎที่ใช้บังคับ/lib/udev/rules.d/77-mm-zte-port-types.rulesจะไม่มีผลใช้บังคับ แต่ควรจะเป็นที่ที่ควรไป และด้วยความหยั่งรู้ล่วงหน้าเกี่ยวกับudevเวทย์มนตร์pre-101 ฉันจะพิจารณาตั้งคำถามถึงบรรทัดที่ 4 ซึ่งกล่าวว่า:

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

ฉันคิดว่าบรรทัดนั้นต้องมีการเริ่มต้น#เพื่อแสดงความคิดเห็น ในรายละเอียดการอ่านไฟล์ของฉันคือมันต้องมีสถานะการเรียกของ SUBSYSTEM == "tty" และ SUBSYSTEMS = "usb" เพื่อใช้บิตที่ดีรวมถึงกฎผลิตภัณฑ์ "2003" และอย่างน้อยสำหรับการทดสอบ มันควรจะปลอดภัยที่จะข้ามการกรอง "tty" และตอนนี้ฉันไม่มีอะไรดีขึ้น

แก้ไข 7

หลังจากใช้เวลาคุณภาพกับเครื่องมือค้นหาที่ชื่นชอบฉันเชื่อว่าอีกเล็กน้อยว่าตัวเลือก ttyUSB เป็นปัญหาหลักที่นี่ กฎของ udev ที่ฉันชี้ไปนั้นใช้ได้และคุณควรย้อนกลับการแก้ไขนั้น

อย่างไรก็ตามฉันเริ่มเชื่อว่ากฎการกำหนดค่าที่ส่วนท้ายของไฟล์นั้นสำหรับรหัสผลิตภัณฑ์ "2003" กำลังทำให้เข้าใจผิด จากบันทึกมันดูสำหรับฉันว่ารหัสผลิตภัณฑ์ "2003" เป็นอุปกรณ์หน่วยความจำของดองเกิลจริง ๆ ในขณะที่ด้านโมเด็มมีรหัสผลิตภัณฑ์ "1232" คุณสามารถทดสอบสิ่งนี้ได้โดยทำซ้ำกฎ "2003" สองตัวสำหรับรหัสผลิตภัณฑ์ "1232" ในไฟล์/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"

หรือดีกว่าเพิ่มไฟล์ใหม่ข้างๆเช่นตั้งชื่อ78-ralph.rulesแต่คุณต้องเพิ่มการป้องกันระบบย่อยและระบบย่อยรอบ ๆ

จากนั้นดึงดองเกิลออกมาเรียกใช้udevadm control --reload(หรือรีบูต) และใส่ดองเกิล และยังมีอีกการsyslogจับกุมเว้นแต่ตอนนี้จะเกิดขึ้นกับการทำงาน

แม้ว่าปัญหาที่มีประสิทธิภาพคือ ModemManager จะทิ้งปลั๊กอินlibmm-plugin-zte.soเมื่อทำการตรวจสอบล่วงหน้าและลงเอยด้วยการใช้โมเด็มตัวจัดการทั่วไป ถ้าฉันพูดถูกเกี่ยวกับรหัสผลิตภัณฑ์นี่อาจเป็นเหตุผล การตรวจสอบล่วงหน้าจะค้นหาID_MM_ZTE_PORT_TYPE_MODEMแหล่งที่มาและนี่คือการขาดรหัสผลิตภัณฑ์ "1232" (ก่อนแพทช์) โดยมีผลกระทบที่ปลั๊กอิน zte ถูกทิ้ง

แก้ไข 8

syslogบันทึกเป็นระยะสั้นบิต ไม่มีจุดเริ่มต้นที่ ModemManager ไม่สามารถติดตั้งปลั๊กอิน zte อย่างไรก็ตามเห็นได้ชัดว่ามีการใช้ปลั๊กอินโมเด็มทั่วไป แต่อย่างใด ตอนนี้อาจเป็นไปได้ว่าusb_modeswitchกฎที่ฉันให้ไว้ก่อนหน้านี้เป็นสิ่งที่ผิดเช่นกัน มันตัดสินใจเปลี่ยนเป็น "2003" เมื่อฉันคิดว่าเปลี่ยนจาก "2003" แต่man usb_modeswitch(ซึ่งผมควรจะได้มองที่ก่อนหน้านี้) ชนิดของการแสดงให้เห็นว่ามันจะเลื่อนไปรหัสสินค้ามากกว่าจากมัน ไม่ว่าในกรณีใดบันทึกจะแสดงว่าเกิดขึ้น ดังนั้นโปรดเปลี่ยนกฎเพื่อใช้ "1232" แทนแล้วลองอีกครั้ง

ถ้าไม่มีอะไรอย่างน้อยฉันก็ต้องเรียนรู้เล็กน้อยเกี่ยวกับ udev

แก้ไข 9

ดี. ปัญหายังคงอยู่ (หรือยัง) ที่ ModemManager ปล่อยปลั๊กอิน ZTE เมื่อทำการตรวจสอบล่วงหน้า บันทึกการแก้ไขข้อบกพร่องของ ModemManager สำหรับ 15.10 (ชุดการบันทึก "debuglogs *") ทั้งหมดบอกเล่าเรื่องราวที่ปลั๊กอิน ZTE ถูกยกเลิกเนื่องจากการทดสอบผู้จำหน่าย id / product-id

ไปที่แหล่งกำเนิดลุค! ฉันใช้โอกาสนี้เพื่อดูซอร์สโค้ด ModemManager สั้น ๆ และมันแสดงให้เห็นว่าปลั๊กอินเป็นตารางของ vid / pid ที่ไม่รวม 19d2 / 2003 ... แม้ว่าฉันไม่พบแหล่งตารางนั้นดังนั้นฉันจึงไม่สามารถ ไม่ยืนยัน

หรืออาจมีปัญหาเรื่องเวลาที่นี่ เช่น ModemManager รันการตรวจสอบล่วงหน้าขณะที่อุปกรณ์คือ 19d2 / 1232 ความคิดนั้นสอดคล้องกับการสังเกตว่าการใช้กฎ 78-mm-zte-port-RALPH.rules udev ทำให้ ModemManager มีความสุขมากขึ้นกับอุปกรณ์ แต่ทำไมมันไม่มีความสุขและใช้ประโยชน์จากปลั๊กอินนั้นเมื่อเปลี่ยนอุปกรณ์เป็น 19d2 / 2003

อาจจำเป็นต้องใช้บันทึกเพิ่มเติม :-) ด้วย ModemManager ที่ถูกดีบั๊กและยังมีการดักจับคำสั่งudevadm monitor --e |& tee udevadm.log(ในเทอร์มินัลอื่น) เมื่อคุณเสียบอุปกรณ์ ฉันได้รับคำสั่งนั้นจาก ( https://wiki.ubuntu.com/DebuggingUdev )

ทำสิ่งนี้สองครั้ง: ครั้งหนึ่งโดยไม่ต้อง78-mm-zte-port-types-RALPH.rulesและครั้งเดียวกับกฎ ... ทั้งสองครั้งจากการรีบูตใหม่ กล่าวคือ

1. ติดตั้ง/lib/udev/rules.dโดยมีหรือไม่มี*-RALPH.rulesไฟล์
2. ดึงอุปกรณ์ออก
3. รีบูต
4. setup ModemManager สำหรับการดีบั๊กและตั้งค่า udevadm capture
5. เสียบอุปกรณ์และรอสักครู่
6. แพ็คไฟล์บันทึก
7. ทำซ้ำจาก 1 ด้วยการทดสอบครั้งต่อไป

การบันทึกนั้นควรบอกว่าปลั๊กอินของ ZTE หล่นไปที่ไหนและอย่างที่ฉันเข้าใจแล้วมันจะบอกเกี่ยวกับการจัดการเหตุการณ์ udev ด้วย

แก้ไข 10

(ฉันใกล้จะถึงจุดจบของฉันแล้ว แต่ฉันเหลืออีกหนึ่งหรือสองลมหายใจ :-)

ประการแรกการudevตกแต่งทั้งหมดดูเหมือนจะจบลงอย่างที่ควรจะมีเพียงเครื่องหมายคำถามสองสามข้อในคุณลักษณะสองประการ โดยเฉพาะอย่างยิ่งสิ่งที่78-*-RALPH.rulesควรโยนทิ้งไป; มันไม่มีประโยชน์

ฉันคิดว่าฉันสามารถอ่านอะไรบางอย่างได้จากสิ่งนี้ แต่ฉันไม่แน่ใจว่าควรแก้ไขอย่างไร โดยพื้นฐานแล้วฉันเห็นเมื่อดองเกิลเสียบเข้าที่นั่นจะมีเหตุการณ์วุ่นวายมากมาย มุ่งเน้นไปที่ผู้ที่เกี่ยวข้องกับ ttyUSB1 มีเหตุการณ์ "เร็ว":

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

ซึ่งทำให้usb_serialไดรเวอร์ถูกโหลดและ/dev/ttyUSB1ปรากฏขึ้น โดยเฉพาะอย่างยิ่งที่ทำให้เกิดเหตุการณ์อื่น:

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

ModemManagerผมคิดว่ายังทริกเกอร์ คุณต้องไปsyslogดูหลักฐานนี้เนื่องจากไม่มีความสัมพันธ์ที่เข้มงวดระหว่างบันทึก กรณีที่มีการประทับเวลา3867.435102และsyslogของขวัญของที่ใกล้ที่สุดต่อมาสายการบันทึกเพียงหลังจากบรรทัดบันทึกเคอร์เนลประทับModemManager3867.437412

ในแนวความคิดของฉันModemManagerยังไม่ควรถูกกระตุ้น แต่หลังจากเหตุการณ์ ttyUSB1 ที่ตามมา:

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

ซึ่งได้แนบแอตทริบิวต์ของ ZTE

ในบันทึก MM เราจะอยู่ที่การประทับบรรทัด1449934745.363291ซึ่งเห็นได้ชัดว่าเป็นการประทับเวลาแบบ "เรียลไทม์" แทนที่จะประทับ "เคอร์เนลเวลา"

ModemManager จากนั้นจะดำเนินการกับการตรวจสอบล่วงหน้าที่1449934745.450398 87ms ในภายหลังซึ่งในแง่เวลาเคอร์เนลจะใกล้3867.524519และ 55ms ก่อนหน้านั้น "ดี" UDEV รายงานเหตุการณ์ข้างต้น

ทราบว่าในsyslog, ModemManagerไม่ร้องเรียนลอดจ์ที่ttyUSB1ไม่ได้มีแอตทริบิวต์ที่กำหนดและอาจว่าการร้องเรียนที่เกี่ยวข้องกับ "การทำเครื่องหมาย" ที่เกิดขึ้นใน80-mm-candidate.rulesที่เกิดขึ้นใน จากความคิดเห็นในไฟล์นั้นการทำเครื่องหมายนั้นดูเหมือนจะเป็นความพยายามที่จะจัดการกับปัญหานี้อย่างแน่นอน แต่ถ้าเป็นเช่นนั้นมันจะไม่ทำงานในกรณีนี้

บางทีความเป็นไปได้ที่จะแก้ไขปัญหานี้อาจเป็นการเปลี่ยนกฎ "tty" 80-mm-candidate.rulesเป็น:

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

ในใจของฉันนั่นจะทำให้แน่ใจว่าการID_MM_CANDIDATEตั้งค่าจะล่าช้าจนกว่าจะมีการตั้งค่าแอตทริบิวต์ ZTE การ.ID_PORTตั้งค่าเป็นผลของ60-serial.rulesกฎ (เรียกว่า60-persistent-serial.rulesก่อนหน้านี้) และเงื่อนไขที่เพิ่มให้กับกฎการทำเครื่องหมายเป็นเพียงการมีค่า

เงื่อนไขนี้ไม่ใช่แอตทริบิวต์ของ ZTE แต่เพียงอย่างเดียวเพื่อให้กฎทั่วไปมากกว่า ขั้นตอนที่หนึ่งเฉพาะเจาะจงมากขึ้นจะค่อนข้างต้องใช้แทนเนื่องจากได้รับมอบหมายที่นี่เกิดขึ้นโดยENV{.MM_USBIFNUM}="?*"77-mm-zte-port-types.rules

โดยทั่วไปฉันไม่แน่ใจเกี่ยวกับudevการสั่งซื้อกฎและฉันก็ยังไม่แน่ใจว่านี่จะหยุดModemManagerการแสดงเร็วเกินไป อย่างไรก็ตามถ้ามันไม่เป็นเช่นนั้นก็80-mm-candidate.rulesจะมีฟังก์ชั่นน้อยถึงไม่มีเลยและบางทีมันก็จะลงมาที่ "การปรับปรุง" ถึงModemManagerจาก 15.04

แก้ไข 21

ถอนหายใจ อาจไม่เกี่ยวข้อง แต่คุณอาจต้องการตรวจสอบของคุณ7-zte-mutil_port_device.rulesไฟล์นั่นเป็นเศษที่เหลือจากการทดลองอื่นหรือไม่ อย่างไรก็ตามไม่เกี่ยวข้องที่นี่

ยังคงมีอยู่เกือบสองวินาทีระหว่าง515.558184และ516.381549สถานที่ที่ModemManagerกระตือรือร้นและไม่ถูกต้องคว้า/dev/ttyUSB1และในขณะที่บ่นเกี่ยวกับมันไม่ได้ตั้งค่ายังคงผ่านการตรวจสอบล่วงหน้าและทิ้งปลั๊กอิน ZTE กล่าวอีกนัยหนึ่งการแก้ไขกฎไม่ModemManagerรอ

ฉันคิดว่าคุณทดสอบโดยใช้ENV{.MM_USBIFNUM}="?*"แทนENV{.ID_PORT}=="?*"แทน

ที่จริงแล้วเพื่อยืนยันว่าการตั้งค่าENV{ID_MM_CANDIDATE}=1มีความสำคัญหรือไม่คุณควรย้ายไปชั่วคราว80-mm-candidate.rulesแล้วดู (ในsyslog) หากModemManagerไม่สนใจ/dev/ttyUSB1หรือไม่ ฉันสงสัยว่า "ไม่"

และจากนั้นบางทีคุณอาจใช้รุ่นที่ใช้งานได้เช่น 14.04 และถ้าคุณต้องการบางทีอาจรัน 15.10 ในกล่องเสมือนจริงเว้นแต่ว่าแน่นอนว่ามันมีอยู่ในกล่องเสมือนแล้ว

ฉันคิดว่าฉันต้องเรียกร้องความพ่ายแพ้ ณ จุดนี้

โมเด็มเริ่มทำงานใน Ubuntu 16.04 รุ่นนี้ยังอยู่ในช่วงการพัฒนา แต่ใช้งานได้ดีในแล็ปท็อปของฉัน

ฉันหวังว่าฉันจะสามารถให้รายละเอียดทางเทคนิคเพิ่มเติมเกี่ยวกับวิธีการที่มันเริ่มทำงาน

หลังจากมองดูแล้วดูเหมือนว่านี่ไม่ใช่ครั้งแรกที่มังกรตัวนี้จัดการกับมันได้อย่างเหมาะสม มันเป็นข้อผิดพลาดมาก่อนใน 12.10 และ 13.04 บางทีข้อผิดพลาดอาจไม่เคยแก้ไขหรือแพทช์ใหม่ทำอะไรบางอย่างที่ทำงานผิดปกติมาก่อน

หวังว่าหากฉันอ่านรายละเอียดทางเทคนิคของคุณอย่างถูกต้องฉันจะต้องนำคุณไปยังทิศทางนี้ (MF190J):

โมเด็ม 3G (ZTE MF190J) ยังคงต้องทำการปรับแต่งเอง

คุณได้ลองสิ่งนี้แล้ว:

 rfkill list up

จากนั้นสร้างสคริปต์นี้และเรียกใช้:

 #/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

และมันอาจทำงานได้ดีในลักษณะนี้