1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
Utiliser une clé 4G E3372h sous Linux
===================
Ăa fait quelques annĂ©es que j'ai remplacĂ© mon portable (un galaxy S4 ...) par une clĂ© USB 4G.
Une clé que j'utilise toujours encore d'ailleurs !
La référence de la clé est E2272h-153, je l'ai en 2 modÚles, une un peu vielle qui par l'usure [des années s'est abßmé](https://linuxfr.org/forums/general-cherche-materiel/posts/cle-4g-linux-et-gammu). L'autre plus récente mais qui manifestement n'a rien de différent.
Bref, il se trouve que ces clés fonctionnent de maniÚre bizarre au démarage. Elles veullent installer leurs pilotes avant de vraiment se lancer. Sauf que ça marche pas vraiment comme ça sous Linux. Il va alors faloir changer le mode de la clé automatiquement. Tout ce qu'il faut savoir c'est que c'est une pratique courante et bien utile pour créer des produits plug & play. Le mot clé associé est [ZeroCD](https://en.wikipedia.org/wiki/Virtual_CD-ROM_switching_utility).
Pour changer de mode sous Linux, on utilise `usb_modeswitch`. Pour fonctionner, cet utilitaire aura besoin des droits super utilisateur. DĂšs qu'il a envoyĂ© la commande de âswitchâ, l'utilitaire s'arrĂȘte; ce n'est donc pas un service qui tourne en tache de fond avec des droits root.
~~~shell
$ usb_modeswitch --help
* usb_modeswitch: handle USB devices with multiple modes
* Version 2.6.1 (C) Josua Dietze 2017
* Based on libusb1/libusbx
! PLEASE REPORT NEW CONFIGURATIONS !
Usage: usb_modeswitch [<params>] [-c filename]
-h, --help this help
-e, --version print version information and exit
-j, --find-mbim return config no. with MBIM interface, exit
-v, --default-vendor NUM vendor ID of original mode (mandatory)
-p, --default-product NUM product ID of original mode (mandatory)
-V, --target-vendor NUM target mode vendor ID (optional)
-P, --target-product NUM target mode product ID (optional)
-C, --target-class NUM target mode device class (optional)
-b, --bus-num NUM system bus number of device (for hard ID)
-g, --device-num NUM system device number (for hard ID)
-m, --message-endpoint NUM direct the message transfer there (optional)
-M, --message-content <msg> message to send (hex number as string)
-2, --message-content2 <msg>
-3, --message-content3 <msg> additional messages to send if needed
-w, --release-delay <msecs> wait a while before releasing the interface
-n, --need-response obsolete, no effect (always on)
-r, --response-endpoint NUM read response from there (optional)
-K, --std-eject send standard EJECT sequence
-d, --detach-only detach the active driver, no further action
-H, --huawei-mode apply a special procedure
-J, --huawei-new-mode apply a special procedure
-X, --huawei-alt-mode apply a special procedure
-S, --sierra-mode apply a special procedure
-O, --sony-mode apply a special procedure
-G, --gct-mode apply a special procedure
-N, --sequans-mode apply a special procedure
-A, --mobileaction-mode apply a special procedure
-T, --kobil-mode apply a special procedure
-L, --cisco-mode apply a special procedure
-B, --qisda-mode apply a special procedure
-E, --quanta-mode apply a special procedure
-F, --pantech-mode NUM apply a special procedure, pass NUM through
-Z, --blackberry-mode apply a special procedure
-U, --option-mode apply a special procedure
-R, --reset-usb reset the device after all other actions
-Q, --quiet don't show progress or error messages
-W, --verbose print all settings and debug output
-D, --sysmode specific result and syslog message
-s, --check-success <seconds> check switching result, with timeout
-I, --inquire obsolete, no effect
-c, --config-file <filename> load long configuration from file
-t, --stdinput read long configuration from stdin
-f, --long-config <text> get long configuration from string
-i, --interface NUM select initial USB interface (default 0)
-u, --configuration NUM select USB configuration
-a, --altsetting NUM select alternative USB interface setting
~~~
Moi j'utilise une clé Huawei et le mode `-J` fonctionne trÚs bien donc la commande est :
~~~shell
# usb_modeswitch -v 12d1 -p 14fe -J
~~~
Le numéro de vendeur (`-v`) et de produit (`-p`) sont récupérer depuis `dmesg`.
Vous devriez voir ceci apparaitre ceci :
~~~shell
# dmesg
...
[46469.963675] usb 2-1: New USB device found, idVendor=12d1, idProduct=14fe, bcdDevice= 1.01
[46469.963685] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[46469.963689] usb 2-1: Product: HUAWEI_MOBILE
...
~~~
Une fois que c'est fait c'est fini. Normalement la clé devrait resté dans le mode modem.
Cependant depuis quelque temps, elle revient en mode clé USB (*mass storage*).
Pour automatiser ça, j'ai rajouté une rÚgle udev dans le fichier `/etc/udev/rules.d/41-whatever.rules`.
~~~text
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14fe", RUN+="/usr/bin/usb_modeswitch -v 12d1 -p 14fe -J"
~~~~
Ce n'est pas un *big deal* j'avais déjà 2 paires de rÚgles pour automatiser mon installation.
~~~text
ACTION=="add", KERNEL=="ttyUSB0", SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506", RUN+="/usr/bin/systemctl start smsd"
ACTION=="remove", KERNEL=="ttyUSB0", SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506", RUN+="/usr/bin/systemctl stop smsd"
ACTION=="add", KERNEL=="ttyUSB1", SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506", RUN+="/usr/bin/systemctl start wvdial"
ACTION=="remove", KERNEL=="ttyUSB1", SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506", RUN+="/usr/bin/systemctl stop wvdial"
~~~
Qui activent et désactivent gammu et wvdial lorsque je connecte et déconnecte la clé.
Gammu permet de gérer les SMS. J'ai codé un programme en C pour pouvoir gérer ça de maniÚre pratique. Il s'appelle [mesms](https://git.ache.one/mesms) et j'auto-héberge les sources.
Ăa ressemble à ça :
![Interface de mesms](https://ache.one/res/mesms.gif)
wvdial est un modÚme qui se charge d'activer la connection et crée un pont ppp avec la clé pour avoir internet en 4G.
j'ai entendu dire que je pouvais utiliser [NCM](https://github.com/torvalds/linux/blob/master/drivers/net/usb/huawei_cdc_ncm.c) mais trÚs franchement, je n'ai pas cherché plus que ça. Pour l'instant ça marche.
Le fichier de configuration de wvdial est trĂšs basique (`/etc/wvdial.conf`):
~~~text
[Dialer Defaults]
ISDN = 0
Dial Command = ATDT
Stupid Mode = 1
Init1 = ATZ
Init3 = AT+CGDCONT=1,"IP","free"
Phone = *99***1#
Modem = /dev/ttyUSB1
New PPD = yes
Modem Type = USB Modem
ISDN = 0
Username = free
Password = free
Auto DNS = Off
~~~
J'ai une autre version pour d'autres carte SIM comme par exemple :
~~~text
[Dialer Defaults]
ISDN = 0
Dial Command = ATDT
Stupid Mode = 1
Init1 = ATZ
Init3 = AT+CGDCONT=1,"IP","drei.at"
Phone = *99#
Modem = /dev/ttyUSB1
New PPD = yes
Modem Type = USB Modem
ISDN = 0
Username = drei.at
Password = drei.at
Auto DNS = Off
~~~
Il n'y a pas beaucoup de changement. Il suffit généralement de changer simplement le nom de l'APN.
J'aurais certainement d'autres choses à dire mais ça sera pour une prochaine notes ! \o
<tag>4g</tag><tag>huawei</tag><tag>usb</tag><tag>lte</tag>
|