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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 26 Apr 2017 10:55:46 -0400
From:   Michael Richardson <mcr@...delman.ca>
To:     Alexander Aring <aar@...gutronix.de>
cc:     Network Development <netdev@...r.kernel.org>,
        Jukka Rissanen <jukka.rissanen@...ux.intel.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "linux-wpan\@vger.kernel.org" <linux-wpan@...r.kernel.org>,
        Linux Bluetooth <linux-bluetooth@...r.kernel.org>
Subject: Re: bluetooth 6lowpan interfaces are not virtual anymore


Alexander Aring <aar@...gutronix.de> wrote:
    >> In a classic SVR4 STREAMS works, it would have been just another
    >> module.  (No, I'm not a fan of *STREAMS* or of SVR4 in general,
    >> although I liked some of the ideas).
    >>

    > ok, I see you complain about "having a virtual on top of wpan
    > interface", or?

    > I wanted to talk at first about the queue handling which is introduced
    > when 6LoWPAN is not a virtual interface anymore. Or do you want to have
    > a queue in front of 6lowpan adaptation (see other mail reply with ASCII
    > graphics).

I would like to have a single queue, as close to the hardware as possible,
such that BQL can do it's thing easily.  Should we rethink outgoing fragment
handling for 6lowpan?  Clearly the BT people had a need.
I don't think they've had a chance to respond to your complaints.

    > We can change that you can run multiple interfaces on one
    > PHY. Currently we just allow one, because address filtering. Disable
    > address filtering
    > we will loose ACK handling on hardware.

Yes, that's a limitation of some hardware, and if you enable multiple PANIDs,
that might be the consequence....

    > I can try to implement all stuff in software "for fun, maybe see what
    > we can do to handle ACK in software, etc" Then you can run multiple

I'm not asking you to do it, I'm asking, now that we've gotten to a certain
point, we have a better idea what the various requirements are, and can we
re-evaluate things and maybe tweak some things.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@...delman.ca  http://www.sandelman.ca/        |   ruby on rails    [


Download attachment "signature.asc" of type "application/pgp-signature" (473 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ