<int_ua> oh snap! No hidden network configuration in wifi-menu :(
<Skry> "hidden" wlans are nonsense. regardless, if you only have one network you need, don't bother with wifi-menu, just create profile for netcfg, it's more straightforward and handles the hidden network too.
<int_ua> do you mean nonsense for security considerations?
<int_ua> Thanks, doing that :)
<Skry> only thing it does is make connecting more complicated for _you_, and security benefits are zero
<int_ua> doesn't it save some energy?
<Skry> that I do not know
<Sicelo> :P
<Sicelo> it doesn't
<int_ua> what problem does it solves then?
<Skry> nothing
<int_ua> s/solves/solve/
<Sicelo> placebo effect. false sense of security
<Skry> yup
<int_ua> if it was created someone must have been thinking about some problem...
<Skry> probably marketing trick
<Sicelo> they were thinking about security
<Sicelo> and it never materialized :P
<int_ua> Actually, I was thinking that in non-hidden mode it beams it's name every n seconds, doesn't it?
<Sicelo> beacon is there whether or not name is broadcast
<int_ua> for what reason?
<int_ua> if not for the name
<Sicelo> to kepp connected devices connected
<int_ua> what if there are none?
<Sicelo> new devices must also find the AP
<Sicelo> if it doesn't say that it's there, how are devices going to find it?
<int_ua> client SSID query? Just found it in wiki
<int_ua> from wiki: "hiding the access point's name by disabling the SSID broadcast."
<Pali> hidden wifi networks do not broadcast ssid and I think this can save power for some cards...
<Sicelo> int_ua: you're aware SSID is the name? :P
<int_ua> yes, of course :)
<int_ua> do you mean "How clients are gonna get MAC"?
<int_ua> Pali: I cannot find anything about it on google, any suggestions?
<Sicelo> no. they have to know that there's a live AP around, right?
<int_ua> Sicelo: isn't it better for AP to wait for a request instead of continuously beaming that it's alive?
<Sicelo> then how do you associate a new device, even if you knew the name? :P
<Pali> look at hostap: http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf
<Pali> key ignore_broadcast_ssid
<Pali> * send empty (length=0) SSID in beacon and ignore probe request for broadcast SSID
<Pali> * clear SSID (ASCII 0), but keep the original length (this may be required with some clients that do not support empty SSID) and ignore probe requests for broadcast SSID
<Sicelo> int_ua: you've probably seen that your N900 actually does 'know' about the existence of a hidden SSID AP
<Pali> there are two modes of "hidden" ssid
<Pali> you can scan for wifi APs (BSSIDs)
<Pali> but if AP will not send SSID in beacon you do not know SSID
<Sicelo> thus, the power-saving benefit of hidden-SSID is negligible as beacon is still sent (albeit modified, as Pali just showed the details)
<Pali> hm, yes, right
<Pali> so "hiding" network is good only if you do not want to show that your wifi network XYZ exists
<int_ua> yes, the beacons are sent anyway :( http://blogs.technet.com/b/networking/archive/2008/02/08/non-broadcast-wireless-ssids-why-hidden-wireless-networks-are-a-bad-idea.aspx
<Sicelo> nice analogy, lol
<int_ua> :) But I still think that this beacons could be avoided by making the client initiate the connection.
<Sicelo> how will client know that there's an AP?
<int_ua> this analogy is security-centered while I'm trying to think energy-wise
<Pali> Sicelo, you know that there is AP with BSSID
<Pali> you can store BSSID to client
<Sicelo> yes
<int_ua> Sicelo: 0. AP waits until client sends request for all available APs. 1. APs are sending the response.
<int_ua> 3. Client gets all the info and selects the needed AP.
<Pali> if client tryting to send (hidden) SSID to all APs then it is bad implementation
<Pali> (in that article all windows doing it...)
<Sicelo> int_ua: you generally want to save power on the client rather than AP :P
<Pali> also non hidden APs must response to SSID broadcast messages
<Pali> and if you have problem with cheap hw/ap somebody can crash your hw/ap or make it slow...
<int_ua> Sicelo: why? No, I'm trying to eradicate beaming every n seconds
<Sicelo> for what reason?
<int_ua> Sicelo: energy
<int_ua> Pali: can't it be done with current standard?
<Sicelo> heh. well, it's an idea
<int_ua> Pali: there are requests that need answer anyway, aren't there?
<Pali> I do not know
<int_ua> some "client SSID query"? I don't yet understand what exactly is that...
<futpib> then it is about sending 'bump' on all channels
<futpib> continious scanning for available APs will eat clients' baterry
<futpib> s/baterry/battery/
<int_ua> futpib: well, I don't really like the idea of continuous scanning... But that's a good point. AFAIU it's still eating the battery, just much less.
<int_ua> what are the usages of the continuous scanning? Positioning?
<int_ua> What is the appropriate site to move this discussion?
<futpib> i dunno, simply finding available APs and connecting to them
<int_ua> superuser?
<int_ua> futpib: continuosly? :)
<futpib> well, android is a bit network-centric
<Sicelo> int_ua: i think what he meant was that having no beacons sent makes zero difference on power usage on the client
<futpib> obviously yes
<int_ua> Sicelo: on the client - maybe (what about processing all the info?), but APs still lose power on beacons
<Sicelo> int_ua: beacon not only advertises the AP, but also keeps existing connections alive when no 'data' is being transmitted. without beacons, connection would drop too frequently
<Sicelo> most times the AP is powered by AC, which is rrely the case for the client
<Sicelo> s/rrel/rarely/
<int_ua> Sicelo: yes, agreed. But what if AP sends beacons only in case of active connections present?
<int_ua> Sicelo: yes, of course, but I'm thinking about global usage, not some battery life.
<futpib> how does it work in ad-hoc mode? maybe exactly like you suggest :)
<Sicelo> ad-hoc is a bigger power-hog :P
<Sicelo> it was consuming battery power at such an alarming rate on N900 that i finally went ahead and bought an AP
<int_ua> futpib: I don't know, I lived ~2 years thinking my AP doesn't send beacons =D
<Pali> int_ua, turn wifi card to monitor mode and run wireshark
<Pali> maybe there are APs which do not send beacons...
<Pali> ...we know that implementation of wifi 802.1 is not correct on more cards/systems
<int_ua> Pali: "sudo iwconfig wlan0 mode monitor" says "Device or resource busy"
<futpib> probably bring it down first
<Pali> int_ua, first use iw (instead old deprecated iwconfig) and second: some cards cannot change mode when are up, call ip link set wlan0 down
<int_ua> filtering beacon frames...
<int_ua> tons of beacons per second from my router...
<int_ua> =(
<futpib> om nom nom
<futpib> it seems to be a wordplay in my language, sorry :(
<int_ua> futpib: well, I love wordplay, but I'm not sure I got this one. Is it more than sound of someone eating?)
<futpib> eating tons of bacon per second, wich sounds almost beacon in russian. total off-topic
<Pali> you can limit it in hostapd by "beacon_int=" config
<int_ua> futpib: another offtopic: I know russian :)
<int_ua> Pali: it's just a D-Link router even without openwrt. AFAIU I don't have hostapd on it
<int_ua> strange, I've just enabled WMM and now I can't see the beacons
<int_ua> what an offtopic day in here
<int_ua> yes, there are beacons in the hidden mode.
<Skry> offtopic is good :)
<Skry> Pali: have you booted any distro with 3.8 yet?
<Pali> Skry, only rescue OS
<int_ua> and when I go to "select connection" dialog on N900 it continuously sends "Probe request" messages according to wireshark
<Pali> and maemo bootmenu
<Pali> I fixed /bootmenu.sh to work with 3.8 kernel
<int_ua> So clients are active too
Ще цікаве посилання:<Skry> "hidden" wlans are nonsense. regardless, if you only have one network you need, don't bother with wifi-menu, just create profile for netcfg, it's more straightforward and handles the hidden network too.
<int_ua> do you mean nonsense for security considerations?
<int_ua> Thanks, doing that :)
<Skry> only thing it does is make connecting more complicated for _you_, and security benefits are zero
<int_ua> doesn't it save some energy?
<Skry> that I do not know
<Sicelo> :P
<Sicelo> it doesn't
<int_ua> what problem does it solves then?
<Skry> nothing
<int_ua> s/solves/solve/
<Sicelo> placebo effect. false sense of security
<Skry> yup
<int_ua> if it was created someone must have been thinking about some problem...
<Skry> probably marketing trick
<Sicelo> they were thinking about security
<Sicelo> and it never materialized :P
<int_ua> Actually, I was thinking that in non-hidden mode it beams it's name every n seconds, doesn't it?
<Sicelo> beacon is there whether or not name is broadcast
<int_ua> for what reason?
<int_ua> if not for the name
<Sicelo> to kepp connected devices connected
<int_ua> what if there are none?
<Sicelo> new devices must also find the AP
<Sicelo> if it doesn't say that it's there, how are devices going to find it?
<int_ua> client SSID query? Just found it in wiki
<int_ua> from wiki: "hiding the access point's name by disabling the SSID broadcast."
<Pali> hidden wifi networks do not broadcast ssid and I think this can save power for some cards...
<Sicelo> int_ua: you're aware SSID is the name? :P
<int_ua> yes, of course :)
<int_ua> do you mean "How clients are gonna get MAC"?
<int_ua> Pali: I cannot find anything about it on google, any suggestions?
<Sicelo> no. they have to know that there's a live AP around, right?
<int_ua> Sicelo: isn't it better for AP to wait for a request instead of continuously beaming that it's alive?
<Sicelo> then how do you associate a new device, even if you knew the name? :P
<Pali> look at hostap: http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf
<Pali> key ignore_broadcast_ssid
<Pali> * send empty (length=0) SSID in beacon and ignore probe request for broadcast SSID
<Pali> * clear SSID (ASCII 0), but keep the original length (this may be required with some clients that do not support empty SSID) and ignore probe requests for broadcast SSID
<Sicelo> int_ua: you've probably seen that your N900 actually does 'know' about the existence of a hidden SSID AP
<Pali> there are two modes of "hidden" ssid
<Pali> you can scan for wifi APs (BSSIDs)
<Pali> but if AP will not send SSID in beacon you do not know SSID
<Sicelo> thus, the power-saving benefit of hidden-SSID is negligible as beacon is still sent (albeit modified, as Pali just showed the details)
<Pali> hm, yes, right
<Pali> so "hiding" network is good only if you do not want to show that your wifi network XYZ exists
<int_ua> yes, the beacons are sent anyway :( http://blogs.technet.com/b/networking/archive/2008/02/08/non-broadcast-wireless-ssids-why-hidden-wireless-networks-are-a-bad-idea.aspx
<Sicelo> nice analogy, lol
<int_ua> :) But I still think that this beacons could be avoided by making the client initiate the connection.
<Sicelo> how will client know that there's an AP?
<int_ua> this analogy is security-centered while I'm trying to think energy-wise
<Pali> Sicelo, you know that there is AP with BSSID
<Pali> you can store BSSID to client
<Sicelo> yes
<int_ua> Sicelo: 0. AP waits until client sends request for all available APs. 1. APs are sending the response.
<int_ua> 3. Client gets all the info and selects the needed AP.
<Pali> if client tryting to send (hidden) SSID to all APs then it is bad implementation
<Pali> (in that article all windows doing it...)
<Sicelo> int_ua: you generally want to save power on the client rather than AP :P
<Pali> also non hidden APs must response to SSID broadcast messages
<Pali> and if you have problem with cheap hw/ap somebody can crash your hw/ap or make it slow...
<int_ua> Sicelo: why? No, I'm trying to eradicate beaming every n seconds
<Sicelo> for what reason?
<int_ua> Sicelo: energy
<int_ua> Pali: can't it be done with current standard?
<Sicelo> heh. well, it's an idea
<int_ua> Pali: there are requests that need answer anyway, aren't there?
<Pali> I do not know
<int_ua> some "client SSID query"? I don't yet understand what exactly is that...
<futpib> then it is about sending 'bump' on all channels
<futpib> continious scanning for available APs will eat clients' baterry
<futpib> s/baterry/battery/
<int_ua> futpib: well, I don't really like the idea of continuous scanning... But that's a good point. AFAIU it's still eating the battery, just much less.
<int_ua> what are the usages of the continuous scanning? Positioning?
<int_ua> What is the appropriate site to move this discussion?
<futpib> i dunno, simply finding available APs and connecting to them
<int_ua> superuser?
<int_ua> futpib: continuosly? :)
<futpib> well, android is a bit network-centric
<Sicelo> int_ua: i think what he meant was that having no beacons sent makes zero difference on power usage on the client
<futpib> obviously yes
<int_ua> Sicelo: on the client - maybe (what about processing all the info?), but APs still lose power on beacons
<Sicelo> int_ua: beacon not only advertises the AP, but also keeps existing connections alive when no 'data' is being transmitted. without beacons, connection would drop too frequently
<Sicelo> most times the AP is powered by AC, which is rrely the case for the client
<Sicelo> s/rrel/rarely/
<int_ua> Sicelo: yes, agreed. But what if AP sends beacons only in case of active connections present?
<int_ua> Sicelo: yes, of course, but I'm thinking about global usage, not some battery life.
<futpib> how does it work in ad-hoc mode? maybe exactly like you suggest :)
<Sicelo> ad-hoc is a bigger power-hog :P
<Sicelo> it was consuming battery power at such an alarming rate on N900 that i finally went ahead and bought an AP
<int_ua> futpib: I don't know, I lived ~2 years thinking my AP doesn't send beacons =D
<Pali> int_ua, turn wifi card to monitor mode and run wireshark
<Pali> maybe there are APs which do not send beacons...
<Pali> ...we know that implementation of wifi 802.1 is not correct on more cards/systems
<int_ua> Pali: "sudo iwconfig wlan0 mode monitor" says "Device or resource busy"
<futpib> probably bring it down first
<Pali> int_ua, first use iw (instead old deprecated iwconfig) and second: some cards cannot change mode when are up, call ip link set wlan0 down
<int_ua> filtering beacon frames...
<int_ua> tons of beacons per second from my router...
<int_ua> =(
<futpib> om nom nom
<futpib> it seems to be a wordplay in my language, sorry :(
<int_ua> futpib: well, I love wordplay, but I'm not sure I got this one. Is it more than sound of someone eating?)
<futpib> eating tons of bacon per second, wich sounds almost beacon in russian. total off-topic
<Pali> you can limit it in hostapd by "beacon_int=" config
<int_ua> futpib: another offtopic: I know russian :)
<int_ua> Pali: it's just a D-Link router even without openwrt. AFAIU I don't have hostapd on it
<int_ua> strange, I've just enabled WMM and now I can't see the beacons
<int_ua> what an offtopic day in here
<int_ua> yes, there are beacons in the hidden mode.
<Skry> offtopic is good :)
<Skry> Pali: have you booted any distro with 3.8 yet?
<Pali> Skry, only rescue OS
<int_ua> and when I go to "select connection" dialog on N900 it continuously sends "Probe request" messages according to wireshark
<Pali> and maemo bootmenu
<Pali> I fixed /bootmenu.sh to work with 3.8 kernel
<int_ua> So clients are active too
http://msinfluentials.com/blogs/jesper/archive/2008/03/10/regulatory-silliness.aspx
Немає коментарів:
Дописати коментар