Everything I read tells me this may be possible with hostapd (which I see is in the repos), but that you have to have a wireless dongle that supports it, so I'm hoping some folks have actual examples of working product model numbers :-).
(I'm hoping I can provide a wi-fi connection for my phone from my desktop at work).
On 04/24/11 13:44, Tom Horsley wrote:
Everything I read tells me this may be possible with hostapd (which I see is in the repos), but that you have to have a wireless dongle that supports it, so I'm hoping some folks have actual examples of working product model numbers :-).
(I'm hoping I can provide a wi-fi connection for my phone from my desktop at work).
Be sure to set your desktop to enable ip forwarding, and if you have a firewall enabled on y our desktop, be sure to add a rule to allow packets to/from your USB interface. Also, your main interface should NAT packets from your USB interface, otherwise, your will not be able to connect your phone to the public net.
On Sun, 24 Apr 2011 14:07:25 -0700 JD wrote:
(I'm hoping I can provide a wi-fi connection for my phone from my desktop at work).
Be sure to set your desktop to enable ip forwarding, and if you have a firewall enabled on y our desktop, be sure to add a rule to allow packets to/from your USB interface. Also, your main interface should NAT packets from your USB interface, otherwise, your will not be able to connect your phone to the public net.
Yea, but that is all stuff to worry about after I find hardware that actually works :-).
I should also be sure to setup wireless security and not broadcast my SSID, etc. (so as not to attract the MIS department's attention, who would surely tell me I'm not allowed no matter how secure I make the interface :-).
On 04/24/11 14:22, Tom Horsley wrote:
On Sun, 24 Apr 2011 14:07:25 -0700 JD wrote:
(I'm hoping I can provide a wi-fi connection for my phone from my desktop at work).
Be sure to set your desktop to enable ip forwarding, and if you have a firewall enabled on y our desktop, be sure to add a rule to allow packets to/from your USB interface. Also, your main interface should NAT packets from your USB interface, otherwise, your will not be able to connect your phone to the public net.
Yea, but that is all stuff to worry about after I find hardware that actually works :-).
I should also be sure to setup wireless security and not broadcast my SSID, etc. (so as not to attract the MIS department's attention, who would surely tell me I'm not allowed no matter how secure I make the interface :-).
If the IT department is worth it's salt, it's gateway will detect NAT'ed packets, and ring a few bells. You will have to cross t hat bridge when you get to it.
Meanwhile, build the F15 kernel under F14, and try and see if it will indeed detect your USB wifi dongle, and then see if you can get your phone to associate with it.
On Sun, 2011-04-24 at 17:22 -0400, Tom Horsley wrote:
I should also be sure to setup wireless security and not broadcast my SSID, etc. (so as not to attract the MIS department's attention, who would surely tell me I'm not allowed no matter how secure I make the interface :-).
If they're doing their job, then not broadcasting your SSID isn't going to help. It's just a name being transmitted in part of the traffic. You're still transmitting, and some other parts of those transmissions provide identifying information.
On 4/24/11 8:28 PM, Tim wrote:
On Sun, 2011-04-24 at 17:22 -0400, Tom Horsley wrote:
I should also be sure to setup wireless security and not broadcast my SSID, etc. (so as not to attract the MIS department's attention, who would surely tell me I'm not allowed no matter how secure I make the interface :-).
If they're doing their job, then not broadcasting your SSID isn't going to help. It's just a name being transmitted in part of the traffic. You're still transmitting, and some other parts of those transmissions provide identifying information.
The SSID is broadcast from the client to the AP. You would have to be sniffing at the same time that a connection is being made. WPA2 is supposed to 'suppress' this information...
James McKenzie
On Mon, Apr 25, 2011 at 12:28 AM, Tim ignored_mailbox@yahoo.com.au wrote:
If they're doing their job, then not broadcasting your SSID isn't going to help.
Oh yeah, because IT departments are continuously "war driving" around the office with directional antennas, scanning the airwaves for access points...
*sarcasm* FC
On 04/24/11 21:06, Fernando Cassia wrote:
On Mon, Apr 25, 2011 at 12:28 AM, Timignored_mailbox@yahoo.com.au wrote:
If they're doing their job, then not broadcasting your SSID isn't going to help.
Oh yeah, because IT departments are continuously "war driving" around the office with directional antennas, scanning the airwaves for access points...
*sarcasm* FC
I do not believe they have to. If the company has an intelligent gateway/router, it will detect NAT'ed packets, and if the IP address being NAT'ed is not in the list of allowed IP adresses, then some messages would be sent to a network cop.
On Mon, Apr 25, 2011 at 1:24 AM, JD jd1008@gmail.com wrote:
If the company has an intelligent gateway/router, it will detect NAT'ed packets, and if the IP address being NAT'ed is not in the list of allowed IP adresses, then some messages would be sent to a network cop.
If you work for a 3-letter paranoid agency, yes. It takes an IDS (intrusion detection system) which does real-time scanning of all packets, along with very strict policies in place to specifically targeting NAT to ring alarm bells in case NAT is detected.
http://www.sflow.org/detectNAT/
FC
There are very legit uses for NAT. Say you connect your smartphone (or feature phone) via Bluetooth to your PC, to connect receive e-mail on the phone without using your mobile provider´s data network... bang, it does NAT.
http://forum.brighthand.com/treo-650/83479-how-bluetooth-internet-through-pc...
FC
On Mon, 2011-04-25 at 01:06 -0300, Fernando Cassia wrote:
Oh yeah, because IT departments are continuously "war driving" around the office with directional antennas, scanning the airwaves for access points...
It isn't necessary to do that much work to detect "rogue" access points. Instead, just wait until some user in the vicinity files a ticket because "wireless is broken". This is primarily why rogue access points are forbidden at my workplace; it's not security paranoia, it's interference with the production wireless network that is at stake.
--Greg
On Mon, Apr 25, 2011 at 11:38 AM, Greg Woods woods@ucar.edu wrote:
This is primarily why rogue access points are forbidden at my workplace; it's not security paranoia, it's interference with the production wireless network that is at stake.
I´d refuse to work on any place that *forces* me to use Wi-Fi instead of a proper, Cat5e Ethernet (or fiber) LAN....
If they use wi-fi at the workplace then they have bigger security worries to begin with. :-P
FC
On Mon, 2011-04-25 at 13:41 -0300, Fernando Cassia wrote:
I´d refuse to work on any place that *forces* me to use Wi-Fi instead of a proper, Cat5e Ethernet (or fiber) LAN....
We do not force people to use wireless; we do have a wired LAN as well. But lots of people have mobile laptops, smartphones, and other devices that need wireless. We also have on-site workshops and conferences where it is not practical to provide wired connections for all the visitors. We provide wireless IN ADDITION TO the normal wired LAN, because it is a service that is in demand.
If they use wi-fi at the workplace then they have bigger security worries to begin with. :-P
There are ways that these worries can be addressed and we do. Our wireless network does not provide direct access to our internal network without certificate-based WPA2 authentication with fully encrypted communication. We have a "guest" wireless network that is outside of our security perimeter for visitors. That is no more risky for us than allowing outsiders to connect to our servers (which we have to because it is part of our research mission) and no more risky for the visitors than using WiFi at the local coffee shop. It is up to them whether they want to take that risk.
--Greg
On Mon, Apr 25, 2011 at 2:38 PM, Greg Woods woods@ucar.edu wrote:
There are ways that these worries can be addressed and we do.
What you decribe seems OK.
What I find stupid is when you have 20 people on desks using Wi-Fi because management is too cheap or lazy to install proper networking...
Then the entire corporate network security depends on the strength of WPA2...
FC
On Mon, Apr 25, 2011 at 11:18 AM, Fernando Cassia fcassia@gmail.com wrote:
On Mon, Apr 25, 2011 at 2:38 PM, Greg Woods woods@ucar.edu wrote:
There are ways that these worries can be addressed and we do.
What you decribe seems OK.
What I find stupid is when you have 20 people on desks using Wi-Fi because management is too cheap or lazy to install proper networking...
Then the entire corporate network security depends on the strength of WPA2...
Ask TJX about the WAP gap and what kind of fun it can create.
James McKenzie
-
Fernando Cassia -
Greg Woods -
James McKenzie -
JD -
Tim -
Tom Horsley