Re: [WISPA] Redundant Connections
I was looking for something similar the other day. http://www.google.com/search?ie=UTF-8oe=UTF-8q=dual+wan+port+broadband+routerbtnG=Google+Search You'll likely want something of a higher quality. But it can be done. I think that wisps that don't have a backup offering are missing a very big boat today. Especially in the more urban markets. Marlon (509) 982-2181 Equipment sales (408) 907-6910 (Vonage)Consulting services 42846865 (icq)And I run my own wisp! 64.146.146.12 (net meeting) www.odessaoffice.com/wireless www.odessaoffice.com/marlon/cam - Original Message - From: John Scrivner [EMAIL PROTECTED] To: wireless@wispa.org Sent: Thursday, January 12, 2006 11:10 AM Subject: [WISPA] Redundant Connections A little feedback from the collective is appreciated here. I have a high school who has bought a connection from me but is also stuck with an old T1 circuit under contract for the next 3 years. They want both connections to be used all the time and for all traffic to automatically go through the working connection if one fails. Basically they want load balancing and failover. All addresses are nat'd private space IPs. I would think I should be able to do this with Mikrotik and/or Star OS but I do not know how. Your thoughts and or other suggestions are highly appreciated. If only failover or only load balance is possible then suggestions on that are welcome also. By the way, the T1 provider is not me and will likely not work with me unfortunately. We have to leave their network settings intact. Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Redundant Connections
Stay away from the Xincom routers. They don't work and there is no support. Marlon K. Schafer (509) 982-2181 wrote: I was looking for something similar the other day. http://www.google.com/search?ie=UTF-8oe=UTF-8q=dual+wan+port+broadband+routerbtnG=Google+Search You'll likely want something of a higher quality. But it can be done. I think that wisps that don't have a backup offering are missing a very big boat today. Especially in the more urban markets. Marlon (509) 982-2181 Equipment sales (408) 907-6910 (Vonage)Consulting services 42846865 (icq)And I run my own wisp! 64.146.146.12 (net meeting) www.odessaoffice.com/wireless www.odessaoffice.com/marlon/cam - Original Message - From: John Scrivner [EMAIL PROTECTED] To: wireless@wispa.org Sent: Thursday, January 12, 2006 11:10 AM Subject: [WISPA] Redundant Connections A little feedback from the collective is appreciated here. I have a high school who has bought a connection from me but is also stuck with an old T1 circuit under contract for the next 3 years. They want both connections to be used all the time and for all traffic to automatically go through the working connection if one fails. Basically they want load balancing and failover. All addresses are nat'd private space IPs. I would think I should be able to do this with Mikrotik and/or Star OS but I do not know how. Your thoughts and or other suggestions are highly appreciated. If only failover or only load balance is possible then suggestions on that are welcome also. By the way, the T1 provider is not me and will likely not work with me unfortunately. We have to leave their network settings intact. Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Redundant Connections
Have you used that backhaul to carry one of your high end business client's cisco VPNs? Most people don't even know how to detect that packets are getting sent out of order, and don't realize bandwidth is being wasted on packet drops. The reason is the only way to know is to go into the logs of the end user's VPN routers. Cisco VPN gear has some good tools to test the VPN and report the loss. It was the tech company of the subscriber, that it brought it to our attention and noticed it. And on $500 a month ARPU subs, if they see something like that, it means cancellation, if it can't be resolved. The reason is high end customers shoot for 100% not 99.9%. Andwhen things aren't perfect, the smarter techs realize that a less than perfect link could effect many different things that get troubleshooted over time, so the goal is to make it perfect to rule it out from ever being a factor. If fiber can make it perfect and wireless can't, wireless goes. That has been my experience. So my question to you is... when you use Mikrotik for Per Packet load balancing, does the Mikrotik, just guarantee that the packets arrive in order, or does the Mikrotik correct any errors in the packets getting received out of order, or are your links lucky to just be capable of delivering the packets in order? Technically, if a radio has a buffer or queue, its possible for the protocols to re-order the packets so they are back in order by the time they leave the other end of the Mikrotik router. At a small penalty of latency, re-ordering could be acheived. Its also possible that the end user VPN protocols could also already take care of that. I don't know enoguh about the VPN venders to know which protocols self-correct/guarantee correct packet ordering. When using the per packet load balancing of theMikrotik, is the Mikrotik also the radio, apposed to it be jsut the router connected Ethernet to external radios of another brand. Its possible that without Ethernet involved in between that they jsut get to the destination in order more frequently. Running per packet load balancing is much more reliable over circuits with fixed factors such as wired and fiber connections. In an RF enviroment its a much different situation. There are many factors in RF that can cause a packet to get delayed in delivery individually. For example an RF link that automatically adjusts modulation when errors occur. Because two RF links may transfer at different rates, the packets could arrive at different times. I did not specify previously, but when mentioning the risk of per packet load balancing, I was referring to using it within an RF environment. And I was referring to it being used for loadbalancing for a PtP link. Load balancing per packet between two different ISP transit providers, also could result in serious out of order packet problems, thus justifying per session load balancing. A PTP wired link, very well may be a preferred method to use per packet load balancing. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 8:22 PM Subject: RE: [WISPA] Redundant Connections I think it depends on the links involved and the remote termination, I currently run per packet round robin load balance across 3 T1's, no issue's with VoIP or VPN - of course the remote ends points are the same devices -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi Sent: Thursday, January 12, 2006 5:17 PM To: WISPA General List Subject: Re: [WISPA] Redundant Connections It important to consider the possibilties of packets arriving out of order. Some VPN protocols (deployed by corporate subscribers), will discard the packets when they arrive out of order, and is almost as bad as packet loss. And VOIP quality can be degrated as well. Per session is preferred. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Paul Hendry [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 3:22 PM Subject: RE: [WISPA] Redundant Connections Running a EoIP tunnel across both the T1 and your link you should be able to load-balance across both links for incoming and outgoing traffic by bonding both EoIP interfaces at the customer site and your Mikrotik box. I have done this in the past but it has been across a couple of wireless links with similar round trip delays. If you use per-packet load balancing there may be issues with packets arriving out of order but if you do it per session it should work fine. With per session load balancing you won't get an aggregate throughput of both links with a single stream but should use both links if multiple streams are flowing. Cheers, P. -Original Message
RE: [WISPA] Redundant Connections
These are PTP wired links - 3 of them combined together - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi Sent: Friday, January 13, 2006 1:32 PM To: WISPA General List Subject: Re: [WISPA] Redundant Connections Have you used that backhaul to carry one of your high end business client's cisco VPNs? Most people don't even know how to detect that packets are getting sent out of order, and don't realize bandwidth is being wasted on packet drops. The reason is the only way to know is to go into the logs of the end user's VPN routers. Cisco VPN gear has some good tools to test the VPN and report the loss. It was the tech company of the subscriber, that it brought it to our attention and noticed it. And on $500 a month ARPU subs, if they see something like that, it means cancellation, if it can't be resolved. The reason is high end customers shoot for 100% not 99.9%. Andwhen things aren't perfect, the smarter techs realize that a less than perfect link could effect many different things that get troubleshooted over time, so the goal is to make it perfect to rule it out from ever being a factor. If fiber can make it perfect and wireless can't, wireless goes. That has been my experience. So my question to you is... when you use Mikrotik for Per Packet load balancing, does the Mikrotik, just guarantee that the packets arrive in order, or does the Mikrotik correct any errors in the packets getting received out of order, or are your links lucky to just be capable of delivering the packets in order? Technically, if a radio has a buffer or queue, its possible for the protocols to re-order the packets so they are back in order by the time they leave the other end of the Mikrotik router. At a small penalty of latency, re-ordering could be acheived. Its also possible that the end user VPN protocols could also already take care of that. I don't know enoguh about the VPN venders to know which protocols self-correct/guarantee correct packet ordering. When using the per packet load balancing of theMikrotik, is the Mikrotik also the radio, apposed to it be jsut the router connected Ethernet to external radios of another brand. Its possible that without Ethernet involved in between that they jsut get to the destination in order more frequently. Running per packet load balancing is much more reliable over circuits with fixed factors such as wired and fiber connections. In an RF enviroment its a much different situation. There are many factors in RF that can cause a packet to get delayed in delivery individually. For example an RF link that automatically adjusts modulation when errors occur. Because two RF links may transfer at different rates, the packets could arrive at different times. I did not specify previously, but when mentioning the risk of per packet load balancing, I was referring to using it within an RF environment. And I was referring to it being used for loadbalancing for a PtP link. Load balancing per packet between two different ISP transit providers, also could result in serious out of order packet problems, thus justifying per session load balancing. A PTP wired link, very well may be a preferred method to use per packet load balancing. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 8:22 PM Subject: RE: [WISPA] Redundant Connections I think it depends on the links involved and the remote termination, I currently run per packet round robin load balance across 3 T1's, no issue's with VoIP or VPN - of course the remote ends points are the same devices -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi Sent: Thursday, January 12, 2006 5:17 PM To: WISPA General List Subject: Re: [WISPA] Redundant Connections It important to consider the possibilties of packets arriving out of order. Some VPN protocols (deployed by corporate subscribers), will discard the packets when they arrive out of order, and is almost as bad as packet loss. And VOIP quality can be degrated as well. Per session is preferred. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Paul Hendry [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 3:22 PM Subject: RE: [WISPA] Redundant Connections Running a EoIP tunnel across both the T1 and your link you should be able to load-balance across both links for incoming and outgoing traffic by bonding both EoIP interfaces at the customer site and your Mikrotik box. I have done this in the past but it has been across a couple of wireless links with similar round trip delays. If you
Re: [WISPA] Redundant Connections
I beg to differ, we only have 2 installed and they work as advertised. John Thomas warped.terranova.net wrote: Stay away from the Xincom routers. They don't work and there is no support. Marlon K. Schafer (509) 982-2181 wrote: I was looking for something similar the other day. http://www.google.com/search?ie=UTF-8oe=UTF-8q=dual+wan+port+broadband+routerbtnG=Google+Search You'll likely want something of a higher quality. But it can be done. I think that wisps that don't have a backup offering are missing a very big boat today. Especially in the more urban markets. Marlon (509) 982-2181 Equipment sales (408) 907-6910 (Vonage)Consulting services 42846865 (icq)And I run my own wisp! 64.146.146.12 (net meeting) www.odessaoffice.com/wireless www.odessaoffice.com/marlon/cam - Original Message - From: John Scrivner [EMAIL PROTECTED] To: wireless@wispa.org Sent: Thursday, January 12, 2006 11:10 AM Subject: [WISPA] Redundant Connections A little feedback from the collective is appreciated here. I have a high school who has bought a connection from me but is also stuck with an old T1 circuit under contract for the next 3 years. They want both connections to be used all the time and for all traffic to automatically go through the working connection if one fails. Basically they want load balancing and failover. All addresses are nat'd private space IPs. I would think I should be able to do this with Mikrotik and/or Star OS but I do not know how. Your thoughts and or other suggestions are highly appreciated. If only failover or only load balance is possible then suggestions on that are welcome also. By the way, the T1 provider is not me and will likely not work with me unfortunately. We have to leave their network settings intact. Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Redundant Connections
Is there some reason you are not using CEF or inverse MUX? John Thomas [EMAIL PROTECTED] wrote: These are PTP wired links - 3 of them combined together - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi Sent: Friday, January 13, 2006 1:32 PM To: WISPA General List Subject: Re: [WISPA] Redundant Connections Have you used that backhaul to carry one of your high end business client's cisco VPNs? Most people don't even know how to detect that packets are getting sent out of order, and don't realize bandwidth is being wasted on packet drops. The reason is the only way to know is to go into the logs of the end user's VPN routers. Cisco VPN gear has some good tools to test the VPN and report the loss. It was the tech company of the subscriber, that it brought it to our attention and noticed it. And on $500 a month ARPU subs, if they see something like that, it means cancellation, if it can't be resolved. The reason is high end customers shoot for 100% not 99.9%. Andwhen things aren't perfect, the smarter techs realize that a less than perfect link could effect many different things that get troubleshooted over time, so the goal is to make it perfect to rule it out from ever being a factor. If fiber can make it perfect and wireless can't, wireless goes. That has been my experience. So my question to you is... when you use Mikrotik for Per Packet load balancing, does the Mikrotik, just guarantee that the packets arrive in order, or does the Mikrotik correct any errors in the packets getting received out of order, or are your links lucky to just be capable of delivering the packets in order? Technically, if a radio has a buffer or queue, its possible for the protocols to re-order the packets so they are back in order by the time they leave the other end of the Mikrotik router. At a small penalty of latency, re-ordering could be acheived. Its also possible that the end user VPN protocols could also already take care of that. I don't know enoguh about the VPN venders to know which protocols self-correct/guarantee correct packet ordering. When using the per packet load balancing of theMikrotik, is the Mikrotik also the radio, apposed to it be jsut the router connected Ethernet to external radios of another brand. Its possible that without Ethernet involved in between that they jsut get to the destination in order more frequently. Running per packet load balancing is much more reliable over circuits with fixed factors such as wired and fiber connections. In an RF enviroment its a much different situation. There are many factors in RF that can cause a packet to get delayed in delivery individually. For example an RF link that automatically adjusts modulation when errors occur. Because two RF links may transfer at different rates, the packets could arrive at different times. I did not specify previously, but when mentioning the risk of per packet load balancing, I was referring to using it within an RF environment. And I was referring to it being used for loadbalancing for a PtP link. Load balancing per packet between two different ISP transit providers, also could result in serious out of order packet problems, thus justifying per session load balancing. A PTP wired link, very well may be a preferred method to use per packet load balancing. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 8:22 PM Subject: RE: [WISPA] Redundant Connections I think it depends on the links involved and the remote termination, I currently run per packet round robin load balance across 3 T1's, no issue's with VoIP or VPN - of course the remote ends points are the same devices -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi Sent: Thursday, January 12, 2006 5:17 PM To: WISPA General List Subject: Re: [WISPA] Redundant Connections It important to consider the possibilties of packets arriving out of order. Some VPN protocols (deployed by corporate subscribers), will discard the packets when they arrive out of order, and is almost as bad as packet loss. And VOIP quality can be degrated as well. Per session is preferred. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Paul Hendry [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 3:22 PM Subject: RE: [WISPA] Redundant Connections Running a EoIP tunnel across both the T1 and your link you should be able to load-balance across both links for incoming and outgoing traffic by bonding both EoIP interfaces at the customer site and your Mikrotik box. I have done this in the past but it has been across a couple of wireless links with similar round trip delays. If you use per-packet load
RE: [WISPA] Redundant Connections
Running a EoIP tunnel across both the T1 and your link you should be able to load-balance across both links for incoming and outgoing traffic by bonding both EoIP interfaces at the customer site and your Mikrotik box. I have done this in the past but it has been across a couple of wireless links with similar round trip delays. If you use per-packet load balancing there may be issues with packets arriving out of order but if you do it per session it should work fine. With per session load balancing you won't get an aggregate throughput of both links with a single stream but should use both links if multiple streams are flowing. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: 12 January 2006 19:11 To: wireless@wispa.org Subject: [WISPA] Redundant Connections A little feedback from the collective is appreciated here. I have a high school who has bought a connection from me but is also stuck with an old T1 circuit under contract for the next 3 years. They want both connections to be used all the time and for all traffic to automatically go through the working connection if one fails. Basically they want load balancing and failover. All addresses are nat'd private space IPs. I would think I should be able to do this with Mikrotik and/or Star OS but I do not know how. Your thoughts and or other suggestions are highly appreciated. If only failover or only load balance is possible then suggestions on that are welcome also. By the way, the T1 provider is not me and will likely not work with me unfortunately. We have to leave their network settings intact. Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 11/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 11/01/2006 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Redundant Connections
Can mikrotik switch between per packet or per session load balancing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hendry Sent: Thursday, January 12, 2006 3:23 PM To: 'WISPA General List' Subject: RE: [WISPA] Redundant Connections Running a EoIP tunnel across both the T1 and your link you should be able to load-balance across both links for incoming and outgoing traffic by bonding both EoIP interfaces at the customer site and your Mikrotik box. I have done this in the past but it has been across a couple of wireless links with similar round trip delays. If you use per-packet load balancing there may be issues with packets arriving out of order but if you do it per session it should work fine. With per session load balancing you won't get an aggregate throughput of both links with a single stream but should use both links if multiple streams are flowing. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: 12 January 2006 19:11 To: wireless@wispa.org Subject: [WISPA] Redundant Connections A little feedback from the collective is appreciated here. I have a high school who has bought a connection from me but is also stuck with an old T1 circuit under contract for the next 3 years. They want both connections to be used all the time and for all traffic to automatically go through the working connection if one fails. Basically they want load balancing and failover. All addresses are nat'd private space IPs. I would think I should be able to do this with Mikrotik and/or Star OS but I do not know how. Your thoughts and or other suggestions are highly appreciated. If only failover or only load balance is possible then suggestions on that are welcome also. By the way, the T1 provider is not me and will likely not work with me unfortunately. We have to leave their network settings intact. Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 11/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 11/01/2006 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 01/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 01/11/2006 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Redundant Connections
I think it depends on the links involved and the remote termination, I currently run per packet round robin load balance across 3 T1's, no issue's with VoIP or VPN - of course the remote ends points are the same devices -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom DeReggi Sent: Thursday, January 12, 2006 5:17 PM To: WISPA General List Subject: Re: [WISPA] Redundant Connections It important to consider the possibilties of packets arriving out of order. Some VPN protocols (deployed by corporate subscribers), will discard the packets when they arrive out of order, and is almost as bad as packet loss. And VOIP quality can be degrated as well. Per session is preferred. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Paul Hendry [EMAIL PROTECTED] To: 'WISPA General List' wireless@wispa.org Sent: Thursday, January 12, 2006 3:22 PM Subject: RE: [WISPA] Redundant Connections Running a EoIP tunnel across both the T1 and your link you should be able to load-balance across both links for incoming and outgoing traffic by bonding both EoIP interfaces at the customer site and your Mikrotik box. I have done this in the past but it has been across a couple of wireless links with similar round trip delays. If you use per-packet load balancing there may be issues with packets arriving out of order but if you do it per session it should work fine. With per session load balancing you won't get an aggregate throughput of both links with a single stream but should use both links if multiple streams are flowing. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: 12 January 2006 19:11 To: wireless@wispa.org Subject: [WISPA] Redundant Connections A little feedback from the collective is appreciated here. I have a high school who has bought a connection from me but is also stuck with an old T1 circuit under contract for the next 3 years. They want both connections to be used all the time and for all traffic to automatically go through the working connection if one fails. Basically they want load balancing and failover. All addresses are nat'd private space IPs. I would think I should be able to do this with Mikrotik and/or Star OS but I do not know how. Your thoughts and or other suggestions are highly appreciated. If only failover or only load balance is possible then suggestions on that are welcome also. By the way, the T1 provider is not me and will likely not work with me unfortunately. We have to leave their network settings intact. Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 11/01/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 11/01/2006 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 01/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: 01/11/2006 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
