gmane.comp.security.firewalls.m0n0wall

Re: How often is the CF card written on normal operation?

Tim Nelson — 2008-12-01T17:10:00

Manuel or another dev can probably comment on this further in terms of specific writes... BUT, I can comment on real world usage. Nearly every flash device comes with a wear-leveling mechanism to prevent single-flash-sector burnout from happening as quickly. I've got a few installations of m0n0wall and pfSense on 256MB Sandisk CF cards that have been working flawlessly for nearly two years with semi-regular monthly changes/updates. One of my personal systems at home is using a similar card and has been working for the same amount of time but with constant (almost daily) updates, reflashes, etc. Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 ----- "Holger Rodriguez" roseng.ch> wrote:

Re: How often is the CF card written on normal operation?

Lee Sharp — 2008-12-01T17:07:33

That is it. Only on config changes and firmware upgrades. While running, it is not even mounted. Only reads on boot enough to load into ram. Lee

How often is the CF card written on normal operation?

Holger Rodriguez — 2008-12-01T17:02:26

Hi list, I have a net45xx board and my question is: How often is the card written to in normal operation? I understand, that the events: - upgrade software - changes rules needs writing. I am just curious, because I do want to loose the industrial CF card too early ;-) Cheers, Holger

Re: Performance difference between 1.235 and 1.3b15

Neil A. Hillard — 2008-11-30T16:10:35

Hi, In message <0vDVruFdGgIJFwaN< at >dana.internal.dana.org.uk>, Neil A. Hillard dana.org.uk> writes Does anyone have any ideas on this? I've done lots of searching for FreeBSD bugs relating to this particular problem and can't find anything! This bug is really killing Internet performance and I can't go back to 1.235 because I need to filter incoming ipsec connections! Any advice would be seriously appreciated! Many thanks in advance, Neil.

Re: AW: Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification

Chris Buechler — 2008-11-28T16:25:43

On Fri, Nov 28, 2008 at 11:05 AM, Michael Stecher cib.de> wrote: That's just to allow the connections to be initiated. Add rules in the GUI for anything else you need to pass. m0n0wall won't listen on proxy ARP IPs so you can't terminate IPsec connections using one.

AW: AW: Problems with IPSec Site to Site Tunnel: ignoreRESPONDER-LIFETIME notification

Michael Stecher — 2008-11-28T16:05:48

I've found out the problem: we're using a 10.0.0.0 Class A net on m0n0wall OPT interface (endpoint of the tunnel) but only a /29 subnet for the ipsec tunnel. For each subnet we've got one proxy ARP entry in m0n0wall configuration for the respective subnets gateway. In the near future we want to establish more of these subnets with a own ipsec tunnel to a specific customer so it's not possible to use current ipsec subnet for OPT interface. The subnets should be separated from each other (we do this with firewall rules and managed switches). M0n0wall adds ipsec firewall rules for OPT interface IP address (/32), but not for the specific tunnels. ... < at >18 pass out quick on vr2 proto udp from 10.0.0.1/32 port = isakmp to any keep frags < at >19 pass out quick on vr2 proto udp from 10.0.0.1/32 port = sae-urn to any keep frags < at >20 pass out quick on vr2 proto esp from 10.0.0.1/32 to any keep frags < at >21 pass out quick on vr2 proto ah from 10.0.0.1/32 to any keep frags ... < at >32 pass in quick on vr2 proto udp from any to 10.0.0.1/32 port = isakmp keep frags < at >33 pass in quick on vr2 proto udp from any to 10.0.0.1/32 port = sae-urn keep frags < at >34 pass in quick on vr2 proto esp from any to 10.0.0.1/32 keep frags < at >35 pass in quick on vr2 proto ah from any to 10.0.0.1/32 keep frags Is there an easy reason to add those rules for our subnets (proxy ARP) gateways? I've tried with and ipf -f but this is really exhausting and I think not very fail-safe too. Have many thanks for your help. Kind regards, Michael -----Ursprüngliche Nachricht----- Von: Eric Boudrand [mailto:eric< at >boudrand.net] Gesendet: Mittwoch, 26. November 2008 23:12 An: m0n0wall< at >lists.m0n0.ch Betreff: Re: AW: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification Hi, draft-ietf-ipsec-nat-t-ike-07... The RFC 3947 was published in January 2005 and it is the reference document. The firmware of the Cisco does not implement it. Anyway, that is details. There are no big difference between this draft and the RFC. I think the remote gateway dropped the response from the racoon. You should take a look to the Cisco logs. I do not like racoon logs because some basic information are missing. In main mode you have 6 exchanges and in Quick Mode 3 exchanges. You can deduce very easily configuration error from the point at which the negotiation failed. In this log, a packet is retransmitted in phase 1, but which one ? Packet with Security Association payload (1rst and 2nd exchanges) ? Or packet with ID payload (5th and 6th exchanges) ? Is there a problem when using UDP port 4500 in the 5th and 6th exchanges ? I do not think it is a configuration issue, because it worked. Cisco logs will be helpful. Regards. - Éric --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall-unsubscribe< at >lists.m0n0.ch For additional commands, e-mail: m0n0wall-help< at >lists.m0n0.ch

Re: Minor typos in System: Group Manager page

mtnbkr — 2008-11-27T06:22:46

If you are telling me (looking at the timestamp on that dev-list entry) that I sent you my report the SAME day it was fixed and reported back to the dev list, then yes - That IS a coincidence. I noticed this and pretty much immediately reported it today. :) Cheers & keep up the great work! -- Bill Arlofski Reverse Polarity, LLC

Re: AW: Problems with IPSec Site to Site Tunnel: ignoreRESPONDER-LIFETIME notification

Eric Boudrand — 2008-11-26T22:11:55

Hi, draft-ietf-ipsec-nat-t-ike-07... The RFC 3947 was published in January 2005 and it is the reference document. The firmware of the Cisco does not implement it. Anyway, that is details. There are no big difference between this draft and the RFC. I think the remote gateway dropped the response from the racoon. You should take a look to the Cisco logs. I do not like racoon logs because some basic information are missing. In main mode you have 6 exchanges and in Quick Mode 3 exchanges. You can deduce very easily configuration error from the point at which the negotiation failed. In this log, a packet is retransmitted in phase 1, but which one ? Packet with Security Association payload (1rst and 2nd exchanges) ? Or packet with ID payload (5th and 6th exchanges) ? Is there a problem when using UDP port 4500 in the 5th and 6th exchanges ? I do not think it is a configuration issue, because it worked. Cisco logs will be helpful. Regards. - Éric

Re: Minor typos in System: Group Manager page

Manuel Kasper — 2008-11-26T17:59:36

Have a look at this: Coincidence! :) - Manuel

Minor typos in System: Group Manager page

mtnbkr — 2008-11-26T15:30:47

Manuel... Not a high priority in the grand scheme of things, but I just noticed a minor issue in the output of the "System: Group Manager" page. It looks like text from somewhere else is being pulled in for the "Description" column for the "Firewall Rules" and "Firewall Rules Edit" lines: --[snip]-- Firewall: Traffic shaper: Queues firewall_shaper_queues.php Firewall: Traffic shaper: Rules firewall_shaper.php Firewall: ipv6enabled( firewall_rules.php Firewall: ipv6enabled( firewall_rules_edit.php Hidden: Detailed Status status.php Hidden: Exec exec.php --[snip]-- The same symptom exists for the "System Routes" and "System Routes Edit" lines: --[snip]-- System: Group manager system_groupmanager.php System: ipv6enabled( system_routes_edit.php System: ipv6enabled( system_routes.php VPN: IPsec: CAs vpn_ipsec_ca.php VPN: IPsec: Edit CA certificate vpn_ipsec_ca_edit.php --[snip]-- This is on 1.3b15, I have not looked elsewhere. Cheers! -- Bill Arlofski Reverse Polarity, LLC

AW: Problems with IPSec Site to Site Tunnel: ignoreRESPONDER-LIFETIME notification

Michael Stecher — 2008-11-26T10:26:15

Hello Eric, you can find my logs in separated mail to mailinglist. This is our first tunnel between m0n0wall and cisco. We've got some stable tunnels between some m0n0walls on other hardware without any problems. I think we can send IKE und ESP. The peer told me that ESP, UDP 500 and UDP 4500 is opened for us. Have many thanks. Kind regards, Michael (133) -----Ursprüngliche Nachricht----- Von: Eric Boudrand [mailto:eric< at >boudrand.net] Gesendet: Mittwoch, 26. November 2008 10:24 An: m0n0wall< at >lists.m0n0.ch Betreff: Re: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification Hello, What do you have in the logs ? You can't send IKE packets or ESP packets ? You can find details about this notification in RFC 2407 section 4.5.4. RESPONDER-LIFETIME notification is sent by the responder (that is the Cisco) when "the initiator offers an SA lifetime longer than the responder is willing to accept". The raccon is ignoring the fact the Cisco cannot deal with its lifetime. Do you have several tunnels on the CISCO ? Regards. Éric --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall-unsubscribe< at >lists.m0n0.ch For additional commands, e-mail: m0n0wall-help< at >lists.m0n0.ch

AW: Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification

Michael Stecher — 2008-11-26T10:22:33

Hello! I've checked the lifetime settings again and anything seems to be ok. The peer admin told me that now the correct lifetime is transmitted and their cisco will also handle shorter lifetime cycles. So maybe the problem is not the lifecycle?!? I've made some other detection: if the peer side starts the tunnel first I've got following log entry: Nov 26 10:26:48 racoon: NOTIFY: the packet is retransmitted by x.x.x.x[500]. Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03 Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07 Nov 26 10:26:38 racoon: INFO: begin Identity Protection mode. Nov 26 10:26:38 racoon: INFO: respond new phase 1 negotiation: x.x.x.x[500]<=>x.x.x.x[500] It look like the peer didn't receive a needed packet from our side, right? Here is the complete log. Successful start on 09:05, problems on 09:54, try to reconnect from per on 10:26 and restart tunnel from our side on 10:52. Nov 26 10:53:01 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.176/29[0] x.x.x.249/24[0] proto=any dir=out Nov 26 10:53:01 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.91/32[0] x.x.x.99/24[0] proto=any dir=out Nov 26 10:53:01 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.249/24[0] x.x.x.176/29[0] proto=any dir=in Nov 26 10:53:01 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.99/24[0] x.x.x.91/32[0] proto=any dir=in Nov 26 10:53:01 racoon: INFO: x.x.x.91[500] used for NAT-T Nov 26 10:53:01 racoon: INFO: x.x.x.91[500] used as isakmp port (fd=12) Nov 26 10:53:01 racoon: INFO: x.x.x.13[500] used for NAT-T Nov 26 10:53:01 racoon: INFO: x.x.x.13[500] used as isakmp port (fd=11) Nov 26 10:53:01 racoon: INFO: x.x.x.1[500] used for NAT-T Nov 26 10:53:01 racoon: INFO: x.x.x.1[500] used as isakmp port (fd=10) Nov 26 10:53:01 racoon: INFO: x.x.x.177[500] used for NAT-T Nov 26 10:53:01 racoon: INFO: x.x.x.177[500] used as isakmp port (fd=9) Nov 26 10:53:01 racoon: INFO: 127.0.0.1[500] used for NAT-T Nov 26 10:53:01 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=8) Nov 26 10:53:01 racoon: INFO: Reading configuration from "/var/etc/racoon.conf" Nov 26 10:53:01 racoon: INFO: < at >(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) Nov 26 10:53:01 racoon: INFO: < at >(#)ipsec-tools 0.7 (http://ipsec-tools.sourceforge.net) Nov 26 10:53:00 racoon: INFO: racoon shutdown Nov 26 10:52:59 racoon: INFO: caught signal 15 Nov 26 10:41:08 racoon: ERROR: x.x.x.3 give up to get IPsec-SA due to time up to wait. Nov 26 10:40:38 racoon: INFO: initiate new phase 2 negotiation: x.x.x.1[500]<=>x.x.x.3[500] Nov 26 10:27:28 racoon: ERROR: phase1 negotiation failed due to time up. 7c9ba353a31f1d4b:2cd4fca1d18f4037 Nov 26 10:27:28 last message repeated 4 times Nov 26 10:26:48 racoon: NOTIFY: the packet is retransmitted by x.x.x.3[500]. Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03 Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07 Nov 26 10:26:38 racoon: INFO: begin Identity Protection mode. Nov 26 10:26:38 racoon: INFO: respond new phase 1 negotiation: x.x.x.13[500]<=>x.x.x.3[500] Nov 26 09:54:30 racoon: ERROR: x.x.x.3 give up to get IPsec-SA due to time up to wait. Nov 26 09:54:00 racoon: INFO: IPsec-SA expired: ESP/Tunnel x.x.x.3[0]->x.x.x.1[0] spi=4350059(0x42606b) Nov 26 09:54:00 racoon: INFO: initiate new phase 2 negotiation: x.x.x.1[500]<=>x.x.x.3[500] Nov 26 09:54:00 racoon: INFO: IPsec-SA expired: ESP/Tunnel x.x.x.1[0]->x.x.x.3[0] spi=2846965402(0xa9b13e9a) Nov 26 09:05:59 racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.1[500]->x.x.x.3[500] spi=2846965402(0xa9b13e9a) Nov 26 09:05:59 racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.3[0]->x.x.x.1[0] spi=4350059(0x42606b) Nov 26 09:05:59 racoon: WARNING: attribute has been modified. Nov 26 09:05:59 racoon: WARNING: ignore RESPONDER-LIFETIME notification. Nov 26 09:05:59 racoon: INFO: initiate new phase 2 negotiation: x.x.x.1[500]<=>x.x.x.3[500] Nov 26 09:05:58 racoon: INFO: ISAKMP-SA established x.x.x.1[500]-x.x.x.3[500] spi:4ac5128ca16fa8be:f05900aec4be625c Nov 26 09:05:58 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt Nov 26 09:05:58 racoon: INFO: received Vendor ID: DPD Nov 26 09:05:58 racoon: INFO: received Vendor ID: CISCO-UNITY Nov 26 09:05:57 racoon: INFO: begin Identity Protection mode. Nov 26 09:05:57 racoon: INFO: initiate new phase 1 negotiation: x.x.x.1[500]<=>x.x.x.3[500] Nov 26 09:05:57 racoon: INFO: IPsec-SA request for x.x.x.3 queued due to no phase1 found. Nov 26 09:05:47 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.176/29[0] x.x.x.249/24[0] proto=any dir=out Nov 26 09:05:47 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.91/32[0] x.x.x.99/24[0] proto=any dir=out Nov 26 09:05:47 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.249/24[0] x.x.x.176/29[0] proto=any dir=in Nov 26 09:05:47 racoon: ERROR: such policy already exists. anyway replace it: x.x.x.99/24[0] x.x.x.91/32[0] proto=any dir=in Nov 26 09:05:47 racoon: INFO: x.x.x.91[500] used for NAT-T Nov 26 09:05:47 racoon: INFO: x.x.x.91[500] used as isakmp port (fd=12) Nov 26 09:05:47 racoon: INFO: x.x.x.13[500] used for NAT-T Nov 26 09:05:47 racoon: INFO: x.x.x.13[500] used as isakmp port (fd=11) Nov 26 09:05:47 racoon: INFO: x.x.x.1[500] used for NAT-T Nov 26 09:05:47 racoon: INFO: x.x.x.1[500] used as isakmp port (fd=10) Nov 26 09:05:47 racoon: INFO: x.x.x.177[500] used for NAT-T Nov 26 09:05:47 racoon: INFO: x.x.x.177[500] used as isakmp port (fd=9) Nov 26 09:05:47 racoon: INFO: 127.0.0.1[500] used for NAT-T Nov 26 09:05:47 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=8) Nov 26 09:05:47 racoon: INFO: Reading configuration from "/var/etc/racoon.conf" Nov 26 09:05:47 racoon: INFO: < at >(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) Nov 26 09:05:47 racoon: INFO: < at >(#)ipsec-tools 0.7 (http://ipsec-tools.sourceforge.net) Nov 26 09:05:46 racoon: INFO: racoon shutdown Nov 26 09:05:45 racoon: INFO: caught signal 15 And here is my racoon.conf: path pre_shared_key "/var/etc/psk.txt"; path certificate "/var/etc"; remote x.x.x.3 { exchange_mode main; my_identifier address "x.x.x.176"; peers_identifier address x.x.x.3; initial_contact on; support_proxy on; proposal_check obey; dpd_delay 0; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 5; lifetime time 86400 secs; } lifetime time 86400 secs; } sainfo address x.x.x.176/29 any address x.x.x.249/24 any { encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; lifetime time 3600 secs; } The peer is a customer of our company. At the moment I haven't this config. Many thanks to all! Kind regards, Michael -----Ursprüngliche Nachricht----- Von: Christopher M. Iarocci [mailto:iarocci< at >eastendsc.com] Gesendet: Mittwoch, 26. November 2008 01:00 An: Michael Stecher Cc: m0n0wall< at >lists.m0n0.ch Betreff: Re: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification Michael Stecher wrote: I have 4 tunnels set up from my m0n0wall (also 1.3b15) to Cisco routers that are reliable and stay up 24/7. However, I've had the problem you are having and it was always a mis-match of the lifetime setting. Be 110% sure these numbers match or you will be constantly trying to figure out why they come up then drop. For reference, I have my lifetime setting on 3600 seconds. However, my setting may not be what you need/want. I am simply stating that setting to demonstrate that what you put in that setting does matter. I know that 28800 is the default setting on a Cisco and it appears you probably haven't changed that to match your 86400 you have on the m0n0wall. Try setting the m0n0wall to 28800. If you could show us your configs on both sides we may be able to help further. Chris P.S. Those racoon warnings are just that, warnings. I have the identical warnings with stable tunnels.

Re: Problems with IPSec Site to Site Tunnel: ignoreRESPONDER-LIFETIME notification

Eric Boudrand — 2008-11-26T09:24:15

Hello, What do you have in the logs ? You can't send IKE packets or ESP packets ? You can find details about this notification in RFC 2407 section 4.5.4. RESPONDER-LIFETIME notification is sent by the responder (that is the Cisco) when "the initiator offers an SA lifetime longer than the responder is willing to accept". The raccon is ignoring the fact the Cisco cannot deal with its lifetime. Do you have several tunnels on the CISCO ? Regards. Éric

Re: Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification

Christopher M. Iarocci — 2008-11-25T23:59:41

I have 4 tunnels set up from my m0n0wall (also 1.3b15) to Cisco routers that are reliable and stay up 24/7. However, I've had the problem you are having and it was always a mis-match of the lifetime setting. Be 110% sure these numbers match or you will be constantly trying to figure out why they come up then drop. For reference, I have my lifetime setting on 3600 seconds. However, my setting may not be what you need/want. I am simply stating that setting to demonstrate that what you put in that setting does matter. I know that 28800 is the default setting on a Cisco and it appears you probably haven't changed that to match your 86400 you have on the m0n0wall. Try setting the m0n0wall to 28800. If you could show us your configs on both sides we may be able to help further. Chris P.S. Those racoon warnings are just that, warnings. I have the identical warnings with stable tunnels.

Re: DNS behavior

Lee Sharp — 2008-11-25T21:52:32

And when that cache hangs, it gets VERY misleading! :) Give it a try, for me. :) Lee

Re: DNS behavior

Milek Hansen — 2008-11-25T21:33:16

< at >Lee Sharp you don`t need the dns-client service for dns queries to work. dns-client only caches the queries. The description in services.msc is somewhat misleading. 2008/11/25 Lee Sharp hal-pc.org>

Re: OT: wireless PTP

Tim Nelson — 2008-11-25T21:23:21

Good luck! Wireless is hard stuff to get right sometimes. Even a properly engineered PtP link can fail... Even though it *is* OT, please post if you have further problems. Some of us like the variance in topic... :-) Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 ----- "David Burgess" gmail.com> wrote:

Re: OT: wireless PTP

David Burgess — 2008-11-25T21:18:30

Thanks for all the great info. I ordered the Ubiquiti Power Station, as it was rated to -40 C, while the others were rated to -20 or 0 in some cases. The Nano stations would have no doubt sufficed in this particular network, and I could have rigged up some heat, but being 1100 km away (I'm doing this for family), I need it to set up right the first time, and just keep working when the east wind blows. db

RE: OT: wireless PTP

Rhon-Kaniel Bramwell — 2008-11-25T18:11:55

I think you need to look into some UBNT equipment, NS5's 5.8Ghz Should do the job great! Rhon -----Original Message----- From: David Burgess [mailto:apt.get< at >gmail.com] Sent: Tuesday, November 25, 2008 1:02 PM To: Monowall User List Subject: Re: [m0n0wall] OT: wireless PTP On Tue, Nov 25, 2008 at 8:13 AM, Lee Sharp hal-pc.org> wrote: Thanks for all the great tips. I would rather keep my radio indoors and put just the antenna outdoors. Is there a reason this doesn't seem to be done? Is antenna cabling expensive? Is line loss too great over distances? I realize it's easier to run cat5 than thick coax for sure, but winter is long and cold here and it seems to me I could reduce my risks and my costs significantly by keeping my electronics indoors and running 30 meters of antenna wire. But like I said, this is an option that people don't appear to be talking about. What is the reason for that? db --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall-unsubscribe< at >lists.m0n0.ch For additional commands, e-mail: m0n0wall-help< at >lists.m0n0.ch __________ NOD32 3637 (20081124) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com

Re: OT: wireless PTP

Tim Nelson — 2008-11-25T18:03:43

Typically the power loss on 30ft of antenna cabling will be quite a bit which means you'll probably need to invest in an amplifier. Why not keep that loss to a minimum by running Cat5 (Data and power)? Also, you can find some great gel filled outdoor UV resistant cabling that isn't overly expensive. If you're also concerned about the temperatures affecting your radio, get a good radio that's designed for outdoor use or put the radio into an enclosure that has a heating element. They sound odd but work very reliably in the installations I've used them on. Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 ----- "David Burgess" gmail.com> wrote:

Re: OT: wireless PTP

David Burgess — 2008-11-25T18:01:55

Thanks for all the great tips. I would rather keep my radio indoors and put just the antenna outdoors. Is there a reason this doesn't seem to be done? Is antenna cabling expensive? Is line loss too great over distances? I realize it's easier to run cat5 than thick coax for sure, but winter is long and cold here and it seems to me I could reduce my risks and my costs significantly by keeping my electronics indoors and running 30 meters of antenna wire. But like I said, this is an option that people don't appear to be talking about. What is the reason for that? db