| View previous topic :: View next topic |
| Author |
Message |
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
 Posted: Fri Jul 24, 2015 7:42 pm Post subject: 'ifconfig <iface> <ip>' not getting the right ip |
 |
|
Okay, so on my other distro (Mint) on the same machine I got a script at boot to connect to the internet which is:
| Code: |
#!/bin/bash
iface=wlan0
essid=#cut out
key=#cut out
ip=192.168.0.6
ifconfig "$iface" down &&
ifconfig "$iface" up &&
if [ ! -z "$ip" ] ; then
ifconfig "$iface" "$ip"
fi &&
iwconfig "$iface" essid "$essid" key "$key" &&
dhclient "$iface"
|
Which runs at boot or whenever I want and connects and always succeeds in getting the IP I want, in rare cases it gets 192.168.0.101 instead of 192.168.0.6 but then simply running the script manually solves this. On Gentoo however it always gets 101 on exactly the same hardware. The connexion with dhclient otherwise succeeds.
Also, my /etc/conf.d/net: (on mint this is stored in /etc/network/interfaces with an entirely different syntax):
| Code: | modules="iwconfig"
config_<essid_cut>="192.168.0.6/24 brd 192.168.0.255"
routes_<essid_cut>="default via 192.168.0.1"
key_Wireless="[1] <key_cut> key [1] enc open"
dns_servers="8.8.8.8 8.8.4.4"
|
Not sure if there is some other configuration file I have overlooked? |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Fri Jul 24, 2015 8:14 pm Post subject: |
|
|
I don't remember exactly how to set up OpenRC wireless directly* but your first script looks a bit wrong because first you set the IP address, then later you run dhclient - which under many situations will simply rewrite your IP address with whatever DHCP picks up. dhclient should not be necessary if you want to statically write your ip address this way.
Your OpenRC config - just to make sure, you're using the wl0p2s5junk instead of _wireless or _wlan0 or _<essid> (depending on what persistent device name you got from udev)?
* Most of the time I use Networkmanager for OpenRC/systemd because they allow userland/gui/tui/cli network changes when roaming, and seamlessly integrates with wpa-supplicant which is needed for WPA/WPA2. Using the static keys and WEP, though insecure, does not require the use of wpa-supplicant (though it handles it too).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Fri Jul 24, 2015 8:31 pm Post subject: |
|
|
| eccerr0r wrote: | | I don't remember exactly how to set up OpenRC wireless directly* but your first script looks a bit wrong because first you set the IP address, then later you run dhclient - which under many situations will simply rewrite your IP address with whatever DHCP picks up. dhclient should not be necessary if you want to statically write your ip address this way. |
So how do you connect without running dhclient then? Surely you need to enter some command to connect?
| Quote: | | Your OpenRC config - just to make sure, you're using the wl0p2s5junk instead of _wireless or _wlan0 or _<essid> (depending on what persistent device name you got from udev)? |
| Code: |
modules="iwconfig"
config_Wireless<last_name>="192.168.0.6/24 brd 192.168.0.255"
routes_Wireless<last_name>="default via 192.168.0.1"
key_Wireless<last_name>="[1] <key_cut> key [1] enc open"
dns_servers="8.8.8.8 8.8.4.4" |
Where Wireless<last_name> is the ESSID to my network.
| Quote: | | * Most of the time I use Networkmanager for OpenRC/systemd because they allow userland/gui/tui/cli network changes when roaming, and seamlessly integrates with wpa-supplicant which is needed for WPA/WPA2. Using the static keys and WEP, though insecure, does not require the use of wpa-supplicant (though it handles it too). |
hmm, I didn't know WPA_supplicant also did WEP, maybe I should just check that out then? |
|
| Back to top |
|
|
Buffoon
Veteran
Joined: 17 Jun 2015
Posts: 1369
Location: EU or US
|
| Posted: Fri Jul 24, 2015 8:45 pm Post subject: |
|
|
DHCP does not connect you, it is merely a configuration helper, it will get you an IP address, DNS, timezone, NTP, etc. All that can be set manually.
_________________
Life is a tragedy for those who feel and a comedy for those who think. |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Fri Jul 24, 2015 9:11 pm Post subject: |
|
|
| Buffoon wrote: | | DHCP does not connect you, it is merely a configuration helper, it will get you an IP address, DNS, timezone, NTP, etc. All that can be set manually. |
Yeah, I just figured that out, so for the last 4 years or so I believed for whatever reason that dhclient establishes the final connexion. Seems like a weird idea to not have to input a command to connect.
In case anyone is wondering:
| Code: |
ifconfig "$iface" down &&
ifconfig "$iface" up &&
ifconfig "$iface" "$ip" &&
ifconfig "$iface" netmask 255.255.255.0 &&
ifconfig "$iface" broadcast "$subnet.255" &&
route add default gw "$subnet.1" "$iface" &&
iwconfig "$iface" essid "$essid" key "$key"
|
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Fri Jul 24, 2015 11:54 pm Post subject: |
|
|
Yes, at least for static key WEP and unprotected WiFi, you do not need any commands. Just set the ESSID, keys, and mode (managed/adhoc) and you're connected. With WPA you need the supplicant but you can use the supplicant with WEP too.
I'll have to check on my lone static openrc wifi config later (with WPA), forgot how I did it. That machine is not a laptop (and only has 64MB RAM) so I saved memory by not using networkmanager, which would have not bought me anything anyway since it would never roam (and has no user interface at all other than ssh or serial!). I could have sworn that I specified the interface name, not SSID, in the config_xxxxx= lines. Though I do have to use wpa-supplicant because I use WPA, so config might be slightly different...
https://wiki.gentoo.org/wiki/Wpa_supplicant
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jul 25, 2015 8:01 am Post subject: |
|
|
Just a remark: Do not spend too much time with "iwconfig". It uses a deprecated kernel interface ("wireless extensions") and so it is possible that quite soon it will not work anymore with current kernels. AFAIK there are no plans to update iwconfig; AFAIK iw can be used as a successor.
Another remark: I hope that you are aware that WEP or unprotected Wifi are usually not a good idea for security reasons. That's why many people use wpa_supplicant for a static setup. |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Sat Jul 25, 2015 9:45 am Post subject: |
|
|
| Yeah, I know the problems with WEP but I doubt my neighbours are out to decrypt me. The major reason I use this old system is because I don't know how to write a simple script that just connects when you run it. All literature I found on WPA_supplicant implies some kind of startup daemon and some fancy configuration file or some GUI or ncurses GUI. I just want a simple script that takes four arguments, the essid, the keyphrase, the ip address of the gateway and the address my computer is going to get. Not sure if that is possible at all wpa_supplicant, if it is then the internet hasn't taught me yet. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Sat Jul 25, 2015 4:23 pm Post subject: |
|
|
| mi_unixbird wrote: | | The major reason I use this old system is because I don't know how to write a simple script that just connects when you run it. |
So why not use dhcpcd with wpa_supplicant? |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Sat Jul 25, 2015 4:41 pm Post subject: |
|
|
I'm more worried about drive-bys than neighbors.
In any case wpa_supplicant needs to be running before dhcpcd, whether there's a wrapper or not doesn't matter. Yes the supplicant needs to be running in the background to handle dynamic key changing and there's no way around that, but the config file is not much different than any other OpenRC config (compared to something like sendmail.cf.)
In fact all my wpa_supplicant.conf is something like this:
| Code: | country=US
ap_scan=1
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
ssid="MySSID"
scan_ssid=1
key_mgmt=WPA-PSK
psk="MyPresharedKey"
} |
That's not that difficult... You can even add more network={} sections and wpa-supplicant will switch between wifi SSID as needed.
My /etc/conf.d/net actually is empty, but I use DHCP to autoconfigure the IP address. But to configure a static IP I'd have something like this there:
| Code: | config_wlp0s18="10.0.0.2/24"
routes_wlp0s18="default by 10.0.0.1"
|
OpenRC automatically sets up everything else for you.
I do want to add that most of my laptops, etc. I do NOT do this. The configuration I allude here is a single board computer that has 64MB RAM and no monitor or keyboard. My machines running X11 I use Networkmanager on all of them because it's much more convenient to switch. OpenRC by itself does a poor job when roaming that I've found, at least when I switch from wireless to wired or vice versa, usually leaves you with a dead connection without manual intervention. Networkmanager will switch links for you automatically.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Sat Jul 25, 2015 5:34 pm Post subject: |
|
|
| charles17 wrote: | | mi_unixbird wrote: | | The major reason I use this old system is because I don't know how to write a simple script that just connects when you run it. |
So why not use dhcpcd with wpa_supplicant? |
Mostly because it needs some config file again which is not what I want really. I just want to enter a command to connect to the network instead of some fancy daemon at whatever OpenRC runlevel.
If there's a way you know to rig a script with wpa_supplicant / DHCPCD that just takes four arguments: the essid, the passphrase, the ip I want of the machine and the ip of gateway and then exit with 0 on connexion then I'll take it, not sure if it's possible, I tried to search but couldn't find anything. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Sun Jul 26, 2015 6:09 am Post subject: |
|
|
| mi_unixbird wrote: | | Mostly because it needs some config file again which is not what I want really. |
Only config files it needs are /etc/wpa_supplicant/wpa_supplicant.conf and /etc/dhcpcd.conf.
| mi_unixbird wrote: | I just want to enter a command to connect to the network instead of some fancy daemon at whatever OpenRC runlevel.
If there's a way you know to rig a script with wpa_supplicant / DHCPCD that just takes four arguments: the essid, the passphrase, the ip I want of the machine and the ip of gateway and then exit with 0 on connexion then I'll take it, not sure if it's possible, I tried to search but couldn't find anything. |
Maybe not exactly what you want, but did you check dhcpcd-ui and wpa_cli? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 26, 2015 6:44 am Post subject: |
|
|
| mi_unixbird wrote: | | Mostly because it needs some config file again which is not what I want really. |
Why not? I really do not understand what is the problem of a config file. If you do not want to override the system-wide config file, you can probably specify another one by a command line argument; maybe it will even accept a shell here-script as argument (I did try neither).
Concerning having a daemon running: I really do not know much about the WPA protocoll, but the kernel's philosophy was always to push as much implmentation as possible to the user space. So I can imagine that the daemon is essentially needed for decryption/encryption or at least updating some changing session keys after certain periods. Probably an expert could tell you more. Also here, I do not understand why you want to avoid the daemon in the first place (if the protocol really requires it). |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Sun Jul 26, 2015 1:11 pm Post subject: |
|
|
| mv wrote: | | mi_unixbird wrote: | | Mostly because it needs some config file again which is not what I want really. |
Why not? I really do not understand what is the problem of a config file. If you do not want to override the system-wide config file, you can probably specify another one by a command line argument; maybe it will even accept a shell here-script as argument (I did try neither).
Concerning having a daemon running: I really do not know much about the WPA protocoll, but the kernel's philosophy was always to push as much implmentation as possible to the user space. So I can imagine that the daemon is essentially needed for decryption/encryption or at least updating some changing session keys after certain periods. Probably an expert could tell you more. Also here, I do not understand why you want to avoid the daemon in the first place (if the protocol really requires it). |
Couple of philosophical and practical reasons why I am opposed to config files for this.
- It keeps this information on the filesystem, someone might take your drive out and get it
- It's just impractical when you are on a foreign network to first edit a configuration file with all its syntax before you can connect rather than just type a command and connect
- I do not like the idea of networking just starting at boot, I like to enter a command and start it, though this is also possible with a config file, if you enter this command you might as well just pass the credentials to it
- Simply executing a command allows someone who wants a config file to easily rig that for herself, not so much in reverse.
Basically, a wireless key is like a login password. You think it's a good idea to force people to log in to forums.gentoo.org by forcing them to make a config file and having them log in at boot rather than just allowing them to log in manually? If they want a config file and log in at boot, they can rig their own super simple primitive init script that just executes the command reading their own config file. Keep it simple, stupid. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 26, 2015 1:53 pm Post subject: |
|
|
| mi_unixbird wrote: | | - It keeps this information on the filesystem, someone might take your drive out and get it |
The init-file is on the file-system as well; I do not see the difference. If you do not like the place at /etc use a symlink (that's actually what I do for config-files with sensitive data).
| Quote: | | - It's just impractical when you are on a foreign network to first edit a configuration file |
If you have a machine which you move to foreign networks every static setup is impractical. In such cases, one has to use something like network-manager, anyway.
Also your other points - entering the password "on the fly" - look that you should use something like network-manager.
Unfortunately, network-manager is broken (a gnome-polcykit moloch), and I do not yet know a good replacement for it.
Anyway, you can of course create a config-file on the fly in /run, for instance.
| Quote: | | Basically, a wireless key is like a login password. |
What you currently do (WEP or unencrypted) is like having an empty or no password. Everything is better than that. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jul 26, 2015 3:43 pm Post subject: |
|
|
| mi_unixbird wrote: | | Couple of philosophical and practical reasons why I am opposed to config files for this. |
mi_unixbird ... none of which are particularly compelling ...
| mi_unixbird wrote: | | - It keeps this information on the filesystem, someone might take your drive out and get it |
Yes, that is a possibility, but someone gaining physical access to the machine would be far less likely than someone sniffing the airwaves, breaking WEP (trivial), and so getting the passphrase. The contents of the hardisk can be protected via encryption to prevent such access to config files, the case and/or machine can be locked/secured, the security of the authentication/transmission improved by the use of WPA2, WPS disabled on the router, etc, etc. Security isn't a switch that's either on or off, its a series of layers.
| mi_unixbird wrote: | | - It's just impractical when you are on a foreign network to first edit a configuration file with all its syntax before you can connect rather than just type a command and connect |
Well no, because most networks will be using WPA/RSN, and so a supplicant/authenticator is required, that is simply an unavoidable fact regarding wireless ... and wpa_supplicant is the only method of WPA authentication. That said, it isn't that impractical ... a config entry needs one or two parameters, and a config file needn't be edited directly, the script you envisage could as well be creating such entries.
| mi_unixbird wrote: | | - I do not like the idea of networking just starting at boot, I like to enter a command and start it, though this is also possible with a config file, if you enter this command you might as well just pass the credentials to it |
Neither do I, but openrc allows for networks to be configured based on runlevel, and these runlevels are very flexible. I can switch between networks (with all manner of specific setups for these networks) by simply issuing "rc <runlevel>". If I need to do something not currently configured its trivial to replicate a particular setup and create a profile for that particular situation. Its also possible using wpa_cli, ip, iw, dhcpcd, shell/history, etc, to quickly add/configure some setup if needed.
| mi_unixbird wrote: | | - Simply executing a command allows someone who wants a config file to easily rig that for herself, not so much in reverse. |
That doesn't really make sense ... if by "in reverse" you mean "undo" it isn't such an issue, besides 99% of network setups are not one time only, they are generally reused.
| mi_unixbird wrote: | | Basically, a wireless key is like a login password. You think it's a good idea to force people to log in to forums.gentoo.org by forcing them to make a config file and having them log in at boot rather than just allowing them to log in manually? If they want a config file and log in at boot, they can rig their own super simple primitive init script that just executes the command reading their own config file. Keep it simple, stupid. |
The difference is that for a secure WPA2 key you should be using a 63 char randomish string, these are not memorable and so most humans need to have some method of storing them. For f.g.o most people will be using their browser to store such passphrases, and so, again, a config file. As for your last point I'm not sure I understand the scenario you're suggesting.
Anyhow, if you're set on such a method then I'm sure something of this nature can be scripted ... the following (untested) might provide a starting point:
| Code: | #!/bin/sh
iface=wlan0
if ! wpa_cli ping >/dev/null ; then
wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant/wpa_supplicant.conf -i$iface -q &
else
for i in $(wpa_cli -i$iface list_networks | awk '/^[0-9]/{print $2}') ; do wpa_cli -i$iface remove_network $i; done
fi
wpa_cli -i$iface add_network
wpa_cli -i$iface set_network 0 auth_alg OPEN
wpa_cli -i$iface set_network 0 key_mgmt WPA-PSK
wpa_cli -i$iface set_network 0 psk "$pass"
wpa_cli -i$iface set_network 0 proto RSN
wpa_cli -i$iface set_network 0 mode 0
wpa_cli -i$iface set_network 0 ssid "$ssid"
wpa_cli -i$iface select_network 0
wpa_cli -i$iface enable_network 0
wpa_cli -i$iface reassociate
timeout="15"
while { [ $timeout -gt 0 ] && [ -z "$(wpa_cli -i$iface status | grep '^wpa_state=COMPLETED')" ]; } ; do
sleep 1
: $(( timeout -= 1 ))
done
if [ $timeout -eq 0 ] && [ -z "$(wpa_cli -i$iface status | grep '^wpa_state=COMPLETED')" ] ; then
echo "Connection failed"
exit 1
fi
dhcpcd $iface |
There are a number of foreseeable issues with the above, like the quoting of "$ssid" and "$pass", and the required 'proto' ... but as I said its a starting point.
HTH & best ... khay |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Sun Jul 26, 2015 5:17 pm Post subject: |
|
|
| khayyam wrote: |
Yes, that is a possibility, but someone gaining physical access to the machine would be far less likely than someone sniffing the airwaves, breaking WEP (trivial), and so getting the passphrase. The contents of the hardisk can be protected via encryption to prevent such access to config files, the case and/or machine can be locked/secured, the security of the authentication/transmission improved by the use of WPA2, WPS disabled on the router, etc, etc. Security isn't a switch that's either on or off, its a series of layers. |
This is not a criticism on the process by which I connect but the flaws in WEP.
| Quote: |
Well no, because most networks will be using WPA/RSN, and so a supplicant/authenticator is required, that is simply an unavoidable fact regarding wireless ... and wpa_supplicant is the only method of WPA authentication. That said, it isn't that impractical ... a config entry needs one or two parameters, and a config file needn't be edited directly, the script you envisage could as well be creating such entries. |
I disagree, it's _super_ annoying to have to scroll through a config file in a terminal-based editor (or run a GUI application as root) to edit those config files for a single connexion. A config file should be edited for something staying up long, a single thing should not "save settings", this system forces you to save settings when you don't or otherwise manually delete them afterwards.
| Quote: |
| mi_unixbird wrote: | | - Simply executing a command allows someone who wants a config file to easily rig that for herself, not so much in reverse. |
That doesn't really make sense ... if by "in reverse" you mean "undo" it isn't such an issue, besides 99% of network setups are not one time only, they are generally reused. |
No, by reverse I mean transforming something that needs a config file into something that can just be done with a command.
If it can be done with a command and arguments you can easily transform it into a config file by reading the config file and passing the arguments, in reverse that's harder and requires you to rig a script that temporarily creates a config file and then deletes it when it's safe, but how does it know when it is safe?
| Quote: | | mi_unixbird wrote: | | Basically, a wireless key is like a login password. You think it's a good idea to force people to log in to forums.gentoo.org by forcing them to make a config file and having them log in at boot rather than just allowing them to log in manually? If they want a config file and log in at boot, they can rig their own super simple primitive init script that just executes the command reading their own config file. Keep it simple, stupid. |
The difference is that for a secure WPA2 key you should be using a 63 char randomish string, these are not memorable and so most humans need to have some method of storing them. For f.g.o most people will be using their browser to store such passphrases, and so, again, a config file. As for your last point I'm not sure I understand the scenario you're suggesting. |
Well, memorizing and inputting 63 chars is still less inconvenient than editing a config file for a single connexion, especially because you to place that string into the config file anyway.
| Quote: |
Anyhow, if you're set on such a method then I'm sure something of this nature can be scripted ... the following (untested) might provide a starting point:
| Code: | #!/bin/sh
iface=wlan0
if ! wpa_cli ping >/dev/null ; then
wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant/wpa_supplicant.conf -i$iface -q &
else
for i in $(wpa_cli -i$iface list_networks | awk '/^[0-9]/{print $2}') ; do wpa_cli -i$iface remove_network $i; done
fi
wpa_cli -i$iface add_network
wpa_cli -i$iface set_network 0 auth_alg OPEN
wpa_cli -i$iface set_network 0 key_mgmt WPA-PSK
wpa_cli -i$iface set_network 0 psk "$pass"
wpa_cli -i$iface set_network 0 proto RSN
wpa_cli -i$iface set_network 0 mode 0
wpa_cli -i$iface set_network 0 ssid "$ssid"
wpa_cli -i$iface select_network 0
wpa_cli -i$iface enable_network 0
wpa_cli -i$iface reassociate
timeout="15"
while { [ $timeout -gt 0 ] && [ -z "$(wpa_cli -i$iface status | grep '^wpa_state=COMPLETED')" ]; } ; do
sleep 1
: $(( timeout -= 1 ))
done
if [ $timeout -eq 0 ] && [ -z "$(wpa_cli -i$iface status | grep '^wpa_state=COMPLETED')" ] ; then
echo "Connection failed"
exit 1
fi
dhcpcd $iface |
There are a number of foreseeable issues with the above, like the quoting of "$ssid" and "$pass", and the required 'proto' ... but as I said its a starting point.
HTH & best ... khay |
Well, that's my point, I don't see what half of those things do because it's overcomplicated by design. To make a simple connexion you need to weed through entire pages of manuals to understand how it works. A lot of these newer Unix tools completely abanonded KISS to the point where some of these "plan text" config files are so complicated they have to be generated by a computer program from simpler config files. I just want a simple command to connect to the internet that I can put in a script. If I need to set up some timer to connect to the itnernet at a specific time to allow my daughter to serve when I'm not home for a set time. How am I going to do this with these super advanced config files. The script would have to generate a file and promptly delete it afterwards and it would store the file inside the script anyway. It's overcomplicated, I want something simple. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jul 26, 2015 8:07 pm Post subject: |
|
|
| mi_unixbird wrote: | | khayyam wrote: | | Yes, that is a possibility, but someone gaining physical access to the machine would be far less likely than someone sniffing the airwaves, breaking WEP (trivial), and so getting the passphrase. The contents of the hardisk can be protected via encryption to prevent such access to config files, the case and/or machine can be locked/secured, the security of the authentication/transmission improved by the use of WPA2, WPS disabled on the router, etc, etc. Security isn't a switch that's either on or off, its a series of layers. |
This is not a criticism on the process by which I connect but the flaws in WEP. |
mi_unixbird ... it was a criticism of your reasoning, you had said that by having a config it might be read should someone gain access to the HD, but by using WEP (as you do) this capability is made easier as no physical access is needed, the pass can be captured, and easily decrypted, via the airwaves.
| mi_unixbird wrote: | | khayyam wrote: | | Well no, because most networks will be using WPA/RSN, and so a supplicant/authenticator is required, that is simply an unavoidable fact regarding wireless ... and wpa_supplicant is the only method of WPA authentication. That said, it isn't that impractical ... a config entry needs one or two parameters, and a config file needn't be edited directly, the script you envisage could as well be creating such entries. |
I disagree, it's _super_ annoying to have to scroll through a config file in a terminal-based editor (or run a GUI application as root) to edit those config files for a single connexion. A config file should be edited for something staying up long, a single thing should not "save settings", this system forces you to save settings when you don't or otherwise manually delete them afterwards. |
No, it doesn't "force you to save settings", you can use wpa_cli and configure a "single connection" and as long as 'save_config' isn't run nothing will be saved. I showed you how that might be scripted for a one time connection similar to the script you've been using.
| mi_unixbird wrote: | | khayyam wrote: | | mi_unixbird wrote: | | - Simply executing a command allows someone who wants a config file to easily rig that for herself, not so much in reverse. |
That doesn't really make sense ... if by "in reverse" you mean "undo" it isn't such an issue, besides 99% of network setups are not one time only, they are generally reused. |
No, by reverse I mean transforming something that needs a config file into something that can just be done with a command. If it can be done with a command and arguments you can easily transform it into a config file by reading the config file and passing the arguments, in reverse that's harder and requires you to rig a script that temporarily creates a config file and then deletes it when it's safe, but how does it know when it is safe? |
I'm not entirely sure of what you're saying, anyhow, as I said, it isn't an issue ... anything that wpa_supplicant.conf provides can be supplied via wpa_cli ... so without need of a config file, or the need for a "temporary config file". In short, wpa_supplicant doesn't force you to do anything, the use of a config file is simply a matter of them providing the most obvious method of storing such configuration ... again, for reasons that passphrases are generally not memorable, and for configuring differing types of authentication (WPA_PSK, EAP, IEEE 802.1x, etc).
| mi_unixbird wrote: | | khayyam wrote: | | mi_unixbird wrote: | | Basically, a wireless key is like a login password. [....] Keep it simple, stupid. |
The difference is that for a secure WPA2 key you should be using a 63 char randomish string, these are not memorable and so most humans need to have some method of storing them. For f.g.o most people will be using their browser to store such passphrases, and so, again, a config file. As for your last point I'm not sure I understand the scenario you're suggesting. |
Well, memorizing and inputting 63 chars is still less inconvenient than editing a config file for a single connexion, especially because you to place that string into the config file anyway. |
Nonsense ... and the conclusion doesn't follow from the premise. If its a "single connection" there is no memorising of the key, unless you just happen to have these things memorised on the off chance you might happen to connect to such a network. Even if it were a one time deal, a secure key of 63 chars isn't trivial to type correctly, let alone memorise. Also, as I showed, there is no need for the psk to be in a config file.
| mi_unixbird wrote: | | khayyam wrote: | Anyhow, if you're set on such a method then I'm sure something of this nature can be scripted ... the following (untested) might provide a starting point:
[...] |
Well, that's my point, I don't see what half of those things do because it's overcomplicated by design. To make a simple connexion you need to weed through entire pages of manuals to understand how it works. A lot of these newer Unix tools completely abanonded KISS to the point where some of these "plan text" config files are so complicated they have to be generated by a computer program from simpler config files. I just want a simple command to connect to the internet that I can put in a script. If I need to set up some timer to connect to the itnernet at a specific time to allow my daughter to serve when I'm not home for a set time. How am I going to do this with these super advanced config files. The script would have to generate a file and promptly delete it afterwards and it would store the file inside the script anyway. It's overcomplicated, I want something simple. |
No, that isn't "your point", your making claims about "complexity", and violations of KISS, ignoring the fact that these tools offer features that are necessary, how do you make EAP, or 802.1x, authentication without the tool providing some method to do so? EAP is part of the 802.11 specification, so the tool needs to support these features, no violation of KISS is involved. If anything wpa_supplicant conforms to KISS because it supports the specification via numerous methods (ie, via the commandline, and so scriptable, via the reading of a config file, etc, etc). Not everyone is using wpa_supplicant in the "simple" manner you expect, connections can be client like (WEP, WPA-PSK, EAP, 802.1x), ad hoc, P2P, AP ... and wpa_supplicant needs to support all these ... "by design". The idea of KISS is not that no understanding is needed, but that with understanding the most complex of needs can be met. Your criticism really comes down to it not meeting your standard of what it should be doing to meet those needs, but that isn't a problem with the program, but with your applying what the program provides to your problem.
best ... khay |
|
| Back to top |
|
|
mi_unixbird
Tux's lil' helper
Joined: 24 Jul 2015
Posts: 118
|
| Posted: Sun Jul 26, 2015 9:26 pm Post subject: |
|
|
| khayyam wrote: | | mi_unixbird wrote: | | khayyam wrote: | | Yes, that is a possibility, but someone gaining physical access to the machine would be far less likely than someone sniffing the airwaves, breaking WEP (trivial), and so getting the passphrase. The contents of the hardisk can be protected via encryption to prevent such access to config files, the case and/or machine can be locked/secured, the security of the authentication/transmission improved by the use of WPA2, WPS disabled on the router, etc, etc. Security isn't a switch that's either on or off, its a series of layers. |
This is not a criticism on the process by which I connect but the flaws in WEP. |
mi_unixbird ... it was a criticism of your reasoning, you had said that by having a config it might be read should someone gain access to the HD, but by using WEP (as you do) this capability is made easier as no physical access is needed, the pass can be captured, and easily decrypted, via the airwaves. |
No, that reasoning assumes I'm actually on those airwaves transmitting at that point. What if I'm 500 km away from my router on a completely different place and somewhat gets access to my filesystem?
| Quote: |
No, it doesn't "force you to save settings", you can use wpa_cli and configure a "single connection" and as long as 'save_config' isn't run nothing will be saved. I showed you how that might be scripted for a one time connection similar to the script you've been using. |
Yes, and that script was super complicated. I could not understand what it was doing at first glance and I'd have to read long manuals to figure it out.
Luckily, it turns out that despite all the documentation not telling me. wpa_cli has a non interactive mode as well which solves all my problems and I am now in WPA. Turns out that:
| Code: |
echo setting ssid...
wpa_cli set_network 0 ssid $sid
echo setting psk...
wpa_cli set_network 0 pask $psk
echo enabling connexion...
wpa_cli enable_network 0
|
Which is exactly the kiss principle of which I spoke, it's dead simple, easy to understand immediately when reading it and does not require the use of extensive documentation to get going. Why I had to weed inside extensive documentation to find out that wpa_cli also had this option instead of the interactive mode, bugger if I know.
| Quote: |
I'm not entirely sure of what you're saying, anyhow, as I said, it isn't an issue ... anything that wpa_supplicant.conf provides can be supplied via wpa_cli ... so without need of a config file, or the need for a "temporary config file". In short, wpa_supplicant doesn't force you to do anything, the use of a config file is simply a matter of them providing the most obvious method of storing such configuration ... again, for reasons that passphrases are generally not memorable, and for configuring differing types of authentication (WPA_PSK, EAP, IEEE 802.1x, etc). |
Quite, I know now that wpa_cli can run in command line mode instead of interactive mode, which none of the documentation of the Gentoo and Achwiki made clear implying you had to run it in interactive mode which is not something you can easily hook a script up to.
| Quote: | | No, that isn't "your point", your making claims about "complexity", and violations of KISS, ignoring the fact that these tools offer features that are necessary, how do you make EAP, or 802.1x, authentication without the tool providing some method to do so? EAP is part of the 802.11 specification, so the tool needs to support these features, no violation of KISS is involved. If anything wpa_supplicant conforms to KISS because it supports the specification via numerous methods (ie, via the commandline, and so scriptable, via the reading of a config file, etc, etc). Not everyone is using wpa_supplicant in the "simple" manner you expect, connections can be client like (WEP, WPA-PSK, EAP, 802.1x), ad hoc, P2P, AP ... and wpa_supplicant needs to support all these ... "by design". The idea of KISS is not that no understanding is needed, but that with understanding the most complex of needs can be met. Your criticism really comes down to it not meeting your standard of what it should be doing to meet those needs, but that isn't a problem with the program, but with your applying what the program provides to your problem. |
Well, apparently, they don't need it because that script I rigged above worked which is no more complex than what I used for the WEP key and a lot less complex than what you rigged.
That script I rigged can be understood by anyone who has never worked with wpa_cli before, it's self explanatory, it's simple. Your script is extremely complicated without knowledge of how it works and I couldn't make out at all what it was doing, it's also 5 times as long. That's what I mean when I want a KISS interface and it's totally possible apparently. Yes, a complex interface is needed when you're doing complicated things, but what I was doing isn't complicated at all and a simple interface should exist to do it, and guess what, it does. And apparently it's so obscure that the archwiki, gentoo wiki, and people on this forum didn't mention the obvious solution. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Jul 27, 2015 1:39 am Post subject: |
|
|
| mi_unixbird wrote: | | khayyam wrote: | | [...] it was a criticism of your reasoning, you had said that by having a config it might be read should someone gain access to the HD, but by using WEP (as you do) this capability is made easier as no physical access is needed, the pass can be captured, and easily decrypted, via the airwaves. |
No, that reasoning assumes I'm actually on those airwaves transmitting at that point. What if I'm 500 km away from my router on a completely different place and somewhat gets access to my filesystem? |
mi_unixbird ... that logic is flawed, regardless of where you are in relation to the HD it doesn't limit the extent to which the use of WEP provides a method of ingress. The fact that your HD *could* be accessed is besides the point, it's far easier, or more probable, that traffic on the airwaves be sniffed and decrypted than someone break into your home, take the HD, and be able to read said config file.
| mi_unixbird wrote: | | khayyam wrote: | | No, it doesn't "force you to save settings", you can use wpa_cli and configure a "single connection" and as long as 'save_config' isn't run nothing will be saved. I showed you how that might be scripted for a one time connection similar to the script you've been using. |
Yes, and that script was super complicated. I could not understand what it was doing at first glance and I'd have to read long manuals to figure it out. Luckily, it turns out that despite all the documentation not telling me. wpa_cli has a non interactive mode as well which solves all my problems and I am now in WPA. |
The script contained some logic to check that wpa_supplicant was running, that any configured networks were removed, that the connection was given time to complete before running dhcp, etc, etc ... basically stuff you do to cover for contingencies. It's perfectly correct to try and cope with such things, but I can only read the above as something of a slight, as after providing you with something which was actually fairly good, for you it isn't good enough ... which is, quite frankly, insulting.
As for you having to read the documentation, well, its obvious from my script that I'm using wpa_cli non-interactively.
| mi_unixbird wrote: | | Which is exactly the kiss principle of which I spoke, it's dead simple, easy to understand immediately when reading it and does not require the use of extensive documentation to get going. Why I had to weed inside extensive documentation to find out that wpa_cli also had this option instead of the interactive mode, bugger if I know. |
That fact should have been obvious from my having used wpa_cli in the script. Honestly, after having provided my time you're now complaining that it wasn't simple enough for you to understand. Sorry, that is not how this works, I don't make any assumptions about your skill level, and you shouldn't be making such ungrateful comments about what I provided. If its wrong in some way, fine, but its basically correct, you just don't like it simply because you don't understand it ... which is not a valid criticism.
| mi_unixbird wrote: | | khayyam wrote: | | I'm not entirely sure of what you're saying, anyhow, as I said, it isn't an issue ... anything that wpa_supplicant.conf provides can be supplied via wpa_cli ... so without need of a config file, or the need for a "temporary config file". In short, wpa_supplicant doesn't force you to do anything, the use of a config file is simply a matter of them providing the most obvious method of storing such configuration ... again, for reasons that passphrases are generally not memorable, and for configuring differing types of authentication (WPA_PSK, EAP, IEEE 802.1x, etc). |
Quite, I know now that wpa_cli can run in command line mode instead of interactive mode, which none of the documentation of the Gentoo and Achwiki made clear implying you had to run it in interactive mode which is not something you can easily hook a script up to. |
The fact that I used it non-interactively shows that to be the case, so I'm not sure why you're now using this as somehow a counter to the point I'm making above.
| mi_unixbird wrote: | | khayyam wrote: | | No, that isn't "your point", your making claims about "complexity", and violations of KISS, ignoring the fact that these tools offer features that are necessary, how do you make EAP, or 802.1x, authentication without the tool providing some method to do so? EAP is part of the 802.11 specification, so the tool needs to support these features, no violation of KISS is involved. If anything wpa_supplicant conforms to KISS because it supports the specification via numerous methods (ie, via the commandline, and so scriptable, via the reading of a config file, etc, etc). Not everyone is using wpa_supplicant in the "simple" manner you expect, connections can be client like (WEP, WPA-PSK, EAP, 802.1x), ad hoc, P2P, AP ... and wpa_supplicant needs to support all these ... "by design". The idea of KISS is not that no understanding is needed, but that with understanding the most complex of needs can be met. Your criticism really comes down to it not meeting your standard of what it should be doing to meet those needs, but that isn't a problem with the program, but with your applying what the program provides to your problem. |
Well, apparently, they don't need it because that script I rigged above worked which is no more complex than what I used for the WEP key and a lot less complex than what you rigged. |
You're not really responding to what I'd written ... you're simply providing a "mine is better than yours" argument (out of context) to show what ... I don't know ... you're ungrateful that I took the time to respond to you.
| mi_unixbird wrote: | | That script I rigged can be understood by anyone who has never worked with wpa_cli before, it's self explanatory, it's simple. Your script is extremely complicated without knowledge of how it works and I couldn't make out at all what it was doing, it's also 5 times as long. That's what I mean when I want a KISS interface and it's totally possible apparently. Yes, a complex interface is needed when you're doing complicated things, but what I was doing isn't complicated at all and a simple interface should exist to do it, and guess what, it does. And apparently it's so obscure that the archwiki, gentoo wiki, and people on this forum didn't mention the obvious solution. |
You're incorrigible ... you're arguing that by involving less logic, being shorter, or whatever, its better. The problem is your making that judgement "without knowledge of how it works" which, regardless of the facts, is actually damning me for having provided you with my time, expertise, etc, even though you're not qualified to judge the script I provided. Oiiiiii |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
