We are finally setting up the gateway at N2MO - the plan is to use an
existing Cisco 2811 Integrated Services Router for AMPRnet.
After reading the config notes at:
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Cisco_Routers , I had
several questions
1) For the FQDN of the commercial internet connection, is there an
accepted naming convention ?
2) Our 2811 ISR has both serial and Ethernet WIC (WIC-2T and
HWIC-2FE). Is there any benefit to using the serial connection?
73
Martin A Flynn / W2RWJ
Ocean-Monmouth Amateur Radio Club, Inc
2300 Marconi Road
Wall Township, NJ 07719
Tel: +01 732-428-7373
Email: mflynn(a)n2mo.org
Visit us online at: www.n2mo.org
Hi there
I started to config my Bullet2 to be access point for delivering the AMPRNET to the HAMS and saw that there is tunnel and ipip in the commands
Does it mean it support by default IPIP tunneling and can serve as Gateway ?
I couldn't succeeded to find the correct syntax of the command whatever i have done it gave me error that something is "garbage"
Please Advice
Thanks Forward
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
On our gateway system we try to offer tunneling technologies that are easily usable on the
equipment the users have available. For example, we deployed OpenVPN because it is so
easy for the users to install and use.
For use on routers like MikroTik, IPsec is more convenient. We offer IPsec tunnels for subnets
and individual addresses, in AH and ESP mode, and the latter also over NAT-T. A number of
users have such a tunnel working over NAT-T without problem. We use setkey/racoon.
To connect a radio network router that uses BGP to provide it with a fallback in case the radio
network is down or when it has not yet been deployed, it is more convenient to use a GRE tunnel
over IPsec transport. BGP can then consider the GRE tunnel as an alternative path.
This is easily configurable on a MikroTik in ESP mode, but AH is also possible.
(AH mode uses less CPU because there is no encryption, only authentication)
After deploying some GRE over IPsec transport connections, of course the first site appeared
who has the MikroTik router behind a NAT router which cannot be removed.
GRE over IPsec transport does not work over NAT.
So, I researched the matter and found that there are examples of the use of GRE over
IPsec tunnel mode, which in turn can operate over NAT-T (when ESP is used).
Of course terribly inefficient in terms of header size, but it should work.
Ok, back to the configuration drawing board and implement this on the Linux gateway.
I cannot get it to work. The whole IPsec tunnel is established correctly (of course, this already
worked), I can add the GRE interface and make it use the tunnel, but when GRE traffic
comes in on the IPsec tunnel it does not appear on the GRE interface. Which worked fine when
using IPsec transport instead of tunnel.
When I ping from the gateway to a connected test router (MikroTik), I can see the pings arrive
on the GRE interface there, being returned to the gateway, arrive as ESP-over-UDP, matched
in the firewall, sent to an iptables entry that matches on protocol 47, I can even dump them
to the log with -j LOG where they appear:
Mar 5 18:23:43 gw-44-137 kernel: [17858.781986] IN=eth0 OUT= MAC=00:0c:29:cc:5a:2a:dc:38:e1:f6:2f:f0:08:00 SRC=10.0.1.43 DST=10.11.12.13 LEN=148 TOS=0x00 PREC=0x00 TTL=255 ID=81 DF PROTO=47
The corresponding GRE tunnel with these addresses is present, it works in the outgoing direction,
but not incoming.
My guess is that it is a problem to match the SRC and DST addresses in an IPsec tunnel packet
to the remote and local addresses of a GRE interface, and it never finds its way. Probably the wrong
addresses are matched, the outside rather than the inside addresses of the IPsec tunnel.
Does anyone have experience with this and know what might be the problem and how it can be fixed?
The Linux kernel is version 3.2.0 (Debian Wheezy) in case that matters.
Rob
Hi there
Has anyone try or doing a Gateway with home router (like TP-LINK) that he has Flashed it to work With OpenWRT ?
If yes how is are results ?can it hold the 520 Gateways routes on its memory and still function ?
Please Advice
Thanks Forward
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
Hello,
I added 2 new gateways yesterday afternoon (static public commercial IP
addresses, no firewall) but I'm still waiting to receive RIP broadcasts
on those IP addresses.
I think to remember that new gateway IP addresses are only added to the
broadcast list every few hours. How can I verify that my gateways
actually did make it into the list?
73 de Marc, LX1DUC
Hi there
Is there a way to have a Packet Node with Pi (or any other small size solution that will not require a PC) ?
If yes How do I connect TNC (serial port) to PI is the Pi support USB to serial external interface (like the profilic ones) ?
Or (preferred) something can be done to do the TNC on Sound card (can be an External sound card that connect to the USB of the PI)
Please Advice
Thanks Forward
Ronen - 4Z4ZQ
jttp://www.ronen.org
For anyone interested in considering a STA you should go to this site:
https://apps.fcc.gov/oetcf/els/forms/STANotificationPage.cfm
STAs are only good for six months, but they can be extended by filing
another application. The filing fee is $60, and you will need your FRN
and password to file it. It is not a simple process, but it is doable.
You should have a narrative explanation of what you propose to do in
PDF format to upload as an attachment as well as filling out the form
completely.
________________________________
>Is this how STAs now work?
>
>When we were implementing packet radio in Canada in the late seventies,
>American hams claimed that the STA process was slow and difficult, the
>equivalent to getting an act through Congress that was difficult and slow
>
>Was this real at the time? Is it better now?
>
>I may have to go through this to push a new mesh protocol through as STA
>(yah, gotta do my local exams first!) and what to know what I'll be up
>against.
>
>- Richard
>
>
>On 3/4/16 10:30 PM, ve1jot wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>> +1
>>
>> On 16-03-04 08:16 PM, kd6oat wrote:
>>> (Please trim inclusions from previous messages)
>>> _______________________________________________
>>> Regarding an STA for higher data rates experimentation: I would think a
>>> well written proposal accompanied by the signature of a number of
>>> licensed
>>> operators willing to participate in experiments would go a long way.
>>> Count
>>> me in as one who would be willing to sign on.
>>> Ken - KD6OAT
>>>
>>> On Thu, Mar 3, 2016 at 11:22 AM, Brian Kantor <Brian at ucsd.edu> wrote:
>>>
>>>> (Please trim inclusions from previous messages)
>>>> _______________________________________________
>>>> In the FCC arena, one of the better ways to get technical restrictions
>>>> removed is to apply for and operate under an STA - Special Temporary
>>>> Authority, a document from the FCC that basically allows you to operate
>>>> an exception to the normal rules. Typically the only requirement is
>>>> that you make a good case for it technically and that you write up a
>>>> report afterwards. In the past, STAs have been the basis for
>>>> changes to
>>>> the rules. Someone who writes well may want to consider submitting
>>>> one to
>>>> allow higher data rates based solely on bandwidth and then
>>>> experimenting
>>>> with it.
>>>>
>>>> Another possibility is to apply for a Experimental Radio Service
>>>> license
>>>> which basically allows you to do just about anything if you can make a
>>>> good case for it. They used to be a little expensive and they require
>>>> a written report on what you found out with your experiments but it
>>>> does
>>>> allow nearly anything you can think of.
>>>> - Brian
> Beyond what others have mentioned like the TNC-Pi (nice kit), using a $7
> USB soundcard and Direwolf will provide superior decodes.
Yes, I wonder why on earth they use a hardware AFSK modem chip in that design...
I can see a place for an adapter board that provides PTT keying, possibly isolated
audio interface, etc for the Pi, but it should always just do A/D and D/A conversion
of the audio and leave the processing to software. That works so much better, and
it enables the development of alternative modem designs without having to change
the hardware every time.
Rob
There were some attempts/news a couple years ago to modernize this:
http://www.arrl.org/news/arrl-files-symbol-rate-petition-with-fcchttp://www.arrl.org/news/arrl-s-symbol-rate-petition-nears-top-of-fcc-s-mos…
The problem is it takes a very long time for the FCC to act on pretty
much anything ham radio related.
It took 3 years for the Mototrbo/TDMA rule change.
Prior to that I recall the spread spectrum automatic power control
rule change took about half that.
I agree though, a STA is a good idea to make a case and bring the
issue to the forefront.
>In the FCC arena, one of the better ways to get technical restrictions
>removed is to apply for and operate under an STA - Special Temporary
>Authority, a document from the FCC that basically allows you to operate
>an exception to the normal rules. Typically the only requirement is
>that you make a good case for it technically and that you write up a
>report afterwards. In the past, STAs have been the basis for changes to
>the rules. Someone who writes well may want to consider submitting one to
>allow higher data rates based solely on bandwidth and then experimenting
>with it.
>
>Another possibility is to apply for a Experimental Radio Service license
>which basically allows you to do just about anything if you can make a
>good case for it. They used to be a little expensive and they require
>a written report on what you found out with your experiments but it does
>allow nearly anything you can think of.
>- Brian
>
>
>On Thu, Mar 03, 2016 at 07:42:09PM +0200, Demetre - SV1UY wrote:
>> Not good for US though, "thanks" to FCC's 300baud symbol rate restrictions of HF.
portal.ampr.org and www.portal.ampr.org are listed (as the only hosts in ampr.org) as vulnerable
to the DROWN attack published today. it is not a high-priority issue but it is a good idea to have
a look and fix the software and/or settings.
Rob*
*
