Intel IWD Makes Another Step Closer To Version 1.0

[phoronix]

Phoronix: Intel IWD Makes Another Step Closer To Version 1.0

The past few years open-source Intel developers have been creating a new Linux wireless daemon to potentially replace wpa_supplicant. This daemon, IWD, continues getting more feature-complete and is well on its way toward version 1.0...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-IWD-0.8-Released

[starshipeleven]

Yass. Station means acting as an access point. I like that.

[cb88]

It's worth noting that wpa_supplicant is cross-platform whereas this does not seem to be.

wpa_supplicant runs on at leaset BSD, Linux, Haiku, Solaris and Windows (with win pcap)... etc..

Also why not just use hostapd if you want host support... at the GUI or Networkmanager level it ought to not matter that those are controlled by separate daemons.... which have distint and separate purposes. If your GUI doesn't support host mode... thats the fault of the GUI and you can blame that on gnome people dumbing things down.

[johanb]

I am really excited about IWD.

However, I tried to use it last week and was able to connect to my wireless connection and IWD told me that it was connected. But even though i was connected according to IWD i saw to ip with "ip addr" and couldn't ping my local router.

Either I'm stupid and missing something very obvious or it doesn't work properly, not sure which one though.

[starshipeleven]

It's worth noting that wpa_supplicant is cross-platform whereas this does not seem to be.

wpa_supplicant runs on at leaset BSD, Linux, Haiku, Solaris and Windows (with win pcap)... etc..

It's somewhat irrelevant though as drivers aren't the same.

Afaik winpcap has nothing to do with the network technology used (and is also long obsoleted and replaced by npcap from nmap project), as it is using a Windows API.

Also why not just use hostapd if you want host support...

It's not like adding RGB controller functionality, why not have only one daemon dealing with all wifi instead of one daemon on top of another?
Does keep the station functionality separated give any kind of benefit?

[pkunk]

missing something very obvious

DHCP, iwd provides only physical connection (ip link).

[cb88]

It's somewhat irrelevant though as drivers aren't the same.

Which is an irrelevant statement as wpa_supplicant doesn't operate at the driver level.... the new intel utility like alot of things of late is far too integrated with Linux... without providing any plan for portability. The supplicant authenticates and interacts with the operating system not directly with drivers.

Open source software that isn't portable is half way to being as bad as closed source software.

[mb_q]

Substantial stuff missing (AFAICT):
- TLS certs require patched kernel,
- No TTLS-PAP, total abomination, but a must-have of eduroam,
- UX: poor documentation (currently the best source are the tests), CLI basically supports only PSK.

[starshipeleven]

Which is an irrelevant statement as wpa_supplicant doesn't operate at the driver level....

I meant that the other OSes (windows, MacOS, Slowlaris, and other proprietary stuff like Cisco and other high-end networking) have their own infrastructure already, so there is no real point in having it be so cross-platform.

Beyond being able to run some specific applications cross-platform to some extent, but then again what applications actually need to be able to control that.

And of those how many applications would be far better off using the same interface wpa_supplicant is using with the OS?

the new intel utility like alot of things of late is far too integrated with Linux... without providing any plan for portability. The supplicant authenticates and interacts with the operating system not directly with drivers.

And the main reason this is done is to avoid excessive abstraction, which is one of the issues of wpa_supplicant codebase, and of other daemons that deal with hardware but are too cross-platform for their own good.

This can be seen also in OpenSSL library, as it strives to be as cross-platform as possible it had to assume that there were some total shit OSes that lacked some functionality and had to implement it on its own (the pseudo-RNG functionality comes to mind)

Open source software that isn't portable is half way to being as bad as closed source software.

I would agree with you if we were talking of some random userspace software, that uses generic API available everywhere.

If we are talking of applications managing, or closely interacting with hardware (and the kernel), if you want performance it's so much better to have the cross-platform capability provided by an open API, with each OS providing that API with a different or very customized fork of the original code.

So applications can still use the same API to talk to what will be different daemons in different operating systems doing the same thing.

Which is what systemd project is doing with its daemons (and one of the reasons why things like elogind exist and work crossplatform).

Or what the ZFS project is doing, creating different drivers that provide the same features in different filesystems, starting from a shared codebase that is modified downstream to work on different kernels.

IWD can be easily "provided" by something else native in another OS, and as long as the interface towards userspace is the same, then applications won't complain.

[tildearrow]

Sorry Michael I just noticed a typo on the short description:

Intwl IWD