Mbbservice.exe — что это такое?
Процесс mbbService.exe принадлежит программе MobileBrServ, которая может автоматически установиться при первом подключении USB-модема для мобильного интернета. Скорее всего устанавливается вместе с драйверами.
Название софта для работы с модемом может быть например Mobile Broadband HL. Но это зависит от модели модема, от оператора, софт может быть вообще выполнен в стиле оформления оператора.
Возможно находится в автозагрузке. Чтобы проверить: зажмите Win R > введите команду msconfig > активируйте вкладку Автозагрузка, посмотрите наличие записи.. связанной с mbbService. Если что — отключите (снимите галочку). Будут проблемы — поставите обратно.
Cdc mbim модем настройка
Mobile Broadband SMS Toolkit
Описание: Программа «Mobile Broadband SMS Toolkit» предназначена для приёма и отправки SMS сообщений через модем широкополосного мобильного интернета (Mobile Broadband Modem). А также программа поддерживает работу с USSD запросами (Unstructured Supplementary Service Data).
Операционная система: Windows 7/8/10.
Текущая версия программы: 1.0.0.79 — RC1
Cdc_mbim.c source code [linux/drivers/net/usb/cdc_mbim.c] – woboq code browser
1 | /* |
---|---|
2 | * Copyright (c) 2022 Smith Micro Software, Inc. |
3 | * Copyright (c) 2022 Bjørn Mork <bjorn@mork.no> |
4 | * |
5 | * This driver is based on and reuse most of cdc_ncm, which is |
6 | * Copyright (C) ST-Ericsson 2022-2022 |
7 | * |
8 | * This program is free software; you can redistribute it and/or |
9 | * modify it under the terms of the GNU General Public License |
10 | * version 2 as published by the Free Software Foundation. |
11 | */ |
12 | |
13 | #include <linux/module.h> |
14 | #include <linux/netdevice.h> |
15 | #include <linux/ethtool.h> |
16 | #include <linux/if_vlan.h> |
17 | #include <linux/ip.h> |
18 | #include <linux/mii.h> |
19 | #include <linux/usb.h> |
20 | #include <linux/usb/cdc.h> |
21 | #include <linux/usb/usbnet.h> |
22 | #include <linux/usb/cdc-wdm.h> |
23 | #include <linux/usb/cdc_ncm.h> |
24 | #include <net/ipv6.h> |
25 | #include <net/addrconf.h> |
26 | |
27 | /* alternative VLAN for IP session 0 if not untagged */ |
28 | #define MBIM_IPS0_VID 4094 |
29 | |
30 | /* driver specific data – must match cdc_ncm usage */ |
31 | structcdc_mbim_state { |
32 | structcdc_ncm_ctx *ctx; |
33 | atomic_tpmcount; |
34 | structusb_driver *subdriver; |
35 | unsignedlong_unused; |
36 | unsignedlongflags; |
37 | }; |
38 | |
39 | /* flags for the cdc_mbim_state.flags field */ |
40 | enumcdc_mbim_flags { |
41 | FLAG_IPS0_VLAN = 1 << 0, /* IP session 0 is tagged */ |
42 | }; |
43 | |
44 | /* using a counter to merge subdriver requests with our own into a combined state */ |
45 | staticintcdc_mbim_manage_power(structusbnet *dev, inton) |
46 | { |
47 | structcdc_mbim_state *info = (void *)&dev->data; |
48 | intrv = 0; |
49 | |
50 | dev_dbg(&dev->intf->dev, “%s() pmcount=%d, on=%dn”, __func__, atomic_read(&info->pmcount), on); |
51 | |
52 | if ((on && atomic_add_return(1, &info->pmcount) == 1) || (!on && atomic_dec_and_test(&info->pmcount))) { |
53 | /* need autopm_get/put here to ensure the usbcore sees the new value */ |
54 | rv = usb_autopm_get_interface(dev->intf); |
55 | dev->intf->needs_remote_wakeup = on; |
56 | if (!rv) |
57 | usb_autopm_put_interface(dev->intf); |
58 | } |
59 | return0; |
60 | } |
61 | |
62 | staticintcdc_mbim_wdm_manage_power(structusb_interface *intf, intstatus) |
63 | { |
64 | structusbnet *dev = usb_get_intfdata(intf); |
65 | |
66 | /* can be called while disconnecting */ |
67 | if (!dev) |
68 | return0; |
69 | |
70 | returncdc_mbim_manage_power(dev, status); |
71 | } |
72 | |
73 | staticintcdc_mbim_rx_add_vid(structnet_device *netdev, __be16proto, u16vid) |
74 | { |
75 | structusbnet *dev = netdev_priv(netdev); |
76 | structcdc_mbim_state *info = (void *)&dev->data; |
77 | |
78 | /* creation of this VLAN is a request to tag IP session 0 */ |
79 | if (vid == MBIM_IPS0_VID) |
80 | info->flags |= FLAG_IPS0_VLAN; |
81 | else |
82 | if (vid >= 512) /* we don’t map these to MBIM session */ |
83 | return –EINVAL; |
84 | return0; |
85 | } |
86 | |
87 | staticintcdc_mbim_rx_kill_vid(structnet_device *netdev, __be16proto, u16vid) |
88 | { |
89 | structusbnet *dev = netdev_priv(netdev); |
90 | structcdc_mbim_state *info = (void *)&dev->data; |
91 | |
92 | /* this is a request for an untagged IP session 0 */ |
93 | if (vid == MBIM_IPS0_VID) |
94 | info->flags &= ~FLAG_IPS0_VLAN; |
95 | return0; |
96 | } |
97 | |
98 | staticconststructnet_device_opscdc_mbim_netdev_ops = { |
99 | .ndo_open = usbnet_open, |
100 | .ndo_stop = usbnet_stop, |
101 | .ndo_start_xmit = usbnet_start_xmit, |
102 | .ndo_tx_timeout = usbnet_tx_timeout, |
103 | .ndo_get_stats64 = usbnet_get_stats64, |
104 | .ndo_change_mtu = cdc_ncm_change_mtu, |
105 | .ndo_set_mac_address = eth_mac_addr, |
106 | .ndo_validate_addr = eth_validate_addr, |
107 | .ndo_vlan_rx_add_vid = cdc_mbim_rx_add_vid, |
108 | .ndo_vlan_rx_kill_vid = cdc_mbim_rx_kill_vid, |
109 | }; |
110 | |
111 | /* Change the control interface altsetting and update the .driver_info |
112 | * pointer if the matching entry after changing class codes points to |
113 | * a different struct |
114 | */ |
115 | staticintcdc_mbim_set_ctrlalt(structusbnet *dev, structusb_interface *intf, u8alt) |
116 | { |
117 | structusb_driver *driver = to_usb_driver(intf->dev.driver); |
118 | conststructusb_device_id *id; |
119 | structdriver_info *info; |
120 | intret; |
121 | |
122 | ret = usb_set_interface(dev->udev, |
123 | intf->cur_altsetting->desc.bInterfaceNumber, |
124 | alt); |
125 | if (ret) |
126 | returnret; |
127 | |
128 | id = usb_match_id(intf, driver->id_table); |
129 | if (!id) |
130 | return –ENODEV; |
131 | |
132 | info = (structdriver_info *)id->driver_info; |
133 | if (info != dev->driver_info) { |
134 | dev_dbg(&intf->dev, “driver_info updated to ‘%s’n”, |
135 | info->description); |
136 | dev->driver_info = info; |
137 | } |
138 | return0; |
139 | } |
140 | |
141 | staticintcdc_mbim_bind(structusbnet *dev, structusb_interface *intf) |
142 | { |
143 | structcdc_ncm_ctx *ctx; |
144 | structusb_driver *subdriver = ERR_PTR(-ENODEV); |
145 | intret = –ENODEV; |
146 | u8data_altsetting = 1; |
147 | structcdc_mbim_state *info = (void *)&dev->data; |
148 | |
149 | /* should we change control altsetting on a NCM/MBIM function? */ |
150 | if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) { |
151 | data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM; |
152 | ret = cdc_mbim_set_ctrlalt(dev, intf, CDC_NCM_COMM_ALTSETTING_MBIM); |
153 | if (ret) |
154 | gotoerr; |
155 | ret = –ENODEV; |
156 | } |
157 | |
158 | /* we will hit this for NCM/MBIM functions if prefer_mbim is false */ |
159 | if (!cdc_ncm_comm_intf_is_mbim(intf->cur_altsetting)) |
160 | gotoerr; |
161 | |
162 | ret = cdc_ncm_bind_common(dev, intf, data_altsetting, dev->driver_info->data); |
163 | if (ret) |
164 | gotoerr; |
165 | |
166 | ctx = info->ctx; |
167 | |
168 | /* The MBIM descriptor and the status endpoint are required */ |
169 | if (ctx->mbim_desc && dev->status) |
170 | subdriver = usb_cdc_wdm_register(ctx->control, |
171 | &dev->status->desc, |
172 | le16_to_cpu(ctx->mbim_desc->wMaxControlMessage), |
173 | cdc_mbim_wdm_manage_power); |
174 | if (IS_ERR(subdriver)) { |
175 | ret = PTR_ERR(subdriver); |
176 | cdc_ncm_unbind(dev, intf); |
177 | gotoerr; |
178 | } |
179 | |
180 | /* can’t let usbnet use the interrupt endpoint */ |
181 | dev->status = NULL; |
182 | info->subdriver = subdriver; |
183 | |
184 | /* MBIM cannot do ARP */ |
185 | dev->net->flags |= IFF_NOARP; |
186 | |
187 | /* no need to put the VLAN tci in the packet headers */ |
188 | dev->net->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_FILTER; |
189 | |
190 | /* monitor VLAN additions and removals */ |
191 | dev->net->netdev_ops = &cdc_mbim_netdev_ops; |
192 | err: |
193 | returnret; |
194 | } |
195 | |
196 | staticvoidcdc_mbim_unbind(structusbnet *dev, structusb_interface *intf) |
197 | { |
198 | structcdc_mbim_state *info = (void *)&dev->data; |
199 | structcdc_ncm_ctx *ctx = info->ctx; |
200 | |
201 | /* disconnect subdriver from control interface */ |
202 | if (info->subdriver && info->subdriver->disconnect) |
203 | info->subdriver->disconnect(ctx->control); |
204 | info->subdriver = NULL; |
205 | |
206 | /* let NCM unbind clean up both control and data interface */ |
207 | cdc_ncm_unbind(dev, intf); |
208 | } |
209 | |
210 | /* verify that the ethernet protocol is IPv4 or IPv6 */ |
211 | staticboolis_ip_proto(__be16proto) |
212 | { |
213 | switch (proto) { |
214 | casehtons(ETH_P_IP): |
215 | casehtons(ETH_P_IPV6): |
216 | returntrue; |
217 | } |
218 | returnfalse; |
219 | } |
220 | |
221 | staticstructsk_buff *cdc_mbim_tx_fixup(structusbnet *dev, structsk_buff *skb, gfp_tflags) |
222 | { |
223 | structsk_buff *skb_out; |
224 | structcdc_mbim_state *info = (void *)&dev->data; |
225 | structcdc_ncm_ctx *ctx = info->ctx; |
226 | __le32sign = cpu_to_le32(USB_CDC_MBIM_NDP16_IPS_SIGN); |
227 | u16tci = 0; |
228 | boolis_ip; |
229 | u8 *c; |
230 | |
231 | if (!ctx) |
232 | gotoerror; |
233 | |
234 | if (skb) { |
235 | if (skb->len <= ETH_HLEN) |
236 | gotoerror; |
237 | |
238 | /* Some applications using e.g. packet sockets will |
239 | * bypass the VLAN acceleration and create tagged |
240 | * ethernet frames directly. We primarily look for |
241 | * the accelerated out-of-band tag, but fall back if |
242 | * required |
243 | */ |
244 | skb_reset_mac_header(skb); |
245 | if (vlan_get_tag(skb, &tci) < 0 && skb->len > VLAN_ETH_HLEN && |
246 | __vlan_get_tag(skb, &tci) == 0) { |
247 | is_ip = is_ip_proto(vlan_eth_hdr(skb)->h_vlan_encapsulated_proto); |
248 | skb_pull(skb, VLAN_ETH_HLEN); |
249 | } else { |
250 | is_ip = is_ip_proto(eth_hdr(skb)->h_proto); |
251 | skb_pull(skb, ETH_HLEN); |
252 | } |
253 | |
254 | /* Is IP session <0> tagged too? */ |
255 | if (info->flags & FLAG_IPS0_VLAN) { |
256 | /* drop all untagged packets */ |
257 | if (!tci) |
258 | gotoerror; |
259 | /* map MBIM_IPS0_VID to IPS<0> */ |
260 | if (tci == MBIM_IPS0_VID) |
261 | tci = 0; |
262 | } |
263 | |
264 | /* mapping VLANs to MBIM sessions: |
265 | * no tag => IPS session <0> if !FLAG_IPS0_VLAN |
266 | * 1 – 255 => IPS session <vlanid> |
267 | * 256 – 511 => DSS session <vlanid – 256> |
268 | * 512 – 4093 => unsupported, drop |
269 | * 4094 => IPS session <0> if FLAG_IPS0_VLAN |
270 | */ |
271 | |
272 | switch (tci & 0x0f00) { |
273 | case0x0000: /* VLAN ID 0 – 255 */ |
274 | if (!is_ip) |
275 | gotoerror; |
276 | c = (u8 *)&sign; |
277 | c[3] = tci; |
278 | break; |
279 | case0x0100: /* VLAN ID 256 – 511 */ |
280 | if (is_ip) |
281 | gotoerror; |
282 | sign = cpu_to_le32(USB_CDC_MBIM_NDP16_DSS_SIGN); |
283 | c = (u8 *)&sign; |
284 | c[3] = tci; |
285 | break; |
286 | default: |
287 | netif_err(dev, tx_err, dev->net, |
288 | “unsupported tci=0xxn”, tci); |
289 | gotoerror; |
290 | } |
291 | } |
292 | |
293 | spin_lock_bh(&ctx->mtx); |
294 | skb_out = cdc_ncm_fill_tx_frame(dev, skb, sign); |
295 | spin_unlock_bh(&ctx->mtx); |
296 | returnskb_out; |
297 | |
298 | error: |
299 | if (skb) |
300 | dev_kfree_skb_any(skb); |
301 | |
302 | returnNULL; |
303 | } |
304 | |
305 | /* Some devices are known to send Neigbor Solicitation messages and |
306 | * require Neigbor Advertisement replies. The IPv6 core will not |
307 | * respond since IFF_NOARP is set, so we must handle them ourselves. |
308 | */ |
309 | staticvoiddo_neigh_solicit(structusbnet *dev, u8 *buf, u16tci) |
310 | { |
311 | structipv6hdr *iph = (void *)buf; |
312 | structnd_msg *msg = (void *)(iph 1); |
313 | structnet_device *netdev; |
314 | structinet6_dev *in6_dev; |
315 | boolis_router; |
316 | |
317 | /* we’ll only respond to requests from unicast addresses to |
318 | * our solicited node addresses. |
319 | */ |
320 | if (!ipv6_addr_is_solict_mult(&iph->daddr) || |
321 | !(ipv6_addr_type(&iph->saddr) & IPV6_ADDR_UNICAST)) |
322 | return; |
323 | |
324 | /* need to send the NA on the VLAN dev, if any */ |
325 | rcu_read_lock(); |
326 | if (tci) { |
327 | netdev = __vlan_find_dev_deep_rcu(dev->net, htons(ETH_P_8021Q), |
328 | tci); |
329 | if (!netdev) { |
330 | rcu_read_unlock(); |
331 | return; |
332 | } |
333 | } else { |
334 | netdev = dev->net; |
335 | } |
336 | dev_hold(netdev); |
337 | rcu_read_unlock(); |
338 | |
339 | in6_dev = in6_dev_get(netdev); |
340 | if (!in6_dev) |
341 | gotoout; |
342 | is_router = !!in6_dev->cnf.forwarding; |
343 | in6_dev_put(in6_dev); |
344 | |
345 | /* ipv6_stub != NULL if in6_dev_get returned an inet6_dev */ |
346 | ipv6_stub->ndisc_send_na(netdev, &iph->saddr, &msg->target, |
347 | is_router/* router */, |
348 | true/* solicited */, |
349 | false/* override */, |
350 | true/* inc_opt */); |
351 | out: |
352 | dev_put(netdev); |
353 | } |
354 | |
355 | staticboolis_neigh_solicit(u8 *buf, size_tlen) |
356 | { |
357 | structipv6hdr *iph = (void *)buf; |
358 | structnd_msg *msg = (void *)(iph 1); |
359 | |
360 | return (len >= sizeof(structipv6hdr) sizeof(structnd_msg) && |
361 | iph->nexthdr == IPPROTO_ICMPV6 && |
362 | msg->icmph.icmp6_code == 0 && |
363 | msg->icmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION); |
364 | } |
365 | |
366 | |
367 | staticstructsk_buff *cdc_mbim_process_dgram(structusbnet *dev, u8 *buf, size_tlen, u16tci) |
368 | { |
369 | __be16proto = htons(ETH_P_802_3); |
370 | structsk_buff *skb = NULL; |
371 | |
372 | if (tci < 256 || tci == MBIM_IPS0_VID) { /* IPS session? */ |
373 | if (len < sizeof(structiphdr)) |
374 | gotoerr; |
375 | |
376 | switch (*buf & 0xf0) { |
377 | case0x40: |
378 | proto = htons(ETH_P_IP); |
379 | break; |
380 | case0x60: |
381 | if (is_neigh_solicit(buf, len)) |
382 | do_neigh_solicit(dev, buf, tci); |
383 | proto = htons(ETH_P_IPV6); |
384 | break; |
385 | default: |
386 | gotoerr; |
387 | } |
388 | } |
389 | |
390 | skb = netdev_alloc_skb_ip_align(dev->net, len ETH_HLEN); |
391 | if (!skb) |
392 | gotoerr; |
393 | |
394 | /* add an ethernet header */ |
395 | skb_put(skb, ETH_HLEN); |
396 | skb_reset_mac_header(skb); |
397 | eth_hdr(skb)->h_proto = proto; |
398 | eth_zero_addr(eth_hdr(skb)->h_source); |
399 | memcpy(eth_hdr(skb)->h_dest, dev->net->dev_addr, ETH_ALEN); |
400 | |
401 | /* add datagram */ |
402 | skb_put_data(skb, buf, len); |
403 | |
404 | /* map MBIM session to VLAN */ |
405 | if (tci) |
406 | __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), tci); |
407 | err: |
408 | returnskb; |
409 | } |
410 | |
411 | staticintcdc_mbim_rx_fixup(structusbnet *dev, structsk_buff *skb_in) |
412 | { |
413 | structsk_buff *skb; |
414 | structcdc_mbim_state *info = (void *)&dev->data; |
415 | structcdc_ncm_ctx *ctx = info->ctx; |
416 | intlen; |
417 | intnframes; |
418 | intx; |
419 | intoffset; |
420 | structusb_cdc_ncm_ndp16 *ndp16; |
421 | structusb_cdc_ncm_dpe16 *dpe16; |
422 | intndpoffset; |
423 | intloopcount = 50; /* arbitrary max preventing infinite loop */ |
424 | u32payload = 0; |
425 | u8 *c; |
426 | u16tci; |
427 | |
428 | ndpoffset = cdc_ncm_rx_verify_nth16(ctx, skb_in); |
429 | if (ndpoffset < 0) |
430 | gotoerror; |
431 | |
432 | next_ndp: |
433 | nframes = cdc_ncm_rx_verify_ndp16(skb_in, ndpoffset); |
434 | if (nframes < 0) |
435 | gotoerror; |
436 | |
437 | ndp16 = (structusb_cdc_ncm_ndp16 *)(skb_in->data ndpoffset); |
438 | |
439 | switch (ndp16->dwSignature & cpu_to_le32(0x00ffffff)) { |
440 | casecpu_to_le32(USB_CDC_MBIM_NDP16_IPS_SIGN): |
441 | c = (u8 *)&ndp16->dwSignature; |
442 | tci = c[3]; |
443 | /* tag IPS<0> packets too if MBIM_IPS0_VID exists */ |
444 | if (!tci && info->flags & FLAG_IPS0_VLAN) |
445 | tci = MBIM_IPS0_VID; |
446 | break; |
447 | casecpu_to_le32(USB_CDC_MBIM_NDP16_DSS_SIGN): |
448 | c = (u8 *)&ndp16->dwSignature; |
449 | tci = c[3] 256; |
450 | break; |
451 | default: |
452 | netif_dbg(dev, rx_err, dev->net, |
453 | “unsupported NDP signature <0xx>n”, |
454 | le32_to_cpu(ndp16->dwSignature)); |
455 | gotoerr_ndp; |
456 | |
457 | } |
458 | |
459 | dpe16 = ndp16->dpe16; |
460 | for (x = 0; x < nframes; x , dpe16 ) { |
461 | offset = le16_to_cpu(dpe16->wDatagramIndex); |
462 | len = le16_to_cpu(dpe16->wDatagramLength); |
463 | |
464 | /* |
465 | * CDC NCM ch. 3.7 |
466 | * All entries after first NULL entry are to be ignored |
467 | */ |
468 | if ((offset == 0) || (len == 0)) { |
469 | if (!x) |
470 | gotoerr_ndp; /* empty NTB */ |
471 | break; |
472 | } |
473 | |
474 | /* sanity checking */ |
475 | if (((offset len) > skb_in->len) || (len > ctx->rx_max)) { |
476 | netif_dbg(dev, rx_err, dev->net, |
477 | “invalid frame detected (ignored) offset[%u]=%u, length=%u, skb=%pn”, |
478 | x, offset, len, skb_in); |
479 | if (!x) |
480 | gotoerr_ndp; |
481 | break; |
482 | } else { |
483 | skb = cdc_mbim_process_dgram(dev, skb_in->data offset, len, tci); |
484 | if (!skb) |
485 | gotoerror; |
486 | usbnet_skb_return(dev, skb); |
487 | payload = len; /* count payload bytes in this NTB */ |
488 | } |
489 | } |
490 | err_ndp: |
491 | /* are there more NDPs to process? */ |
492 | ndpoffset = le16_to_cpu(ndp16->wNextNdpIndex); |
493 | if (ndpoffset && loopcount–) |
494 | gotonext_ndp; |
495 | |
496 | /* update stats */ |
497 | ctx->rx_overhead = skb_in->len – payload; |
498 | ctx->rx_ntbs ; |
499 | |
500 | return1; |
501 | error: |
502 | return0; |
503 | } |
504 | |
505 | staticintcdc_mbim_suspend(structusb_interface *intf, pm_message_tmessage) |
506 | { |
507 | intret = –ENODEV; |
508 | structusbnet *dev = usb_get_intfdata(intf); |
509 | structcdc_mbim_state *info = (void *)&dev->data; |
510 | structcdc_ncm_ctx *ctx = info->ctx; |
511 | |
512 | if (!ctx) |
513 | gotoerror; |
514 | |
515 | /* |
516 | * Both usbnet_suspend() and subdriver->suspend() MUST return 0 |
517 | * in system sleep context, otherwise, the resume callback has |
518 | * to recover device from previous suspend failure. |
519 | */ |
520 | ret = usbnet_suspend(intf, message); |
521 | if (ret < 0) |
522 | gotoerror; |
523 | |
524 | if (intf == ctx->control && info->subdriver && info->subdriver->suspend) |
525 | ret = info->subdriver->suspend(intf, message); |
526 | if (ret < 0) |
527 | usbnet_resume(intf); |
528 | |
529 | error: |
530 | returnret; |
531 | } |
532 | |
533 | staticintcdc_mbim_resume(structusb_interface *intf) |
534 | { |
535 | intret = 0; |
536 | structusbnet *dev = usb_get_intfdata(intf); |
537 | structcdc_mbim_state *info = (void *)&dev->data; |
538 | structcdc_ncm_ctx *ctx = info->ctx; |
539 | boolcallsub = (intf == ctx->control && info->subdriver && info->subdriver->resume); |
540 | |
541 | if (callsub) |
542 | ret = info->subdriver->resume(intf); |
543 | if (ret < 0) |
544 | gotoerr; |
545 | ret = usbnet_resume(intf); |
546 | if (ret < 0 && callsub) |
547 | info->subdriver->suspend(intf, PMSG_SUSPEND); |
548 | err: |
549 | returnret; |
550 | } |
551 | |
552 | staticconststructdriver_infocdc_mbim_info = { |
553 | .description = “CDC MBIM”, |
554 | .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN, |
555 | .bind = cdc_mbim_bind, |
556 | .unbind = cdc_mbim_unbind, |
557 | .manage_power = cdc_mbim_manage_power, |
558 | .rx_fixup = cdc_mbim_rx_fixup, |
559 | .tx_fixup = cdc_mbim_tx_fixup, |
560 | }; |
561 | |
562 | /* MBIM and NCM devices should not need a ZLP after NTBs with |
563 | * dwNtbOutMaxSize length. Nevertheless, a number of devices from |
564 | * different vendor IDs will fail unless we send ZLPs, forcing us |
565 | * to make this the default. |
566 | * |
567 | * This default may cause a performance penalty for spec conforming |
568 | * devices wanting to take advantage of optimizations possible without |
569 | * ZLPs. A whitelist is added in an attempt to avoid this for devices |
570 | * known to conform to the MBIM specification. |
571 | * |
572 | * All known devices supporting NCM compatibility mode are also |
573 | * conforming to the NCM and MBIM specifications. For this reason, the |
574 | * NCM subclass entry is also in the ZLP whitelist. |
575 | */ |
576 | staticconststructdriver_infocdc_mbim_info_zlp = { |
577 | .description = “CDC MBIM”, |
578 | .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN | FLAG_SEND_ZLP, |
579 | .bind = cdc_mbim_bind, |
580 | .unbind = cdc_mbim_unbind, |
581 | .manage_power = cdc_mbim_manage_power, |
582 | .rx_fixup = cdc_mbim_rx_fixup, |
583 | .tx_fixup = cdc_mbim_tx_fixup, |
584 | }; |
585 | |
586 | /* The spefication explicitly allows NDPs to be placed anywhere in the |
587 | * frame, but some devices fail unless the NDP is placed after the IP |
588 | * packets. Using the CDC_NCM_FLAG_NDP_TO_END flags to force this |
589 | * behaviour. |
590 | * |
591 | * Note: The current implementation of this feature restricts each NTB |
592 | * to a single NDP, implying that multiplexed sessions cannot share an |
593 | * NTB. This might affect performace for multiplexed sessions. |
594 | */ |
595 | staticconststructdriver_infocdc_mbim_info_ndp_to_end = { |
596 | .description = “CDC MBIM”, |
597 | .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN, |
598 | .bind = cdc_mbim_bind, |
599 | .unbind = cdc_mbim_unbind, |
600 | .manage_power = cdc_mbim_manage_power, |
601 | .rx_fixup = cdc_mbim_rx_fixup, |
602 | .tx_fixup = cdc_mbim_tx_fixup, |
603 | .data = CDC_NCM_FLAG_NDP_TO_END, |
604 | }; |
605 | |
606 | /* Some modems (e.g. Telit LE922A6) do not work properly with altsetting |
607 | * toggle done in cdc_ncm_bind_common. CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE |
608 | * flag is used to avoid this procedure. |
609 | */ |
610 | staticconststructdriver_infocdc_mbim_info_avoid_altsetting_toggle = { |
611 | .description = “CDC MBIM”, |
612 | .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN | FLAG_SEND_ZLP, |
613 | .bind = cdc_mbim_bind, |
614 | .unbind = cdc_mbim_unbind, |
615 | .manage_power = cdc_mbim_manage_power, |
616 | .rx_fixup = cdc_mbim_rx_fixup, |
617 | .tx_fixup = cdc_mbim_tx_fixup, |
618 | .data = CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE, |
619 | }; |
620 | |
621 | staticconststructusb_device_idmbim_devs[] = { |
622 | /* This duplicate NCM entry is intentional. MBIM devices can |
623 | * be disguised as NCM by default, and this is necessary to |
624 | * allow us to bind the correct driver_info to such devices. |
625 | * |
626 | * bind() will sort out this for us, selecting the correct |
627 | * entry and reject the other |
628 | */ |
629 | { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE), |
630 | .driver_info = (unsignedlong)&cdc_mbim_info, |
631 | }, |
632 | /* ZLP conformance whitelist: All Ericsson MBIM devices */ |
633 | { USB_VENDOR_AND_INTERFACE_INFO(0x0bdb, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE), |
634 | .driver_info = (unsignedlong)&cdc_mbim_info, |
635 | }, |
636 | |
637 | /* Some Huawei devices, ME906s-158 (12d1:15c1) and E3372 |
638 | * (12d1:157d), are known to fail unless the NDP is placed |
639 | * after the IP packets. Applying the quirk to all Huawei |
640 | * devices is broader than necessary, but harmless. |
641 | */ |
642 | { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE), |
643 | .driver_info = (unsignedlong)&cdc_mbim_info_ndp_to_end, |
644 | }, |
645 | |
646 | /* The HP lt4132 (03f0:a31d) is a rebranded Huawei ME906s-158, |
647 | * therefore it too requires the above “NDP to end” quirk. |
648 | */ |
649 | { USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0xa31d, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE), |
650 | .driver_info = (unsignedlong)&cdc_mbim_info_ndp_to_end, |
651 | }, |
652 | |
653 | /* Telit LE922A6 in MBIM composition */ |
654 | { USB_DEVICE_AND_INTERFACE_INFO(0x1bc7, 0x1041, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE), |
655 | .driver_info = (unsignedlong)&cdc_mbim_info_avoid_altsetting_toggle, |
656 | }, |
657 | |
658 | /* default entry */ |
659 | { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE), |
660 | .driver_info = (unsignedlong)&cdc_mbim_info_zlp, |
661 | }, |
662 | { |
663 | }, |
664 | }; |
665 | MODULE_DEVICE_TABLE(usb, mbim_devs); |
666 | |
667 | staticstructusb_drivercdc_mbim_driver = { |
668 | .name = “cdc_mbim”, |
669 | .id_table = mbim_devs, |
670 | .probe = usbnet_probe, |
671 | .disconnect = usbnet_disconnect, |
672 | .suspend = cdc_mbim_suspend, |
673 | .resume = cdc_mbim_resume, |
674 | .reset_resume = cdc_mbim_resume, |
675 | .supports_autosuspend = 1, |
676 | .disable_hub_initiated_lpm = 1, |
677 | }; |
678 | module_usb_driver(cdc_mbim_driver); |
679 | |
680 | MODULE_AUTHOR(“Greg Suarez <gsuarez@smithmicro.com>”); |
681 | MODULE_AUTHOR(“Bjørn Mork <bjorn@mork.no>”); |
682 | MODULE_DESCRIPTION(“USB CDC MBIM host driver”); |
683 | MODULE_LICENSE(“GPL”); |
684 |
Help! contribute! sponsor!
If you want to help, or sponsor further development in libmbim, mbimcli or the ModemManager integration, just let me know!
[UPDATE: Included freedesktop.org project link]
How does this compare to qmi?
There are quite some differences between this protocol and QMI. To name a few:
- Less basic types in MBIM, specially regarding signed/unsigned integers. QMI defines many more integer types, of different sizes and with different sign.
- Basic strings are given in ASCII in QMI
- Struct types are re-used in MBIM, as opposed to QMI, where each TLV would define the struct contents as it needed.
- There is no ‘client allocation’ needed in MBIM, i.e. the process opening the MBIM port doesn’t need to allocate clients for the different services.
- Fragmentation is built-in in the MBIM protocol; QMI required special TLVs and logic to handle messages that may be longer than the standard message size (e.g. when transferring the PRL list).
- Binary representation of the message is completely different. In QMI you would have a list of TLVs, one after the other. In MBIM, the contents of the message are split into two different sections: one which contains the fixed-size values and one for the variable-size values. For example, a string in MBIM is defined by two values in the fixed-size region (offset and size), while the real string data is within the variable-size section.
How to use lte modem in qmi mode for wan connection
More recent Modem default CDC_MBIM OR QMI MODE, This is example for the E20 R2.1, EM05, EM06, EM12, EM20, RM500Q and RM510Q modules
YOU CAN USE AT QCFG=“usbnet” to CHECK USB Driver
If you want to change the USB MODE, you can set the usbnet value
AT QCFG=“usbnet”,0 GobiNet or QMI_WWAN
AT QCFG=“usbnet”,2 CDC_MBIM
Than reset the power
Install the package luci-proto-qmi using Luci (System → Software) and configure the modem using LuCi (Network → Interfaces).
You can configure UCI manually using uci command line or text editor.
UCI is supporting qmi network protocol configuration.
The package uqmi must be installed to use QMI protocol.
Name | Type | Required | Default | Description |
---|---|---|---|---|
device | file path | yes | (none) | QMI device node, typically /dev/cdc-wdm0 |
apn | string | yes | (none) | Used APN |
auth | string | no | (none) | Authentication type: pap, chap, both, none |
username | string | no | (none) | Username for PAP/CHAP authentication |
password | string | no | (none) | Password for PAP/CHAP authentication |
pincode | number | no | (none) | PIN code to unlock SIM card |
delay | number | no | 0 | Seconds to wait before trying to interact with the modem (some ZTE modems require up to 30 s.) |
modes | string | no | (modem default) | Allowed network modes, comma separated list of: all, lte, umts, gsm, cdma, td-scdma |
pdptype | string | no | IP | Used IP-stack mode, IP (for IPv4), IPV6 (for IPv6) or IPV4V6 (for dual-stack) |
profile | number | no | (none) | Connection profile to use |
dhcp | boolean | no | 1 | Whether to use dhcp (default) or uqmi (0) to get IPv4 interface configuration |
dhcpv6 | boolean | no | 0 | Whether to use dhcp (1) or uqmi (default) to get IPv6 interface configuration |
autoconnect | boolean | no | 1 | |
plmn | number | no | (none) | First three digits are the mcc (mobile country code) and the last three digits are the mnc (mobile network code), for example if plmn=338020, then the mcc is 338 and the mnc is 020 |
timeout | number | no | 10 | Timeout (in seconds) to wait for SIM operations |
Here is a brief help about uqmi command line usage.
No device given Usage: uqmi <options|actions> Options: --single, -s: Print output as a single line (for scripts) --device=NAME, -d NAME: Set device name to NAME (required) --keep-client-id <name>: Keep Client ID for service <name> --release-client-id <name>: Release Client ID after exiting --mbim, -m NAME is an MBIM device with EXT_QMUX support --timeout, -t response timeout in msecs Services: dms, nas, pds, wds, wms Actions: --get-versions: Get service versions --set-client-id <name>,<id>: Set Client ID for service <name> to <id> (implies --keep-client-id) --get-client-id <name>: Connect and get Client ID for service <name> (implies --keep-client-id) --sync: Release all Client IDs --start-network: Start network connection (use with options below) --apn <apn>: Use APN --auth-type pap|chap|both|none: Use network authentication type --username <name>: Use network username --password <password>: Use network password --ip-family <family>: Use ip-family for the connection (ipv4, ipv6, unspecified) --autoconnect: Enable automatic connect/reconnect --profile <index>: Use connection profile --stop-network <pdh>: Stop network connection (use with option below) --autoconnect: Disable automatic connect/reconnect --get-data-status: Get current data access status --set-ip-family <val>: Set ip-family (ipv4, ipv6, unspecified) --set-autoconnect <val>: Set automatic connect/reconnect (disabled, enabled, paused) --get-current-settings: Get current connection settings --get-capabilities: List device capabilities --get-pin-status: Get PIN verification status --verify-pin1 <pin>: Verify PIN1 --verify-pin2 <pin>: Verify PIN2 --set-pin1-protection <state>: Set PIN1 protection state (disabled, enabled) --pin <pin>: PIN1 needed to change state --set-pin2-protection <state>: Set PIN2 protection state (disabled, enabled) --pin <pin2>: PIN2 needed to change state --change-pin1: Change PIN1 --pin <old pin>: Current PIN1 --new-pin <new pin>: New pin --change-pin2: Change PIN2 --pin <old pin>: Current PIN2 --new-pin <new pin>: New pin --unblock-pin1: Unblock PIN1 --puk <puk>: PUK needed to unblock --new-pin <new pin>: New pin --unblock-pin2: Unblock PIN2 --puk <puk>: PUK needed to unblock --new-pin <new pin>: New pin --get-iccid: Get the ICCID --get-imsi: Get International Mobile Subscriber ID --get-imei: Get International Mobile Equipment ID --get-msisdn: Get the MSISDN (telephone number) --reset-dms: Reset the DMS service --set-device-operating-mode <m> Set the device operating mode (modes: online, low_power, factory_test, offline reset, shutting_down, persistent_low_power, mode_only_low_power) --fcc-auth: Set FCC authentication --uim-verify-pin1 <pin>: Verify PIN1 (new devices) --uim-verify-pin2 <pin>: Verify PIN2 (new devices) --set-network-modes <modes>: Set usable network modes (Syntax: <mode1>[,<mode2>,...]) Available modes: all, lte, umts, gsm, cdma, td-scdma --set-network-preference <mode>: Set preferred network mode to <mode> Available modes: auto, gsm, wcdma --set-network-roaming <mode>: Set roaming preference: Available modes: any, off, only --network-scan: Initiate network scan --network-register: Initiate network register --set-plmn: Register at specified network --mcc <mcc>: Mobile Country Code (0 - auto) --mnc <mnc>: Mobile Network Code --get-plmn: Get preferred network selection info --get-signal-info: Get signal strength info --get-serving-system: Get serving system info --list-messages: List SMS messages --delete-message <id>: Delete SMS message at index <id> --get-message <id>: Get SMS message at index <id> --get-raw-message <id>: Get SMS raw message contents at index <id> --send-message <data>: Send SMS message (use options below) --send-message-smsc <nr>: SMSC number --send-message-target <nr>: Destination number (required) --send-message-flash: Send as Flash SMS --wda-set-data-format <type>: Set data format (type: 802.3|raw-ip) --wda-get-data-format: Get data format
Based on: This Article
Libmbim
The ‘libmbim‘ library is an attempt to write a protocol support library, as previously done with ‘libqmi‘.
The current codebase, GLib/GObject/GIO based, is pretty similar to what libqmi provided, with a ‘MbimDevice‘ GObject to handle the communication through the /dev/cdc-wdm port, as well as ‘MbimMessage‘ types to handle the creation of commands.
Given that there is no need for client allocations in MBIM, there is no ‘MbimClient‘ object needed. Also, given that the contents of each message are pre-defined, it wasn’t considered the need of input and output ‘bundles’ to handle collections of TLVs, as done in libqmi.
List of driver files that match with the above device in our database.
*: 2K=Windows 2000, 2K3= Windows 2003 , XP= Windows XP , VISTA = Windows Vista , WIN7 = Windows 7,WIN10/11= Windows 10/11
DriverCoding USB MBIM Compliance Network Adapter
1.1.1.9
2022-10-11
3.78 MB
2K, XP, 2K3, VISTA, WIN7, WIN8, WIN10/32bits
XP, VISTA, WIN7, WIN8, WIN10, WIN11/64bits
DriverCoding USB MBIM Compliance Network Adapter
1.1.1.9
2022-10-11
3.54 MB
2K, XP, 2K3, VISTA, WIN7, WIN8, WIN10/32bits
XP, VISTA, WIN7, WIN8, WIN10, WIN11/64bits
DriverCoding USB MBIM Compliance Network Adapter
1.1.1.9
2022-10-11
3.56 MB
2K, XP, 2K3, VISTA, WIN7, WIN8, WIN10/32bits
XP, VISTA, WIN7, WIN8, WIN10, WIN11/64bits
DriverCoding USB MBIM Compliance Network Adapter
1.1.1.9
2022-10-11
3.54 MB
2K, XP, 2K3, VISTA, WIN7, WIN8, WIN10/32bits
XP, VISTA, WIN7, WIN8, WIN10, WIN11/64bits
DriverCoding USB MBIM Compliance Network Adapter
1.1.1.9
2022-10-11
3.68 MB
2K, XP, 2K3, VISTA, WIN7, WIN8, WIN10/32bits
XP, VISTA, WIN7, WIN8, WIN10, WIN11/64bits
DriverCoding USB MBIM Compliance Network Adapter
1.1.1.9
2022-10-11
3.54 MB
2K, XP, 2K3, VISTA, WIN7, WIN8, WIN10/32bits
XP, VISTA, WIN7, WIN8, WIN10, WIN11/64bits
Mbim basic types
The protocol not only defines which action is supported in each command; it also defines the contents of the request, response and indication messages. The contents of each message are composed of collections of basic types defined by the protocol:
- Unsigned 32bit integers: Even for the most simple values (e.g. booleans), little-endian 32 bit unsigned integers are used.
- Strings: UTF-16LE encoded strings are always used.
- UUIDs: The protocol defines a special 16-byte-long UUID type, e.g. to define Service IDs
- Arrays: Collection of N values of a given basic type.
- Structs: Sequence of other basic types, given in a specific order.
As you can see, there is not much effort (none, actually) into making the protocol efficient in terms of overhead introduced; more than half of the bytes in each message will very likely end up being NUL bytes. Also, it is assured that each field within a message is aligned in a 32bit boundary, which makes it easier to read independent fields directly from the binary stream.
Mbim commands
For each service, MBIM defines a set of Commands (CIDs); and each command can then be divided into 3 actions:
Not every action is supported by every command. For example, the “Device Caps” command in the “Basic Connect” service only supports the “Query” action, while the “Radio State” command of the same service supports all “Set“, “Query” and “Notification“.
But how does this match with the message types defined before?
- Host-created “Set” and “Query” requests are sent using “Command Messages“.
- Modem-created “Set” and “Query” responses are sent using “Command Done Messages“.
- Modem-created “Notifications” are sent using “Indication Messages“.
Mbim message types
The protocol defines different message types with different formats.
Some of them are used to establish the channel of communication with the modem:
- Open Message (Host->Modem): Initialization request.
- Open Done Message (Host<-Modem): Initialization response.
- Close Message (Host->Modem): Close request.
- Close Done Message (Host<-Modem): Close response.
Some of the messages are used to report errors in the protocol; which may be sent either from the host or from the modem:
- Host Error Message (Host->Modem): Host-reported error.
- Modem Error Message (Host<-Modem): Modem-reported error.
And finally, some messages provide access to the different CIDs (Command IDs) defined in each Service.
Mbim services
The protocol defines a basic set of different Services:
- Basic Connect: Which provides the support for basic IP connectivity
- SMS: SMS messaging
- USSD: Unstructured Supplementary Service Data
- Phonebook: Handling contacts and such
- STK: SIM toolkit
- Authentication
- Device Service Stream
Only the Basic Connect one is mandatory in every MBIM device; others are optional. Vendors or even Network Operators can also extend the functionality of the device with other services; for example to support other protocols embedded within MBIM (e.g. QMI or AT within MBIM); or just to provide specific new features.
Mbimcli
The project comes with a command line utility (mbimcli), which allows (will allow) running “Get” or “Set” commands directly from the shell. There aren’t many supported commands yet, so I cannot show many more examples than this one:
$ sudo mbimcli -d /dev/cdc-wdm1 –basic-connect-query-subscriber-ready-status
[/dev/cdc-wdm1] Subscriber ready status retrieved:Ready state: ‘device-locked’Subscriber ID: ‘unknown’SIM ICCID: ‘984310311520086950F1’Ready info: ‘unknown’Telephone numbers: ”
Hint: Using –verbose will show you the raw binary message contents!
What is mbim?
The Mobile Interface Broadband Model (MBIM) is a new standard developed by the USB Implementers Forum, specifically designed for high speed mobile broadband modem devices.
This new USB networking subclass defines two separate new features:
- A new MBIM USB device model, providing multiple IP connections over a single USB interface, and without the need of 802.3 frames (as was the case with ECM and NCM)
- A new MBIM control protocol to talk to modem devices
Where do i get it?
The ‘libmbim’ library and the ‘mbimcli’ utility are managed in FreeDesktop.org:
Инструкция по разблокированию usb-модема от мтс для выхода в интернет через сим-карты любых других операторов
Сразу оговоримся, что инструкция актуальна не только для модемов от МТС, но и для модемов с прошивками под любых других операторов, а так же для модемов других производителей. Для примера мы взяли одну из самых распространенных моделей 3G USB модемов с прошивкой МТС — HUAWEI Mobile Broadband E1550.
Прежде всего необходимо открыть отсек модема, где находятся слоты под сим-карту и карту памяти microSD и удалить из него «симку» МТС.
Под сим-картой «прячется» IMEI-номер модема, а так же его серийный номер. Нас интересует IMEI. Его необходимо переписать на листок бумаги. Также не помешает записать производителя и модель устройства.
Нагрузка на пк
Процесс mbbService по непонятным причинам может грузить ПК — иногда через другой процесс, а именно — services.exe. Один пользователь удалил программу Mobile Broadband HL Service, после чего нагрузка прекратилась. Примечание: возможно это не программа.. а служба, проверьте в списке служб, если есть — попробуйте остановить ее. Вообще чтобы открыть службы, то нужно:
- Зажать кнопки Win R, написать команду services.msc, нажать ОК.
- Откроется окно со списком служб — будут отображаться как виндовские, так и сторонние.
- Найдите здесь Mobile Broadband HL Service, нажмите два раза по ней.
- Откроется окошко свойств службы, внутреннее название кстати может быть MobileBrServ.
- Отключаем — в менюшке Тип запуска выбираете Отключена. После — нажимаете кнопку Остановить. Потом можете сделать перезагрузку, чтобы проверить — не будет ли снова процесс mbbService грузить ПК?
На форуме 4PDA нашел инфу — mbbService является службой драйвера, который необходим для работы модема.
Как я понимаю, под модемом имеется ввиду эти USB-модемы.. которые используются для мобильного интернета, например от Билайна, Мегафона. Сами модемы могут быть производителя Huawei. При первом их подключении — происходит автоматическая установка специального софта.
После установки драйверов на модем у вас еще появится виртуальное устройство — Remote NDIS based Internet Sharing Device, правда драйвера для устройства используются от Microsoft. А еще в окне Мой компьютер может быть устройство CD-ром, будто у вас есть CD-привод, но на самом деле это от модема, это нормально, все они так работают.
Еще вы можете найти файл mbbServiceSetup — это установщик драйверов модема.
Оценить эту запись
Вопросы, касающиеся поддержки MBIM устройствами на обсуждаемой платформе, периодически возникают — и в этой теме, и в письмах, которые я получаю. В общем, это меня не удивляет, т.к. сколь-либо серьёзных исследований этого вопроса мы не проводили. Пожалуй, единственное, что можно было с уверенностью сказать, уже сказано на 6-й странице, где описаны стандартные композиции USB-устройств, доступные для выбора с помощью команды USB_MODE_SWITCH: есть композиция (режим 9), в которую входит адаптер MBIM.
Ну ещё я однажды заинтересовался автоматическим «переключателем» композиций, который должен был, по задумке авторов, выбирать эти композиции в зависимости от ОС (Win8/Win/Unix), под управлением которой работает устройство. Если помните, то в результате у меня получился мёртвый модем, который я смог восстановить значительно позже.
Эксперимент не был бесполезным, однако, т.к. стало понятно, что «переключалка» не работает. И ещё один раз мы как-то вспомнили про эту «переключалку» и выяснили, что для её работы необходимы корректные значения одного или двух флагов в /sys, которые устанавливает ядро.
Но как раз этого и не происходит. В результате, работа устройства в среде Win8 не детектируется, демон mbimd не запускается и включённый в композицию адаптер MBIM остаётся «висящим в воздухе», никуда не подключенным. Да, обработка всего этого происходит в скрипте /etc/rcS-zte.
Такая ситуация не могла продолжаться долго. Последней «каплей», пожалуй, стали недавние сообщения gric, который пытался решить вопрос подключения MF823 к планшету, работающему под управлением Windows RT. Конечно, эта система не представляет собой особого интереса для широкого круга пользователей, но как бы то ни было. есть — должно работать!
И вот, наконец, дошли руки. Собственно, исходной информации, описанной выше, было достаточно для того, чтобы определить направление мысли. Мы знаем, что «переключалка» не работает, мы знаем, что демон не запускается. Здесь можно добавить только то, что самого запуска mbimd — недостаточно.
Про протоколы взаимодействия с 3g/lte-модемом
Я, наивный, раньше думал, что протоколов общения с GSM-модемом на сегодняшний день существует не так уж и много. Пока не набрёл в Сети на одну занимательную PDF-ку с презентацией. Оказывается, оных технологий существует около десятка. Причём, как относительно “стандартных” и более-менее распространённых, так и всяких проприетарных и экзотических. Наглядно проиллюстрировать ситуацию можно так:
Если вкратце, то весь этот зоопарк сводится примерно к следующему.
- Семейство AT-комманд PPP
- Семейство ECM (Ethernet Control Model)
- Семейство EEM (Ethernet Emulation Model)
- Семейство NCM (Network Control Model)
- Проприетарщина типа Sierra и Option
- Условно-проприетарщина типа QCDM, WMC, QMI
- RNDIS
- MBIM
Если интересно, сравнение стандартизированных протоколов (ECM, EEM, NCM) и RNDIS можно посмотреть вот здесь.
Как говорится, “оу май факинг гад”! Но это всё голая теория. А что мы имеем на практике и какой протокол / модем лучше выбрать для использования в повседневной нелёгкой админской жизни и на какие грабли можно наступить? Какие нюансы следует держать в голове и учитывать?
- Варианты с PPP и RNDIS — самые тормозные, но в то же время и самые универсальные. Если вам нужна высокая скорость передачи данных и/или торренты, то они не для вас. Первый упирается в архитектурные ограничения, второй — в вычислительные мощности модема, который в таком случае становится уже и не модемом, а очень даже роутером. И помните, что RNDIS автоматически подразумевает наличие ещё одного NAT-а внутри модема, наряду с NAT-ом в сети провайдера.
- Самым свежим, “молодым” и перспективным протоколом является MBIM. В Windows начиная с 8-ки он поддерживается “из коробки”, никаких драйверов устанавливать не требуется: “воткнул и работает”. По этой же причине он не всегда корректно заводится под Linux-ом. В 2022-м году там было вообще всё очень грустно. Как сейчас — не знаю, надо тестировать. Может, и допилили. Именно этому протоколу следует отдавать предпочтение при прочих равных.
- Если выбирать между PPP, ECM, EEM и NCM, то лучше уж NCM. Именно он реализован в большинстве хуявых (Huawei) модемов.
- Почти все устройства на базе широко распространённых чипов имени Qualcomm будут поддерживать QMI. С точки зрения пользователя это вполне нормальный, годный протокол. Linux-ом обычно понимается нормально. Под винду надо ставить драйвера от производителя. Если оный супостат не приложил к железке диск с драйверами, то попробуйте взять их от Sierra Wireless EM7345. 🙂
- Бывает, что одно и то же устройство умеет работать в нескольких различных режимах. Тогда предпочтение тому или иному протоколу следует отдавать в таком порядке, по убыванию: проприетарщина, QMI, MBIM, NCM, ECM, RNDIS, PPP. Данная рекомендация касается админов и пользователей. У разработчиков софта скорее всего будет диаметрально противоположное мнение. 🙂
- Некоторые устройства по-разному представляются операционной системе в зависимости от её типа и версии. Например, бывают модемы, которые под Windows 7 автоматически включают режим RNDIS, под Windows 8 — MBIM, а под Linux-ом — QMI. Такая технология называется “морфинг” (morphing). Иногда это удобно, а иногда наоборот, прибавляет проблем.
Теперь касаемо выбора конкретного железа. Из того, что на момент написания этого поста реально купить, достойны внимания четыре модели.
- Sierra AirCard 320U. Офигенно, дорого, в России официально не продаётся. Есть на AliExpress-е. Заводится под чем угодно быстро и без проблем. Понимает свой собственный проприетарный протокол имени “Direct IP” (есть модуль под Linux) и QMI.
- Huawei E3272 и его клоны. Снят с производства, но можно взять на каком-нибудь Avito БУшный. Понимает RNDIS, он же HiLink, и NCM. Для переключения между одним и другим требуется перепрошивка. Обычно из коробки идёт с NCM-ом.
- Huawei E3372 и его модификации. Старший брат предыдущего товарища на более новом чипе и с более мощным процессором. Также понимает RNDIS и NCM, но намного хуже перепрошивается. Вариант для настоящих красноглазиков. Из коробки обычно идёт с прошивкой RNDIS (HiLink). Экземпляры из некоторых партий дык вообще перешиваются исключительно с применением паяльника. Спорный выбор, но имеет право на существование.
- ZTE MF823D. Полиморф. Настоящий комбайн с труЪ-линуксом внутри. Сделан на базе Qualcomm. Понимает QMI, RNDIS, MBIM и вроде как ECM. Для ценителей доступен линуксовый shell через telnet либо ADB-интерфейс. В MBIM переключать без особой нужды не рекомендуется, ибо при этом сразу теряется доступ к “кишкам” модема. Весьма занятный представитель своего племени.
Что касается конкретно меня, то первые два типа “мопедов” у меня уже довольно давно и успешно трудятся на благо предприятия. Про остальные два больше ничего сказать толком не могу. Купил по штучке “на пробу”, буду ковырять и смотреть как они себя ведут под реальной нагрузкой. Если у кого-то уже есть опыт использования одного из них, милостиво прошу поделиться своими соображениями. Потому что пока не могу решить кому бы отдать предпочтение при закупке следующей партии.
Проблемы с софтом для модема
У меня был некий опыт использования мобильного интернета. И все было также — при подключении модема в окне Мой компьютер появлялось устройство, какой-то CD-ром, с иконкой оператора. Если два раза нажать — то предлагалась установка софта либо открыть папку для просмотра.
Но суть не в этом.
Использовал несколько операторов и часто встречал одну и туже проблему — кривой софт:
- То он грузит комп.
- Бывает интернет пропадает просто так — помогала только перезагрузка.
- Интернет не хотел подключаться, какое-то там соединение.. подключение.. короче была ошибка.
Как я решал проблемы:
- Первое и самое главное — настроить интернет. Как только настроили, проверили что все работает норм — делаем точку восстановления, а лучше образ системы, ибо нарушить работу этого подключения оч легко (сужу по своей ситуации).
- Переустановка драйверов лучше делать только с последующим удалением хвостом. Это очень главное — из-за этого часто повторная установка проблемы не решает.
Чистка системы после удаления ПО очень важна:
- Во-первых нужно почистить реестр — открываете его (Win R > regedit), далее нажимаете Ctrl F, пишите ключевое слово, например Huawei и удаляете все хвосты.
- Файловые остатки удаляете также — в окне Мой компьютер, в правом верхнем углу — текстовое поле поиска. Пишите туда слово Huawei и удаляете все что найдете.
- Важно — вместо слова Huawei можно использовать другое, например MobileBrServ.
Расположение файла mbbservice.exe
Запускаться может из таких папок:
C:Program Files (x86)MobileBrServ
C:ProgramDataMobileBrServ
Заключение
Информации как оказалось — не так много.
Однако, кажется главное — выяснили:
- mbbService — это от модемного софта. Если вы пользуетесь модемным интернетом, то наличие процесса неудивительно.
- По информации с форума 4PDA — процесс участвует в работе драйвера. Скорее всего отключать его просто так нельзя — может пропасть мобильный интернет.
Надеюсь информация помогла. Удачи и добра!
На главную!18.06.2021