Hi there
Is there any one that use Cisco as Gateway and use Policy routing for redirecting the 44 Net Traffic ?
I would like to get the Policy routing lines and the access list that belong to it
and also the static route command specially the one that refer to the default route and to the route to AMPR Gateway (the main 44 net router)
I am writing in the ampr wiki page how to set up a gateway with Cisco Router and i cant succeed to make my policy route work correct and dont want to publish example that doesn't work
Thanks in advance
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
> We are not in a real mesh. We are in a star topology from each node.
> A real mesh would mean that each node knows its neighbourgs (of course ) AND
> is also
> Able to handle traffic for its neighbourgs. That not the case if I'm right.
This is not right, the IPIP network (at least when properly implemented) is
a full mesh. All nodes can send traffic to all other nodes without having
to rely on a central node or a neighbor other than the destination.
Technically one can even send traffic to "the wrong node" and it might forward
it to the correct endpoint, but that is not guaranteed to work because not all
nodes allow that in their firewall rules.
The only thing that operates in a star fashion is the distribution of routing
information using RIP. It would be perfectly possible to setup a second node
that sends this same information, to cover the case where that central node
goes down and the other nodes gradually lose their routing info.
Rob
> And there comes nice feature
> of ampr-ripd program by Marius YO2LOJ:
> in case of missing or not broadcasted
> RIPv4 transmission, it keeps LASTLY
> received data, thus preserving routing table.
But of course only for completely lost transmissions.
Some time ago I was hunting a problem where I apparently had packet loss in RIP
transmissions, likely because they are sent in a big burst and may overflow buffers or exceed
rate limits somewhere. In that case I was randomly losing routes. I kind of fixed that by
increasing the timeout on routes to two hours (default was much lower, 15 minutes I think).
Also when something would break down that resulted in e.g. the RIP server sending only info
about 44.0.0.0/8 in a single packet and not all the other gateways (e.g. due to an empty
result from a database query due to some outside issue), the routes would still be lost.
It is always difficult to prevent all possible mishaps. Sending updates from different
sources will also not prevent all problems (after all there must be a single source of all
the info that is being distributed, or we would be faced with two portal systems and the
obligation to always register and update both).
Rob
I haven't heard back from Tal.
Is there anyone else who share the details on how to build the server
keys so that they work with lotw client based certificates?
Steve, KB9MWR
>Hello,
>The time here is 23:53 and i'm not next to my computer.
>Tomorrow I'll send configuration file for the openvpn server and one to the
>client, also i have script that generate key files & config files for
>clients.
>
>Sorry that i can't send them now.
>
>Regards,
>Tal.
>
>>Brian, thanks for the update.
>>
>>I know I asked before on how to build openvpn server keys and other
>>configuration details that will let a openvpn server I build work with
>>any hams lotw key clients that has previously documented:
>>
>>http://wiki.ampr.org/wiki/AMPRNet_VPN
>>
>>This is what I have built my own generated certificate authority,
>>server keys, with before using the
>>
>>./clean-all
>>./build-ca
>>./build-key-server server
>>./build-key client1
>>./build-dh
>>
>>I could really use something detailed on the values for the keys and
>>certificates parameters to make a server work with the lotw based keys
>>
>>Its not clear to me where one gets the the LoTW root CA certificate(s)
>>that need to be installed on the server. And I assume these are
>>Diffie hellman parameters?
>>
>>Steve
I wish there were. There was an explanation in the NOSIntro book by
Ian Wade which is out of print (but PDFs of it have shown up on line -
for example, there is something at QSL.net, and it's available used
from Amazon).
There really should be an article in the wiki but no one has written
it yet.
- Brian
On Wed, Mar 09, 2016 at 07:08:52PM -0500, Jerry Kutche (N9LYA) wrote:
> Is there any reading material online for NET44 and how it works..
> Documentation, maybe also for the Ip Coordinator to gain a grip.. Thanks...
I apologize to everyone been extremely busy and other things have
cropped up taking my time away from pulling the tnc out. I'll definitely
try to get it out this weekend and report back
thanks 73 leon
On 3/9/2016 7:10 PM, Assi Friedman wrote:
> Hi Leon:
> How much are you asking for the TNC? I assume this is the model consisting
> of the TNC + the 9600 G6RUH card?
> Thanks,
> Assi kk7kx
>
> -----Original Message-----
> From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On
> Behalf Of Leon Zetekoff
> Sent: Wednesday, March 02, 2016 4:23 PM
> To: 44net(a)hamradio.ucsd.edu
> Subject: Re: [44net] Making Packet Node with Pi ?
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> I have a paccomm 9600 which i really never used much way back when. I'd
> unload it if anyone wants it. please contact me off list.
>
> Leon WA4ZLW
>
> On 3/2/2016 6:43 PM, Jerry Kutche (N9LYA) wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>> Yes I have an SCS Tracker and yes it too can do 9600 baud..
>>
>> A lot of miss information going on here...
>>
>> That's two TNCs... Still in production.... Any more probably...
>>
>> 73 jerry n9lya
>>
>> -----Original Message-----
>> From: 44Net
>> [mailto:44net-bounces+n9lya=uronode.n9lya.ampr.org@hamradio.ucsd.edu]
>> On Behalf Of Bill Vodall
>> Sent: Wednesday, March 2, 2016 6:18 PM
>> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
>> Subject: Re: [44net] Making Packet Node with Pi ?
>>
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>>> I'd LOVE a 9K6+++ modem but they just don;t seem to be available.
>> SCS TNC tracker (http://www.p4dragon.com/en/Modems.html#widget4) and
>> the sound card modes such as DireWolf and UZ7HO now claim to support
>> 19,200 so 9600 should be doable.
>>
>> Bill, WA7NWP
>> _________________________________________
>> 44Net mailing list
>> 44Net(a)hamradio.ucsd.edu
>> http://hamradio.ucsd.edu/mailman/listinfo/44net
>>
>> _________________________________________
>> 44Net mailing list
>> 44Net(a)hamradio.ucsd.edu
>> http://hamradio.ucsd.edu/mailman/listinfo/44net
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
> Even APRS would be useful for folks that have 44net services to share.
> (Re-inventing bonjour/ZeroConf....) Perhaps this is a good reason to
> revive the HTPP convsers server (IRC clone) and use it for
> announcements like the DStar folks do with IRC technology.
I think there would be some slightly different approaches:
1. a written announcement like writing "I have this nice webserver" on convers
and requiring people to read the discussion there. of course this information
will get lost over time as other services are announced there.
2. a more static approach like putting all available services on a WiKi page that
can be edited by everyone.
(possibly in a hierarchic way with a page linking to other regional pages)
3. an automatic system like bonjour where every active service is regularly announcing
itself on the network and some page is dynamically updated when services
appear and disappear.
It certainly is something that is worthwhile to take up because it is a frequent
question when having new users. "what can I find on the net and where"
Rob
> Subject:
> Re: [44net] Is there raceroutre machine on 44 net available forpublic ?
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 03/09/2016 02:37 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> I've never found the cause of this; the rip sender would report protocol
> buffer overflows and never has. The UCSD network can easily take the
> amount of traffic that the rip transmissions constitute, and is not rate
> limited, so I am led to the conclusion that the loss must be along the
> transit path somewhere. Of course, being UDP inside IP, we don't get
> notified of in-transit packet drops so it remains a mystery why this
> is/was happening.
Well, when you send a few thousand UDP packets from a fast system on a gigabit
ethernet it does not really surprise me that there can be drops somewhere. Probably
not within the fast infrastructure of a university network, but maybe further along the
path. There could be queues on interfaces that are slower or loaded with other traffic
and that drop some of the packets.
At that time there was an obscure second transmission of the same RIP data and when
that was dropped, the situation appeared to improve.
The gateway where I was observing the problem is on a 100 Mbit line shared with several
other systems, maybe the drops were occurring locally due to some rate limiting in place
to achieve fair sharing of the bandwidth. I don't think I observed it on our gigabit
connected gateway, that was installed later.
You could put a small delay between sending the packets or after each small group
of packets. Also when you are sending the series of packets to all the gateways,
consider to make the inner loop by gateway and the outer loop by packet of the series,
not sending all packets for 1 gateway first and then the series to the next gateway.
The small delay could then be in the outer loop, and each gateway receives its
packets somewhat spaced.
Rob
> For a mesh this information gathering step can not be circumvented. Even if
> we change routing protocols, you still need to know your peers BEFORE being
> able to set up BGP or OSPF.
> And if you know your peers, you can know their subnets, too. So there is
> actually no need for a routing protocol running on a limited bandwidth
> network, because the information is already there, in your peering data.
Way back in the days of the previous packet radio network and NETCHL I started
to code a solution for this. I implemented multicast in NETCHL and created a
simple info protocol that multicasted information about the local system to
address 224.0.1.31 port 1535 (look them up in DNS and /etc/services!)
These announcements were sent with a TTL of 5 or so, so the neighborhood in
the then existing IP/AX.25/NETROM network learned some details about the nodes,
like the sysop call, the frequencies it was operating on, and the subnets it
was serving. The info could be displayed when connected to the NETROM.
The intention was to create an automatic IP routing protocol from there, and
then replace IP-over-NETROM and plain connects over NETROM by an automatically
routed IP network and a service to encapsulate plain user AX.25 connects
(user1-node1-node2-user2) in TCP/IP connects between the nodes. (replacing NETROM)
This never materialized, and in neighboring Germany a network was deployed
(Flexnet) that stuck to the AX.25 routing, and it became quite popular. The
author was not interested in IP at all. More and more operators wanted to switch
to that network so further development on NETCHL was mostly halted.
Of course, now this change has been made anyway (the network is IP with AX.25
running on top of it instead of under it), but quite some time has passed...
Of course we could again embark on such a project, but there is always the issue
of migration to a new method without breaking the whole network in the transition
phase.
Rob
> 3-rd option is interesting. Just that there will be alot of opposition
> from people worrying about 1 ping an hour should some multicast group
> announcement and subscription messages appear on the network...
No, it would work the other way around!
Someone sets up a service on amprnet where services can announce themselves
to be in the global directory of services.
Anyone running a service who would want to be in that directory sends regular
announcements to the central server, and those who do not want traffic simply
don't annouce themselves and won't have any unwanted traffic.
It can be really simple, any capable PHP or ASP programmer can write this in
"one rainy sunday afternoon" as the saying is here. Of course to get it
universally accepted is another matter.
Design would be like this:
Anyone who wants to announce their service makes a cron job that once per day
posts a file to the central server (XML, JSON, whatever) using a simple call to
wget or curl. The file contains the specification of the local services.
It can be called manually whenever the file has been edited for quick update.
The central server receives the posts (simple HTTP POST) and parses the data,
if valid it creates one or more database records with services and sets the
time it (last) received this announcement.
The same central server provides an overview page (with search and/or selection
options) that just dumps the contents of the database as a table. There is
some expiration interval (a small multiple of the post interval, e.g. 3 days)
after which records are deleted or no longer shown. This can also be a parameter
in the selection.
Bottleneck: convince everyone who provides some service on amprnet to write
the corresponding XML/JSON file and setting up the cron job. Providing a working
script callable by cron (i.e. the wget call with the proper parameters) will
help. An indication how to write a properly formatted file and/or a tool to do
this will also help.
It can be made a part of www.ampr.org, for example. Then we can direct anyone
there to lookup the service directory.
Rob