lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGRyCJHA8q9NeA_zf+m0B03eD+FcV0=9LZsFJjdPcBJe-ssM8Q@mail.gmail.com>
Date:   Fri, 4 Jan 2019 17:06:37 +0100
From:   Daniele Palmas <dnlplm@...il.com>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] qmi_wwan: add MTU default to qmap network interface

Hi Bjørn,

Il giorno ven 4 gen 2019 alle ore 14:24 Bjørn Mork <bjorn@...k.no> ha scritto:
>
> Daniele Palmas <dnlplm@...il.com> writes:
>
> > This patch adds MTU default value to qmap network interface in
> > order to avoid "RTNETLINK answers: No buffer space available"
> > error when setting an ipv6 address.
> >
> > Signed-off-by: Daniele Palmas <dnlplm@...il.com>
> > ---
> >  drivers/net/usb/qmi_wwan.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > index 774e1ff..735ad83 100644
> > --- a/drivers/net/usb/qmi_wwan.c
> > +++ b/drivers/net/usb/qmi_wwan.c
> > @@ -123,6 +123,7 @@ static void qmimux_setup(struct net_device *dev)
> >       dev->addr_len        = 0;
> >       dev->flags           = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
> >       dev->netdev_ops      = &qmimux_netdev_ops;
> > +     dev->mtu             = 1500;
> >       dev->needs_free_netdev = true;
> >  }
>
> Setting some value makes sense, but hard coding 1500 feels wrong.
> Should this relate to the real device mtu somehow?  Do we need a
> ndo_change_mtu to enforce this relationship?  Should qmimux_rx_fixup()
> respect the qmap device mtu?
>

yes, all your questions seem relevant to me: in the the first draft of
my patch qmap mtu was related to the real dev mtu, considering also
the qmap header, but then I took a look at how the rmnet driver is
managing mtu.

If I'm not wrong, it seems that mtu is hardcoded also for rmnet
(RMNET_DFLT_PACKET_SIZE = 1500 defined in
drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h and applied in
rmnet_vnd_setup function at rmnet_vnd.c).

I do not see any part of code in which the rmnet mtu is related to the
mtu of the underlying device (but maybe it's me that is missing
something obvious) so I used the same approach, hard coding the value.

Maybe should  usbnet_change_mtu be called with the qmap network
interface mtu (+ qmap header size ?) when creating a qmap device, like
in qmi_wwan_netdev_setup?

Sorry in advance if I'm writing silly things...

Thanks,
Daniele

> I'm fine with this patch as a first step and immediate fix, so
>
> Acked-by: Bjørn Mork <bjorn@...k.no>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ