For something like that you would need a dual-mode cellphone (something that does GSM/CDMA,etc on one side, and 802.11g w/ SIP on the other side). Then, when you're in your house, your phone would join the wifi network and register to a SIP controller (ala Asterisk). Then, when your landline rings, your cellphone would ring as well. The key is you need a handset that supports both GSM/CDMA, as well as 802.11g & SIP.
And keep the legacy landline handsets in the house. This way, no matter where you are in the house, whether or not the cellphone is with you, you can still make/receive calls - leveraging your cell minutes.
You can probably integrate that with an Asterisk VoIP system and get additional things like intercom, room-to-room dialing, etc.
My friends and I have a running game where we see how long we can keep them on the phone line. Play along, come up with funny objections, etc. The goal is to see how long you can keep them on the phone. I've only been able to get 20 minutes down - my wife's record is 26. Think of it as a honeypot - let them waste their time on opportunities that don't really exist.
I had similar problems. The best and easiest way to do this would be to rate-limit all TCP transmission/reception to some percentage less than your overall Internet bandwidth, say 80%. That way, all applications (FTP, BitTorrent, HTTP, etc.) won't take up all of your bandwidth, and thus kill your VoIP. The problem that you're having is that you're saturating your uplink or downlink, and that's what's delaying the VoIP packets. You only need to rate-limit TCP, since Vonage (and most VoIP out there) is UDP-based. You want to let the UDP through without touching it. By limiting TCP, you're effectively reserving UDP bandwidth for your VoIP.
You can do this with a fairly inexpensive Cisco router (buy an 800-series off ebay). You can probably do it with DD-WRT as well.
For the true gearheads out there, I worked out something similar, except that my system actually senses when a call is in process and makes appropriate TCP rate-limiting for the duration of the call. Once the call is complete, the full bandwidth becomes available for other things. It's a clever use of Snort, pfSense, and a Cisco router. I call it AATQoS or Application Aware Triggered Quality of Service.
Whatever you end up doing, just understand that your call quality is suffering due to traffic congestion, and if you can alleviate that congestion enough to let the VoIP UDP packets flow, then your call quality will sound great.
I had major issues with bittorrent, NNTP, and other bulk file transfer applications causing massive latency for my VoIP line. I tried a few things but nothing worked out. I ended up settling on a combination of Snort (to detect when I'm on a VoIP call), pfSense (a box to host the application on), and a Cisco router to rate limit only while I was on a call, to get flawless VoIP even with bittorrent running.
Substitute "VoIP" for online game if you wish... the concept is the same. The nice thing about this method is that 100% of the bandwidth is available for bulk file transfer when important applications are idle, but when they fire-up, rate limiting takes enough bite out of the file transfers to make the VoIP work well.
Re:3com's NIC replacement?
on
The 3Com Saga
·
· Score: 1
Intel already won the NIC war. 3Com's NIC business is dead in the water. They've already phased out most of the NIC product line, and what is left is an extremely small percentage of what they're offering today (Switches, Routers, VoIP, Wireless, Security).
What are you smoking? Or should I say, what is your reseller smoking. The license stays with the call processor. I've swapped the new license-requiring phones under RMA and replaced them with new phones and never had to worry about licenses.
Too bad it's really not this way. Maybe 3Com wouldn't be as unprofitable as they currently are.
Where are you going to put that "internal firewall" so that it would filter ALL of the traffic on your network? You can't. (Unless it's a 3005-port firewall that each of your machines plugs into!)
By adding firewall capabilities to each machine, you can control and protect each individual box, regardless of where the machines are and who is doing the hacking (internal or external).
Once you've upgraded the firmware, Embedded Firewall places a write-protect on the flash. Future updates to the firmware must be authorized from the central management console first. This prevents anyone (virus, malicious code, blackhat, user sitting locally at machine) from updating/changing/modifying the firmware on their own.
Embedded Firewall can protect 95/98/NT/2K/XP machines today. The Policy Server must run on NT4 or Win2k (pro/server - doesn't matter). Linux is the next OS online for support.
Yes, 3Com expects the PC administrators to flash each and every NIC. Of course, you'd do it in an automated fashion through a network management app.
The firmware update places the firewall code onto the firmware of the nic, and that removes any capability of the end user or malicious code from ever changing the rules or applying further changes to the firmware - unless they come from the policy server.
At that point, you can't modify anything from the local machine software configuration to change your rules.
What stops the trojan from sending? The ACL on the card. Depending on how it's configured, the ports and protocols required wouldn't be open, and if they were, the ACL could be further configured to include certain IP addresses.
It would be interesting for that scenario. Having a central policy server would still be key, however. If a hacker owns your machine somehow, then they can modify their own.conf file and take the machine wide open. By requiring that it happen centrally with the proper encryption keys, you remove all possibility that someone else can change the firewall rules.
Maybe 3Com will release a scaled down policy server that isn't $1000... especially when you're only controlling 3-4 machines.
When the Policy Server pushes a policy down to the NIC, it goes straight to the NIC hardware and is immediately implemented (yay, no rebooting). The Host OS never sees the packet.
They are not... BCM5703 hasn't been shipping as long as these cards have (for at least 2 years now). It's a 3Com proprietary processor internally code-named Typhoon. It's 3Com NIC technology combined with an ARM9 cpu running @ 120mhz.
Ya... a simple ruleset for telecommuters (desktop or laptop) would be:
Allow DHCP Client Allow DNS Client allow VPN ports/protocols to 1.1.1.1 bidirectional deny all other traffic
This would prevent a "bounce" attack (someone coming in on the coat tails of a VPN connection).
Something like this also extends the perimeter firewall at the headquarters... So you still get IDS, web filtering, etc. etc... Interesting proposition.
If you want your bluetooth device available for others to connect to it, you set it's security to "low" or "none".
If you want to guarantee that you and only you can connect to your cellphone, you go through a process called "pairing". This assures that my cellphone will only talk to MY bluetooth PC Card and not my neighbor's.
It all depends on the level of security you wish to use on your bluetooth devices.
You won't see cellphone manufacturers building cellphones with 802.11b anytime soon - they're all going down the Bluetooth road. That, by itself, will probably drive many bluetooth applications/products.
I demo bluetooth hardware as part of my job. I have a 3Com Bluetooth PC Card along with an 802.11b PC Card. I am able to surf the net, transfer files, etc., over the 802.11b link, and at the same time, I can sync my PC to an Ericsson T39m (with built-in Bluetooth) or print to my Bluetooth Printer. While I've heard stories that range might be a problem while both radios are active, I personally haven't seen any issues.
3Com demo'd a Bluetooth PC Card with this HP printer at N+I in Atlanta - it was pretty cool.
One of the nice things about a bluetooth printers is that you don't have to let someone onto your corporate network (wired or 802.11b) just because they need to print something out.
Slashdot Mirror
For something like that you would need a dual-mode cellphone (something that does GSM/CDMA,etc on one side, and 802.11g w/ SIP on the other side). Then, when you're in your house, your phone would join the wifi network and register to a SIP controller (ala Asterisk). Then, when your landline rings, your cellphone would ring as well. The key is you need a handset that supports both GSM/CDMA, as well as 802.11g & SIP.
Have a look at this.
Get one of these:
http://www.myxlink.com/index.aspx
And keep the legacy landline handsets in the house. This way, no matter where you are in the house, whether or not the cellphone is with you, you can still make/receive calls - leveraging your cell minutes.
You can probably integrate that with an Asterisk VoIP system and get additional things like intercom, room-to-room dialing, etc.
My friends and I have a running game where we see how long we can keep them on the phone line. Play along, come up with funny objections, etc. The goal is to see how long you can keep them on the phone. I've only been able to get 20 minutes down - my wife's record is 26. Think of it as a honeypot - let them waste their time on opportunities that don't really exist.
I had similar problems. The best and easiest way to do this would be to rate-limit all TCP transmission/reception to some percentage less than your overall Internet bandwidth, say 80%. That way, all applications (FTP, BitTorrent, HTTP, etc.) won't take up all of your bandwidth, and thus kill your VoIP. The problem that you're having is that you're saturating your uplink or downlink, and that's what's delaying the VoIP packets. You only need to rate-limit TCP, since Vonage (and most VoIP out there) is UDP-based. You want to let the UDP through without touching it. By limiting TCP, you're effectively reserving UDP bandwidth for your VoIP.
You can do this with a fairly inexpensive Cisco router (buy an 800-series off ebay). You can probably do it with DD-WRT as well.
For the true gearheads out there, I worked out something similar, except that my system actually senses when a call is in process and makes appropriate TCP rate-limiting for the duration of the call. Once the call is complete, the full bandwidth becomes available for other things. It's a clever use of Snort, pfSense, and a Cisco router. I call it AATQoS or Application Aware Triggered Quality of Service.
Whatever you end up doing, just understand that your call quality is suffering due to traffic congestion, and if you can alleviate that congestion enough to let the VoIP UDP packets flow, then your call quality will sound great.
I had major issues with bittorrent, NNTP, and other bulk file transfer applications causing massive latency for my VoIP line. I tried a few things but nothing worked out. I ended up settling on a combination of Snort (to detect when I'm on a VoIP call), pfSense (a box to host the application on), and a Cisco router to rate limit only while I was on a call, to get flawless VoIP even with bittorrent running.
Substitute "VoIP" for online game if you wish... the concept is the same. The nice thing about this method is that 100% of the bandwidth is available for bulk file transfer when important applications are idle, but when they fire-up, rate limiting takes enough bite out of the file transfers to make the VoIP work well.
I call it Application Aware Triggered Quality of Service or AATQoS for short. Read the how-to on the webpage.
10 Calories per serving (okay, 20 calories per can), tastes pretty darn good.
h p
http://monster.sponsorhouse.com/product/lowcarb.p
As bad as it gets..... for 3Com (yes, I left that part out).
There are quite a few choices from Foundry, Force10, etc. that would spank whatever 3Com has to offer in the core - no doubt about that.
This is as big/bad as it gets:
Intel already won the NIC war. 3Com's NIC business is dead in the water. They've already phased out most of the NIC product line, and what is left is an extremely small percentage of what they're offering today (Switches, Routers, VoIP, Wireless, Security).
What are you smoking? Or should I say, what is your reseller smoking. The license stays with the call processor. I've swapped the new license-requiring phones under RMA and replaced them with new phones and never had to worry about licenses.
Too bad it's really not this way. Maybe 3Com wouldn't be as unprofitable as they currently are.
The 3Com NBX uses WindRiver's VxWorks operating system.
The phones run a layer-2 proprietary protocol, but can run that same protocol over IP if you want to use phones across a router boundary.
This is not a change. It has been VxWorks since the beginning.
hidden72
Where are you going to put that "internal firewall" so that it would filter ALL of the traffic on your network? You can't. (Unless it's a 3005-port firewall that each of your machines plugs into!)
By adding firewall capabilities to each machine, you can control and protect each individual box, regardless of where the machines are and who is doing the hacking (internal or external).
Once you've upgraded the firmware, Embedded Firewall places a write-protect on the flash. Future updates to the firmware must be authorized from the central management console first. This prevents anyone (virus, malicious code, blackhat, user sitting locally at machine) from updating/changing/modifying the firmware on their own.
Embedded Firewall can protect 95/98/NT/2K/XP machines today. The Policy Server must run on NT4 or Win2k (pro/server - doesn't matter). Linux is the next OS online for support.
Yes, 3Com expects the PC administrators to flash each and every NIC. Of course, you'd do it in an automated fashion through a network management app.
The firmware update places the firewall code onto the firmware of the nic, and that removes any capability of the end user or malicious code from ever changing the rules or applying further changes to the firmware - unless they come from the policy server.
At that point, you can't modify anything from the local machine software configuration to change your rules.
What stops the trojan from sending? The ACL on the card. Depending on how it's configured, the ports and protocols required wouldn't be open, and if they were, the ACL could be further configured to include certain IP addresses.
The one update I can give you is that the release version of the product allows for 64 rules on the client side, and 128 rules on the server side
It would be interesting for that scenario. Having a central policy server would still be key, however. If a hacker owns your machine somehow, then they can modify their own .conf file and take the machine wide open. By requiring that it happen centrally with the proper encryption keys, you remove all possibility that someone else can change the firewall rules.
Maybe 3Com will release a scaled down policy server that isn't $1000... especially when you're only controlling 3-4 machines.
When the Policy Server pushes a policy down to the NIC, it goes straight to the NIC hardware and is immediately implemented (yay, no rebooting). The Host OS never sees the packet.
They are not... BCM5703 hasn't been shipping as long as these cards have (for at least 2 years now). It's a 3Com proprietary processor internally code-named Typhoon. It's 3Com NIC technology combined with an ARM9 cpu running @ 120mhz.
Ya... a simple ruleset for telecommuters (desktop or laptop) would be:
Allow DHCP Client
Allow DNS Client
allow VPN ports/protocols to 1.1.1.1 bidirectional
deny all other traffic
This would prevent a "bounce" attack (someone coming in on the coat tails of a VPN connection).
Something like this also extends the perimeter firewall at the headquarters... So you still get IDS, web filtering, etc. etc... Interesting proposition.
If you want your bluetooth device available for others to connect to it, you set it's security to "low" or "none".
If you want to guarantee that you and only you can connect to your cellphone, you go through a process called "pairing". This assures that my cellphone will only talk to MY bluetooth PC Card and not my neighbor's.
It all depends on the level of security you wish to use on your bluetooth devices.
You won't see cellphone manufacturers building cellphones with 802.11b anytime soon - they're all going down the Bluetooth road. That, by itself, will probably drive many bluetooth applications/products.
I demo bluetooth hardware as part of my job. I have a 3Com Bluetooth PC Card along with an 802.11b PC Card. I am able to surf the net, transfer files, etc., over the 802.11b link, and at the same time, I can sync my PC to an Ericsson T39m (with built-in Bluetooth) or print to my Bluetooth Printer. While I've heard stories that range might be a problem while both radios are active, I personally haven't seen any issues.
3Com demo'd a Bluetooth PC Card with this HP printer at N+I in Atlanta - it was pretty cool.
One of the nice things about a bluetooth printers is that you don't have to let someone onto your corporate network (wired or 802.11b) just because they need to print something out.