golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.27k stars 17.57k forks source link

x/sys/unix: add wireless iwreq support from Linux kernel #48338

Open ghost opened 3 years ago

ghost commented 3 years ago

Currently x/sys/unix has type Ifreq and function IoctlIfreq, but it would be nice if somebody added wireless support (linux/wireless.h), since the kernel has a couple of useful functions for that.

For example, here is a sample C code to get SSID of a wireless connection:

...
#include <linux/wireless.h>
...
    struct iwreq req;
    strcpy(req.ifr_ifrn.ifrn_name, argv[1]);
    int fd, status;
    fd = socket(AF_INET, SOCK_DGRAM, 0);
    char* buffer;
    buffer = calloc(32, sizeof(char));
    req.u.essid.pointer = buffer;
    req.u.essid.length = 32;
    if (ioctl(fd, SIOCGIWESSID, &req) == -1) {
        fprintf(stderr, "Failed ESSID get on interface %s: %s\n", argv[1], strerror(errno));
    } else {
        printf("%s", (char*)req.u.essid.pointer);
    }
    free(buffer);
...

As far as of now, i don't know a way to reproduce the same thing in Go, apart from using import "C" in place. A library functions for that sort of thing would be great.

mdlayher commented 3 years ago

No objections to adding it from me, but you may also have some luck with https://github.com/mdlayher/wifi which uses the nl80211 netlink API rather than more ioctls.

ghost commented 3 years ago

@mdlayher just read your blog post, turns out ioctl wireless API is legacy? Suppose it would be more proper to actually use your netlink implementation in the future? If it is so, i don't actually see a reason anyone would want to develop anything for the legacy API, since iwd, NetworkManager, and even wpa_supplicant (with -Dnl80211) use the newer one. And yes, your implementation works for me, so i suppose this issue can be closed, if nobody objects.

mdlayher commented 3 years ago

I'm pretty far removed from the problem space but if all ioctl operations can be performed with nl80211, then yeah I'd recommend going that route instead. I'll leave closing the issue up to you since there's no harm in adding more API to x/sys/unix to mirror the kernel uapis.