portable version of wsupp about minibase

[arsv]

Standalone version: https://github.com/arsv/wsupp-libc

May be somewhat buggy at this point, I did not check it much.

Note I left link-down logic there intact: if the link goes down and the cause is not rfkill, wsupp will exit. Typically this case is handled by link monitor of some sort. If you're not running any, it's probably not an issue for you.

[arsv]

It is certainly possible to rework wsupp so that it would use musl interfaces where appropriate. Just tried it quickly and maybe I will even get it working. It would still need large parts of lib/ bundled however because musl doesn't provide any NL code for instance. Chances are adding support for the arches Sabotage may need (i386 and PPC) will be easier than doing a proper port to musl. I've got a half-done i386 branch already, although it's a nasty target to deal with.

Side note, musl doesn't really support "any" linux arch, that would be impossible. It's just that they have more entries in arch/ than minibase does.

our approach to handling the dhclient / static IP stuff after connection is by calling an external script

Almost did it the same way in minibase. As long as the script is guaranteed to exit fast, this only requires rewriting wsupp_ifmon.c from what it is now to a simple fork-exec-wait sequence.

also, i would like to keep using the familiar tools ifconfig etc from busybox.

wsupp itself doesn't care how the links are set up, it's up to dhpc or whatever replaces dhcp.

[rofl0r]

Just tried it quickly and maybe I will even get it working

great!

Chances are adding support for the arches Sabotage may need (i386 and PPC) will be easier than doing a proper port to musl

right; but my preference is to use vanilla libc, so the code can be compiled on any linux system that has a libc (no matter if musl, uclibc, glibc, or even the buggy dietlibc )

i think your system-call layer is great for creating tiny statically linked programs, but not necessarily for regular applications. imo it'd be nice if one could switch it in and out using some define, e.g.

#ifdef USE_MINILIBC
#include <minilibc.h>
#define open(...) sys_open(...)
...

musl doesn't provide any NL code

right. is your NL code modeled after libnl ? we have libnl-tiny in sabotage: https://github.com/sabotage-linux/libnl-tiny

Side note, musl doesn't really support "any" linux arch, that would be impossible.

right, i actually meant: using libc, which in my case is musl.

[arsv]

This won't work at all:

#ifdef USE_MINILIBC
#include <minilibc.h>
#define open(...) sys_open(...)

The relation between open() and sys_open() looks like this:

extern int errno;

int open(const char* path, int mode)
{
        int ret;

        if((ret = sys_open(path, mode)) < 0) {
                errno = ret;
                return -1;
        } else {
                errno = 0;
                return ret;
        }
}

Note the presence of a global variable errno that requires ungodly efforts to handle in any thread-aware environment.

It doesn't really make much sense to bother with a custom base library if it were just a drop-in replacement for libc. I did exactly that for sninit, and I don't think it's worth repeating. Same goes for libnl, minibase code somewhat resembles the parts of libnl-tiny that aren't compatible with the full-size libnl.

so the code can be compiled on any linux system that has a libc

You are trying to request a very abstract quality that you don't really need, but which comes with a hefty price for the project. Standard libc isn't magic, isn't pretty, is a bad dependency, and is a royal PITA to port or debug.

[rofl0r]

thanks a lot, this is a work of art.

this version does support WPA1, right (unlike the demo/wpa program which explicitly mentions in its manpage that it doesnt) ?

i hope to integrate it asap into sabotage

[arsv]

Nope, none of them supports WPA1.

[rofl0r]

what would be needed to support it ? only using RC4 instead of AES ?

[arsv]

RC4, HMAC-MD5, a second set of IEs, mode selection and a bunch of if-s in wsupp_eapol.c, also probably some changes in wifi to indicate WPA2/WPA1.

[rofl0r]

do you plan to add support for WPA1 someday ? i can connect to WEP networks using vanilla iwconfig, but sometimes it's necessary to connect to WPA1 too.

on a different topic, wsupp is now part of sabotage linux:
sabotage-linux/sabotage@4f3b23e

dynamic:

-rwxr-xr-x    1 root     root         13896 Feb  9 20:27 wifi
-rwxr-xr-x    1 root     root         34376 Feb  9 20:27 wsupp

static:

# la /opt/wsupp/bin/
total 84
drwxr-xr-x    2 root     root          4096 Feb  9 21:11 .
drwxr-xr-x    6 root     root          4096 Feb  9 21:11 ..
-rwxr-xr-x    1 root     root         26104 Feb  9 21:11 wifi
-rwxr-xr-x    1 root     root         46328 Feb  9 21:11 wsupp

[arsv]

It wasn't planned, and I'm somewhat baffled by the request. WPA1 nowadays means a deliberately misconfigured AP, I don't think there are any valid reasons to run it. Anyway, I did plan to add support for non-encrypted (public) networks, which would require some of the changes needed for WPA1 anyway, so maybe I'll try to add WPA1 on top of that.

[rofl0r]

do you never use someone else's wifi when you're travelling ? think internet cafe of some kind. i guess they wouldn't really get my point if i'd try to convince them that they need to get another AP :)

[arsv]

Well yeah, but that's what I'd call misconfiguration. I would be really surprised to find a working AP that's hardware- or firmware-limited to WPA1 only.

[rofl0r]

i've added support for the WPA1 version of AES CCMP to https://github.com/rofl0r/wpakey . the only difference is that the IE is using microsoft OUI, and the type field uses 254 (EAPOL_KEY_WPA) instead of 2.
m3 packet differs in that it has the secure bit not set in info field.

this is sufficient to connect to all WPA1 routers i've seen so far.

[arsv]

Does it really connect? Did you try sending packets over the link, dhcp maybe?

I don't think WPA1 allows CCMP, but I wouldn't be surprised to learn that hostapd accepts combinations that shouldn't be possible.

m3 packet differs in that it has the secure bit not set in info field.

Missing Secure bit means link is not encrypted / key exchange is not complete.
Assuming you get Install bit without Secure set, I'm not even sure what it means.

If possible, try to check how hostapd sees this exchange. With debug output enabled, it should clearly indicate when it's sending 1/4, 3/4 and so on. Works with Android too by the way if you've got adb log access to the device.

[rofl0r]

i was lazy and quit upon receipt of M3, since i know by then that the password is correct.
you can check it easily with wireshark. almost everything is identical to wpa2.

here's an example hostapd.conf

interface=wlan1
driver=nl80211
logger_stdout=-1
logger_stdout_level=0
ssid2=P"TEST_AP"
wpa_passphrase=test1234
wpa=1
hw_mode=b
channel=1
beacon_int=500
dtim_period=1
max_num_sta=1
rts_threshold=2347
fragm_threshold=2346
supported_rates=10 20 55 110 60 90 120
basic_rates=10 20
macaddr_acl=0
auth_algs=3
ignore_broadcast_ssid=0
eapol_version=2
eap_server=0
wpa_psk_radius=0
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
group_mgmt_cipher=AES-128-CMAC

this is roughly equivalent to the WPA1 APs i've encountered so far (they do offer TKIP too, though). using wpakey, you can get the handshake till M3.