[PATCH v2] huawei: add basic support for ME909u-521
Aleksander Morgado
aleksander at aleksander.es
Thu Oct 6 09:35:11 UTC 2016
Hey Stefan,
Patch looks much better, but see some additional comments below.
On Fri, Sep 30, 2016 at 6:46 PM, Stefan Eichenberger <eichest at gmail.com> wrote:
> The ME909u-512 does theoretically support the DHCP feature over AT but if
> this is done right after the NDISDUP command, it seems that the firmware
> has some trouble with it because the firmware will not attach the
> Ethernet header afterwards. This can be seen by doing a tcpdump while
> pinging e.g. 8.8.8.8. The request has a size of 98 Bytes, while the
> replies only have a size of 84 Bytes. The first 14 Bytes are missing
> which is exactly the size of the Ethernet header.
>
> To reproduce this issue, I've tried the command sequence manually:
> mmcli -m 0 --command 'AT^NDISDUP=1,1,"gprs.swisscom.ch"'
> mmcli -m 0 --command "AT+CREG?"
> mmcli -m 0 --command "AT^NDISSTATQRY?"
> mmcli -m 0 --command "AT+CGREG?"
> mmcli -m 0 --command "AT^DHCP?"
>
> The error appears in with this sequence
>
> mmcli -m 0 --command 'AT^NDISDUP=1,1,"gprs.swisscom.ch"'
> mmcli -m 0 --command "AT+CREG?"
> mmcli -m 0 --command "AT^NDISSTATQRY?"
> mmcli -m 0 --command "AT+CGREG?"
>
> The error does not appear in this sequence
>
> This commit applies to 1.6.0 and adds a udev option for this modem,
> which disables the DHCP over AT command feature.
>
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger at netmodule.com>
> ---
> plugins/huawei/77-mm-huawei-net-port-types.rules | 3 ++
> plugins/huawei/mm-broadband-bearer-huawei.c | 53 +++++++++++++++++++-----
> 2 files changed, 45 insertions(+), 11 deletions(-)
>
> diff --git a/plugins/huawei/77-mm-huawei-net-port-types.rules b/plugins/huawei/77-mm-huawei-net-port-types.rules
> index f60f1f8..d35f2d5 100644
> --- a/plugins/huawei/77-mm-huawei-net-port-types.rules
> +++ b/plugins/huawei/77-mm-huawei-net-port-types.rules
> @@ -6,6 +6,9 @@ ENV{ID_VENDOR_ID}!="12d1", GOTO="mm_huawei_port_types_end"
> # MU609 does not support getportmode (crashes modem with default firmware)
> ATTRS{idProduct}=="1573", ENV{ID_MM_HUAWEI_DISABLE_GETPORTMODE}="1"
>
> +# MU909u does not support DHCP properly, it can happen that the Ethernet frames do not attach the Ethernet header afterwards.
> +ATTRS{idProduct}=="1573", ENV{ID_MM_HUAWEI_DISABLE_DHCP}="1"
> +
I'm not completely sure that "ID_MM_HUAWEI_DISABLE_DHCP" is the
correct tag name to use, because we're not really disabling DHCP,
we're disabling the "AT^DHCP" call only. So how about something like
"ID_MM_HUAWEI_DISABLE_AT_DHCP" instead?
> # Mark the modem and at port flags for ModemManager
> SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="ff", ATTRS{bInterfaceSubClass}=="01", ATTRS{bInterfaceProtocol}=="01", ENV{ID_MM_HUAWEI_MODEM_PORT}="1"
> SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="ff", ATTRS{bInterfaceSubClass}=="01", ATTRS{bInterfaceProtocol}=="02", ENV{ID_MM_HUAWEI_AT_PORT}="1"
> diff --git a/plugins/huawei/mm-broadband-bearer-huawei.c b/plugins/huawei/mm-broadband-bearer-huawei.c
> index 60a91e5..efc9fae 100644
> --- a/plugins/huawei/mm-broadband-bearer-huawei.c
> +++ b/plugins/huawei/mm-broadband-bearer-huawei.c
> @@ -465,17 +465,48 @@ connect_3gpp_context_step (Connect3gppContext *ctx)
> g_object_ref (ctx->self));
> return;
>
> - case CONNECT_3GPP_CONTEXT_STEP_IP_CONFIG:
> - mm_base_modem_at_command_full (ctx->modem,
> - ctx->primary,
> - "^DHCP?",
> - 3,
> - FALSE,
> - FALSE,
> - NULL,
> - (GAsyncReadyCallback)connect_dhcp_check_ready,
> - g_object_ref (ctx->self));
> - return;
> + case CONNECT_3GPP_CONTEXT_STEP_IP_CONFIG: {
> + GUdevClient *client;
> + GUdevDevice *tty_device;
> +
> + /* ME909u has a problem with DHCP over AT. If it's done right after NDSIDUP
> + * the modem doesn't send the Ethernet header anymore which confuses the network stack
> + */
> + client = g_udev_client_new (NULL);
> + tty_device = (g_udev_client_query_by_subsystem_and_name (
> + client,
> + "tty",
> + mm_port_get_device (MM_PORT (ctx->primary))));
> + if (!tty_device) {
> + /* Clear context */
> + ctx->self->priv->connect_pending = NULL;
> + g_simple_async_result_set_error (ctx->result,
> + MM_CORE_ERROR,
> + MM_CORE_ERROR_NOT_FOUND,
> + "No valid tty device found to query AT DHCP support");
> + connect_3gpp_context_complete_and_free (ctx);
> + return;
> + }
> + if (!g_udev_device_get_property_as_boolean (tty_device, "ID_MM_HUAWEI_DISABLE_DHCP")) {
> + mm_base_modem_at_command_full (ctx->modem,
> + ctx->primary,
> + "^DHCP?",
> + 3,
> + FALSE,
> + FALSE,
> + NULL,
> + (GAsyncReadyCallback)connect_dhcp_check_ready,
> + g_object_ref (ctx->self));
> + return;
> +
> + }
The udev client and the tty_device are still leaking in all return points...
But, could you anyway rebase the patch on top of git master? Once you
do that, you won't need all the GUdevClient and GUdevDevice logic,
just something like this:
if (!mm_kernel_device_get_property_as_boolean
(mm_port_peek_kernel_device (MM_PORT (ctx->primary)),
"ID_MM_HUAWEI_DISABLE_AT_DHCP")) {
...
}
> +
> + mm_info("This device (%s) does not support DHCP over AT", mm_port_get_device (ctx->data));
> + ctx->ipv4_config = mm_bearer_ip_config_new ();
> + mm_bearer_ip_config_set_method (ctx->ipv4_config, MM_BEARER_IP_METHOD_DHCP);
> + ctx->step ++;
> + /* Fall down to the next step */
> + }
>
> case CONNECT_3GPP_CONTEXT_STEP_LAST:
> /* Clear context */
> --
> 2.0.4
>
--
Aleksander
https://aleksander.es
More information about the ModemManager-devel
mailing list