Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#5697 closed enhancement (fixed)

setwep: wrap it in a GUI

Reported by: mmadia Owned by: nobody
Priority: normal Milestone: R1/alpha3
Component: Applications/Command Line Tools Version:
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

hrev36057 added a temporary CLI application setwep . It is a temporary means for joining an unencrypted or WEP encrypted wifi network. setwep works with 64- and 128-bit WEP and supports both text keys as well as hex digit keys.

Wrapping a simple GUI around set and e.g. adding it to the Network preflet, would greatly improve its appeal.

Attachments (1)

add-wep.diff (6.6 KB ) - added by alexbl 14 years ago.

Download all attachments as: .zip

Change History (14)

by alexbl, 14 years ago

Attachment: add-wep.diff added

comment:1 by alexbl, 14 years ago

Attached patch hacks wep and ssid support into ifconfig. it's currently untested but It should work. It should also probably be cleaned up to fit better into the way ifconfig works in the first place, but here is the patch now so if I don't do it someone else doesn't have to start from zero. :)

comment:2 by jackburton, 14 years ago

By the way... (this would probably fit into another ticket, though) on linux, ifconfig is deprecated, and the new interface for network settings is "iproute". Dunno if we want to follow the same... route.

comment:3 by axeld, 14 years ago

I see no reason to deprecate ifconfig as long as it does everything it should without getting annoying to use.

comment:4 by tangobravo, 14 years ago

A GUI is certainly very important for wifi - but it should be a first class citizen and not just a wrapper around the CLI api. Wifi is quite a dynamic thing, so the GUI needs a constantly refreshing list of visible access points, some concept of a "preferred" list of networks, etc. How does the current network preflet work? I never really trust what it tells me currently - it somehow feels like it probably just calls ifconfig with a command line, it doesn't feel quite as "live" as I would expect. Obviously code should be shared between the command line and GUI utilities bit I'd rather see a shared library than a GUI that calls the command-line app, as GUIs usually deal with one parameter at once, whereas command line interfaces usually batch them up.

For Alpha 2 though, just a simple GUI for setwep would be fine with me, and I think would be a great addition. It doesn't work for me, btw, but I'll post another ticket when I've done more testing (like trying unencrypted).

comment:5 by stippi, 14 years ago

Your comments about the current Network preflet are overall rather uninformed.

in reply to:  5 ; comment:6 by tangobravo, 14 years ago

Replying to stippi:

Your comments about the current Network preflet are overall rather uninformed.

Indeed so. Apologies for once again causing unintended offence! I appreciate how annoying it must be for those doing the work that others pop up and insert criticisms wrapped in philosophical "I'd prefer it if..." or "The BeOS/Haiku way is..." arguments (especially when, as in this case, the arguments are based on false assumptions). I'll resist posting them in future.

The point here was "the wifi GUI should ideally be more than an app that calls setwep", but that's probably universally acknowledged anyway.

Simon

in reply to:  6 comment:7 by anevilyak, 14 years ago

Replying to tangobravo:

The point here was "the wifi GUI should ideally be more than an app that calls setwep", but that's probably universally acknowledged anyway.

Indeed, setwep and an associated GUI wrapper are merely a temporary measure until the overall wifi stack/framework are a bit more fleshed out ; at the moment there is no good mechanism for programmatically discovering the list of available APs (with corresponding signal strengths), etc. which would be needed for a proper preflet.

comment:8 by alexbl, 14 years ago

There is actually not one, but two ways to list the set of available APs. One is to use the BOSII_DETECT_NETWORKS ioctl, and the other is to use the IEEE80211_IOC_SCAN and IEEE80211_IOC_SCAN_RESULTS ioctls. If you look at my wpa_supplicant driver implementation ( http://alexbl.net/~alexbl/haiku-wpa/driver_haiku.c ) you can see examples of using and parsing them.

comment:9 by stippi, 14 years ago

Hi alexbl, your work looks rather interesting, can you explain more about it? Is the looper supposed to be part of the net_server, or does it go somewhere else?

comment:10 by czeidler, 13 years ago

Resolution: fixed
Status: newclosed

I think Axel fixed it...

comment:11 by luroh, 13 years ago

Just to let you that I couldn't connect to my wep router yesterday using NetworkStatus or ifconfig. The router requires a 26-digit hex key and those tools currently only seem to accept a passphrase of up to 16 chars. More than that and they throw a "General system error".

Maybe it's me doing something wrong, like not using the correct syntax for denoting the hex key (tried with/without '0x'). If that's indeed the case, some pointers would be appreciated.

comment:12 by axeld, 13 years ago

The tools currently read raw data, that is you would need to translate the hex key to that. I'll add a nicer way to do this - any suggestions on how the hex input should look like?

comment:13 by jprostko, 13 years ago

Just wanted to say, I was having the same issue as luroh (26 digit hex WEP key), so thanks Axel for the tip. I'll give it a whirl. For me, personally, once WPA2 is around, I'll be switching to that exclusively, and won't really care about the whole hex/ascii key issue. Is there a check that can be done that checks the number of bytes and then make sure every one is hex if the string is an appropriate length for a hex key? I guess doing the whole "0x" thing could work too, but it seems kind of unnecessary if the proper checks are in place.

Note: See TracTickets for help on using tickets.