Announcement

Collapse
No announcement yet.

A New Wireless Daemon Is In Development To Potentially Replace wpa_supplicant

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DeepDayze
    replied
    Originally posted by c117152 View Post

    That's what I'm happy about. Actually, I'd be even happier if they let us have a small user-land library that makes all the sys-calls to the kernel's crypto APIs... The video even mentioned a separate TLS effort too... Can you imagine writing tiny html and ssh daemon that don't need all those huge crypto libraries? Joy
    As SSL/TLS support is a MUST for wifi, there should be hooks for the existing SSL/TLS libs that may be installed on the system or at even include a basic SSL/TLS library in the package as a fallback where system SSL/TLS libraries aren't installed.

    Leave a comment:


  • c117152
    replied
    Originally posted by DeepDayze View Post

    I am sure there will be SSL support in due time as this daemon still is a WIP.
    That's what I'm happy about. Actually, I'd be even happier if they let us have a small user-land library that makes all the sys-calls to the kernel's crypto APIs... The video even mentioned a separate TLS effort too... Can you imagine writing tiny html and ssh daemon that don't need all those huge crypto libraries? Joy

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by carewolf View Post
    wpa_supplicant still exists?

    I haven't had to configure it for a decade or so, ever since network-manager came around.
    wpa_supplicant is network-manager's backend when it operates wifi.

    So yeah, the beast is caged and under watch, but still there.

    Leave a comment:


  • carewolf
    replied
    wpa_supplicant still exists?

    I haven't had to configure it for a decade or so, ever since network-manager came around.

    Leave a comment:


  • Guest
    Guest replied
    Very good. I'd like to see something more automatic than wpa_supplicant.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by xeekei View Post

    OpenBSD does name everything Open-yaddayadda (Except for LibreSSL for obvious reasons), so I guess it makes sense.
    I still can't get over the elegant triple meaning that name has. "Libre" is our pseudo-loanword for "free as in freedom", it's a more principled subset of "Open" in the world of licensing, and you can also read it as "Re[done/made/factored/etc.] SSL", with the standard "lib-" prefix.

    Leave a comment:


  • xeekei
    replied
    Originally posted by ElectricPrism View Post

    At least it would be predictable. I mean - we wouldn't want Linux CLI to be predictable and easy to remember right? Why not complicated and 10 million conflicting naming schemas. /sarcasm
    OpenBSD does name everything Open-yaddayadda (Except for LibreSSL for obvious reasons), so I guess it makes sense.

    Leave a comment:


  • DeepDayze
    replied
    Originally posted by c117152 View Post
    Enterprise wifi without an SSL library... Oh my...
    I am sure there will be SSL support in due time as this daemon still is a WIP.

    Leave a comment:


  • microcode
    replied
    Seems like OTC is more interested in the embedded side of this for now; though if some others pick up the additional work it looks like there's no reason it couldn't also be good for wifi on laptops and the suchlike.

    Leave a comment:


  • ptrwis
    replied
    This is not under systemd umbrella but 38:16 is the perfect reason to fork it ;> (and rename)

    Leave a comment:

Working...
X