Home | News | Download | Packages | Forum | Wiki | Github

[solved] Any plans when void supports IWD?


#21

I am on the road currently and can’t test. But will do and report it asap.


(maxice8 alter) #22

it uses dbus to communicate via iwctl (which is the progrma you use to control it) so i’m almost completely positive that dbus is required


#23

At the moment I can just say that arch’s PKGBUILD does NOT have dependencies on dbus: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/iwd

But I have to test to be sure.


(maxice8 alter) #24

pretty sure they have dbus on the base system since they use systemd


#25

Oh you are right. This may explain it.


#26

Why did the musl build fail?


(maxice8 alter) #27

please use the github pull request to comments.

but it is problably because it is a networking utility and kernel headers are confusing


#28

GLIBC does include linux/if_ether.h while musl defines everything it self which obviously doesn’t end well because iwd does include linux/if_ether.h. Seems like it will be a lot fun to fix that.


#29

So just built and tried it. It works fine so far, but I can’t connect to WPA Enterprise networks. I got the error message Operation failed. Any suggestions?


(maxice8 alter) #30

see the arch wiki for that specific case


#31

According to the arch wiki page:

IWD follows a more simple, more secure and more modern approach.

Eek. There’s something about claims like this that scares me.

I’ve had lots of troubles with Networkmanager, connman, wicd and others before; but never any troubles using wpa_supplicant directly. Does anyone have any information on what iwd plans to do differently, other than the dbus interface?


(Enno Boland) #32

#33

I did before and created the config file but it still does not work. Hower, I will have to debug by myself. Thanks for your help.


#34

Thanks for the video Gottox.

It looks like a megaproject, aimed to replace a massive amount of existing work (beyond just wpa_supplicant) and providing a universal interface for several wireless types.

It sounds good in theory, but I’ve never heard of these mega asbtraction projects going well. Let’s see and hope the results are good. The bigger something is the harder it is for devs to acknowledge mistakes and to go back to fix them, both from practical and psychological perspectives.

N.B. according to the video dbus is just one interface for comms, it happily supports simple sockets, which makes me very happy. Alas your frontend also needs to support this.


(Enno Boland) #35

Hu? What kind of wireless types are you speaking about. iwd only supports a subset of the features supported by wpa_supplicant. And the architecture seems to be a lot simpler.


#36

Apologies, it looks like I’ve confused some of the intro material with the project goals. He talks about the existing stacks including NFC & bluetooth.

EDIT: Ooh, he’s showing off the lack of deps. That’s getting me all excited :stuck_out_tongue:


#37

Same problem for me.
My University uses PEAP+MSCHAPv2.

Here’s the list of many sample examples, but the only one with MSCHAPv2 as the second stage is TLS. Substituting TLS for PEAP does not seem to work.

Also, iwctl’s output is not very informative.

Also, there are some problems with reconnecting if adapter is restarted.


#38

Thank you very much. This is exactly what I was looking for! :slight_smile:

EDIT:
How can I get this working:

# wpa_supplicant config
network={
	ssid="my essid"
	scan_ssid=1
	key_mgmt=WPA-EAP
	identity="my user"
	password="my password"
	eap=PEAP
	phase1="peaplabel=0"
	phase2="auth=MSCHAPV2"
	priority=85
}

#39

I haven’t yet tried it, but they added an example to the mailing list when I asked for one on IRC.


#40

Thanks @eichhorn but isn’t this the same like https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/autotests/testEAP-MSCHAPV2 ?