Possibly because if there were oil near faults, it would be boiled and/or ignited (oxygen permitting). It's entirely possible that there are oil deposits near these places, but the proximate volcano would likely grab our attention more so. But IANAG (I am not a Geologist).
I'll reproduce this from another of my comments:
Lol, of course iwlist will show _some_ information about the network, as networks are configured to beacon at a given time interval with information such as band, BSSID, available throughputs, etc. Minus these being broadcast, we'd have to configure every little option about the network. It just excludes the SSID when the feature we're talking about is turned on, as I've stated time and time again. I've never claimed contrary to this, though you seem to wish I had. I stated (and rightly so) that iwlist will not show the ESSID of a network that hides its ESSID. You're changing your statements to try and save face/backpedal/whathaveyou. I've already proved that you thought ESSID would show up even when the AP is configured not to broadcast it, and I don't feel like stating that again here, as I've had to quote myself on it several times already. You can post all you want in reply to my comments, I'll reply to every single one of them to show how you're wrong. No one who knows what they're talking about is going to accept what you say.;)
Lol, of course iwlist will show _some_ information about the network, as networks are configured to beacon at a given time interval with information such as band, BSSID, available throughputs, etc. Minus these being broadcast, we'd have to configure every little option about the network. It just excludes the SSID when the feature we're talking about is turned on, as I've stated time and time again. I've never claimed contrary to this, though you seem to wish I had. I stated (and rightly so) that iwlist will not show the ESSID of a network that hides its ESSID. You're changing your statements to try and save face/backpedal/whathaveyou. I've already proved that you thought ESSID would show up even when the AP is configured not to broadcast it, and I don't feel like stating that again here, as I've had to quote myself on it several times already. You can post all you want in reply to my comments, I'll reply to every single one of them to show how you're wrong. No one who knows what they're talking about is going to accept what you say.;)
To connect to it, you use a different tool to get it. Iwlist shows that you can do this, by showing you that a network is there.
Hey! Congratulations! By "it" I presume you mean ESSID, so you finally said something true. Thank you for finally conceding my correctness, took you long enough to get to this point.:P
This is obvious backpedaling, as I already said. You replied to a commenter who asked "But what if I hide my SSID" that they were a silly Windows user and that `iwlist` will show it just fine. Your argument is like a closed shape with no vertexes.
I'll leave you to read the other comment I left for you, though I do need to make a note that you ran through the test I suggested before claiming you were joking.;)
So, the comment you're replying to asks innocently "But if I hide my SSID how are you going to find it?" You respond "iwlist shows it silly Windows user". But I'm not to take "it" to mean SSID, when that was the subject of your parent's comment? Heh, no. Your responses to mine have been you trying to save face. I wasn't in need of clarification, you were in need if a little ego check.;)
Lol no, I'm not wrong. Read the reply I gave to your other comment before you jump to that conclusion.
"I was just telling parent why 'iwlist' isn't the tool for the job here, I already provided for the 'sniffing' alternative, of which kismet and the rest comprise. 'iwlist' is just like standard Windows and Linux wireless clients in that it sends out probes to look for APs."
You: Silly Windows user, iwlist will show them just fine!
Me: You can't decloak an AP by sending out probes.
That's not how it works.
You: Lulz silly Windows user, iwlist works just fine like I said!
Me: You're wrong and here's why...
You: Lulz I was just joking hahaha!
"The beacons aren't broadcasting the SSID, so you'd still need to sniff even even if it wasn't encrypted."
My point is, as I said earlier, iwlist isn't the tool for the job for breaking into wireless access points which hide their SSID. You stated that you were able to determine the ESSID of such a network using just iwlist, and I felt the need to point out that you were using it incorrectly, being that you felt the need to denigrate those 'silly Windows users'.
I was just telling parent why 'iwlist' isn't the tool for the job here, I already provided for the 'sniffing' alternative, of which kismet and the rest comprise. 'iwlist' is just like standard Windows and Linux wireless clients in that it sends out probes to look for APs.
You have a fundamental misunderstanding of 802.11 and belligerence/holier-than-thou attitude to boot.
An 802.11 access point will not respond to a probe with its actual SSID if it's configured to not broadcast SSID. If it were not heeding this directive, you'd still see the access point using a Windows station. This condition is the express purpose of the "don't broadcast SSID" directive.
You can verify your incorrectness by disabling SSID broadcast on an AP with proper firmware, actually saving the setting, ifconfig interface down/ifconfig interface up and attempting iwlist again. If you see an ESSID other than an empty string in your output, then you'll see the access point on Windows too, provided the band is supported by your Windows wireless hardware as well. Any other result is you doing it wrong or just plain trolling.
The only time you'll see the actual SSID of these types of APs are clients setting the ESSID field in packets they send to the AP, which would require you to sniff.
People like you are a significant contributing factor in the slow adoption of Linux, so thanks for that.
Sure are available DIY, for the price of a halfway decent wireless card (optimally supporting injection), a box running linux, and the requisite
AirCrack (the latter for the total price of free).
In case you didn't understand my comment: the HTML input elements that are in the source to show those boxes on the page are NOT part of a form element. This means that absent some javascript, the data in those input elements will not be transmitted. Go ahead and try it with Wireshark for yourself, you'll see that the only result is a GET request for their 'you have failed' page.
That's not the point of the site. The point is to show the vulnerable how easy it is to fall for phishing scams, and that you should never provide your credit card number to a site that you're unfamiliar with.
The site is clearly not malicious. The form tag on the page doesn't include the card number and other identifying input elements, so that data isn't gathered or even transmitted over the network from what I can tell. The page just sends you to their 'you have failed page' any time you submit it.
I also doubt that as well. Nonetheless, many Islamic scholars who wish to justify the hatred they feel and the violence they desire against those they perceive as enemies have and continue to advocate such indiscriminate killing.
I think this Youtube video adequately describes some of the problems with Islam as a whole: http://www.youtube.com/watch?v=NyNQ1zc-q74
Remember all the shenanigans that have happened with censorship countries announcing invalid routes over BGP and accidentally disabling or blocking websites halfway across the globe? Think that.
German government warns against use of the internet and software that has bugs.
Software is inevitably going to have bugs in it and try as we might, it's something we'll always have to deal with. There are always mitigation strategies, such as running Firefox in a virtualized environment a la Sandboxie or a full virtual machine, but we'll never be privy to using only bug-free software day to day. I'm glad to see the German government taking an active approach to notifying people in regard to vulnerabilities in an attempt to mitigate them, but as TFA states, what's the point in suggesting users quit using Firefox when the alternatives are potentially just as vulnerable?
Hopefully it's evidence that they plan to actually create a stable piece of hardware that doesn't suffer from the RRoD at an absurd rate (at least in MS' case). Plus they've just sunk their teeth into digital distribution and they want to milk it and mature it for all this generation is worth (read: they might want to release the next generation only compatible with game downloads).
Slashdot Mirror
Possibly because if there were oil near faults, it would be boiled and/or ignited (oxygen permitting). It's entirely possible that there are oil deposits near these places, but the proximate volcano would likely grab our attention more so. But IANAG (I am not a Geologist).
I'll reproduce this from another of my comments: Lol, of course iwlist will show _some_ information about the network, as networks are configured to beacon at a given time interval with information such as band, BSSID, available throughputs, etc. Minus these being broadcast, we'd have to configure every little option about the network. It just excludes the SSID when the feature we're talking about is turned on, as I've stated time and time again. I've never claimed contrary to this, though you seem to wish I had. I stated (and rightly so) that iwlist will not show the ESSID of a network that hides its ESSID. You're changing your statements to try and save face/backpedal/whathaveyou. I've already proved that you thought ESSID would show up even when the AP is configured not to broadcast it, and I don't feel like stating that again here, as I've had to quote myself on it several times already. You can post all you want in reply to my comments, I'll reply to every single one of them to show how you're wrong. No one who knows what they're talking about is going to accept what you say. ;)
Lol, of course iwlist will show _some_ information about the network, as networks are configured to beacon at a given time interval with information such as band, BSSID, available throughputs, etc. Minus these being broadcast, we'd have to configure every little option about the network. It just excludes the SSID when the feature we're talking about is turned on, as I've stated time and time again. I've never claimed contrary to this, though you seem to wish I had. I stated (and rightly so) that iwlist will not show the ESSID of a network that hides its ESSID. You're changing your statements to try and save face/backpedal/whathaveyou. I've already proved that you thought ESSID would show up even when the AP is configured not to broadcast it, and I don't feel like stating that again here, as I've had to quote myself on it several times already. You can post all you want in reply to my comments, I'll reply to every single one of them to show how you're wrong. No one who knows what they're talking about is going to accept what you say. ;)
To connect to it, you use a different tool to get it. Iwlist shows that you can do this, by showing you that a network is there.
Hey! Congratulations! By "it" I presume you mean ESSID, so you finally said something true. Thank you for finally conceding my correctness, took you long enough to get to this point. :P
This is obvious backpedaling, as I already said. You replied to a commenter who asked "But what if I hide my SSID" that they were a silly Windows user and that `iwlist` will show it just fine. Your argument is like a closed shape with no vertexes.
And that's not the ACTUAL SSID of the network, LOL! That's what iwlist shows when it cannot determine the actual SSID homeslice.
I'll leave you to read the other comment I left for you, though I do need to make a note that you ran through the test I suggested before claiming you were joking. ;)
Thanks for the support, at least I know someone saw it other than those people in need of a little knowledge and a little less ego. :)
So, the comment you're replying to asks innocently "But if I hide my SSID how are you going to find it?" You respond "iwlist shows it silly Windows user". But I'm not to take "it" to mean SSID, when that was the subject of your parent's comment? Heh, no. Your responses to mine have been you trying to save face. I wasn't in need of clarification, you were in need if a little ego check. ;)
Lol no, I'm not wrong. Read the reply I gave to your other comment before you jump to that conclusion. "I was just telling parent why 'iwlist' isn't the tool for the job here, I already provided for the 'sniffing' alternative, of which kismet and the rest comprise. 'iwlist' is just like standard Windows and Linux wireless clients in that it sends out probes to look for APs."
You: Silly Windows user, iwlist will show them just fine! Me: You can't decloak an AP by sending out probes. That's not how it works.
You: Lulz silly Windows user, iwlist works just fine like I said!
Me: You're wrong and here's why...
You: Lulz I was just joking hahaha!
That about right?
"The beacons aren't broadcasting the SSID, so you'd still need to sniff even even if it wasn't encrypted."
My point is, as I said earlier, iwlist isn't the tool for the job for breaking into wireless access points which hide their SSID. You stated that you were able to determine the ESSID of such a network using just iwlist, and I felt the need to point out that you were using it incorrectly, being that you felt the need to denigrate those 'silly Windows users'.
I was just telling parent why 'iwlist' isn't the tool for the job here, I already provided for the 'sniffing' alternative, of which kismet and the rest comprise. 'iwlist' is just like standard Windows and Linux wireless clients in that it sends out probes to look for APs.
You have a fundamental misunderstanding of 802.11 and belligerence/holier-than-thou attitude to boot. An 802.11 access point will not respond to a probe with its actual SSID if it's configured to not broadcast SSID. If it were not heeding this directive, you'd still see the access point using a Windows station. This condition is the express purpose of the "don't broadcast SSID" directive.
You can verify your incorrectness by disabling SSID broadcast on an AP with proper firmware, actually saving the setting, ifconfig interface down/ifconfig interface up and attempting iwlist again. If you see an ESSID other than an empty string in your output, then you'll see the access point on Windows too, provided the band is supported by your Windows wireless hardware as well. Any other result is you doing it wrong or just plain trolling.
The only time you'll see the actual SSID of these types of APs are clients setting the ESSID field in packets they send to the AP, which would require you to sniff.
People like you are a significant contributing factor in the slow adoption of Linux, so thanks for that.
The beacons aren't broadcasting the SSID, so you'd still need to sniff even even if it wasn't encrypted.
Where can I get some free wifi USB dongles or PCMCIA cards?
Sure are available DIY, for the price of a halfway decent wireless card (optimally supporting injection), a box running linux, and the requisite AirCrack (the latter for the total price of free).
FCC is the besieged agency the summary is actually referring to, not the FTC.
In case you didn't understand my comment: the HTML input elements that are in the source to show those boxes on the page are NOT part of a form element. This means that absent some javascript, the data in those input elements will not be transmitted. Go ahead and try it with Wireshark for yourself, you'll see that the only result is a GET request for their 'you have failed' page.
That's not the point of the site. The point is to show the vulnerable how easy it is to fall for phishing scams, and that you should never provide your credit card number to a site that you're unfamiliar with.
The site is clearly not malicious. The form tag on the page doesn't include the card number and other identifying input elements, so that data isn't gathered or even transmitted over the network from what I can tell. The page just sends you to their 'you have failed page' any time you submit it.
I also doubt that as well. Nonetheless, many Islamic scholars who wish to justify the hatred they feel and the violence they desire against those they perceive as enemies have and continue to advocate such indiscriminate killing. I think this Youtube video adequately describes some of the problems with Islam as a whole: http://www.youtube.com/watch?v=NyNQ1zc-q74
Oooh baby yeah, yeah. Show me more of that anger, yeah. You want some upmod? Here you go baby. Yeah.
Remember all the shenanigans that have happened with censorship countries announcing invalid routes over BGP and accidentally disabling or blocking websites halfway across the globe? Think that.
Check this for an example.
German government warns against use of the internet and software that has bugs.
Software is inevitably going to have bugs in it and try as we might, it's something we'll always have to deal with. There are always mitigation strategies, such as running Firefox in a virtualized environment a la Sandboxie or a full virtual machine, but we'll never be privy to using only bug-free software day to day. I'm glad to see the German government taking an active approach to notifying people in regard to vulnerabilities in an attempt to mitigate them, but as TFA states, what's the point in suggesting users quit using Firefox when the alternatives are potentially just as vulnerable?
Hopefully it's evidence that they plan to actually create a stable piece of hardware that doesn't suffer from the RRoD at an absurd rate (at least in MS' case). Plus they've just sunk their teeth into digital distribution and they want to milk it and mature it for all this generation is worth (read: they might want to release the next generation only compatible with game downloads).