Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

portable version of wsupp #1

Closed
rofl0r opened this issue Feb 6, 2018 · 15 comments
Closed

portable version of wsupp #1

rofl0r opened this issue Feb 6, 2018 · 15 comments

Comments

@rofl0r
Copy link

rofl0r commented Feb 6, 2018

hi! i'm really impressed by wsupp and would like to embed it into my musl-based distro sabotage linux because wpa_supplicant drives me crazy.
however, i want it to use vanilla musl libc so it's portable to any linux arch, not just the ones in your mini-libc. also, i would like to keep using the familiar tools ifconfig etc from busybox.
i do think that using musl would not make the binary considerably bigger, and opens the tool to a much bigger audience.

would you be willing to make such a portable version ?

btw, our approach to handling the dhclient / static IP stuff after connection is by calling an external script which creates a background task (so as not to block) and calls itself again.

https://github.com/sabotage-linux/sabotage/blob/master/KEEP/wpa_supplicant-action_script.patch

https://github.com/sabotage-linux/sabotage/blob/master/KEEP/etc/wpa_connect_action.sh#L33
i use the essid in the script to set different static ip or dhcp rule according to network name.

@arsv
Copy link
Owner

arsv commented Feb 7, 2018

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
Copy link
Author

rofl0r commented Feb 7, 2018

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 :trollface: )

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
Copy link
Owner

arsv commented Feb 7, 2018

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.

@arsv
Copy link
Owner

arsv commented Feb 8, 2018

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.

@rofl0r
Copy link
Author

rofl0r commented Feb 9, 2018

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
Copy link
Owner

arsv commented Feb 9, 2018

Nope, none of them supports WPA1.

@rofl0r
Copy link
Author

rofl0r commented Feb 9, 2018

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

@arsv
Copy link
Owner

arsv commented Feb 9, 2018

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
Copy link
Author

rofl0r commented Feb 9, 2018

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
Copy link
Owner

arsv commented Feb 9, 2018

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
Copy link
Author

rofl0r commented Feb 9, 2018

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
Copy link
Owner

arsv commented Feb 9, 2018

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
Copy link
Author

rofl0r commented Feb 16, 2018

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
Copy link
Owner

arsv commented Feb 16, 2018

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
Copy link
Author

rofl0r commented Feb 16, 2018

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.

@arsv arsv closed this as completed Dec 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants