> Subject:
> Re: [44net] ampr-ripd update 1.14
> From:
> Marius Petrescu <marius(a)yo2loj.ro>
> Date:
> 09/21/2016 06:59 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>, "Ana C. Custura" <ana(a)netstat.org.uk>
>
>
> On my server running Debian 8 with kernel 3.16.0-4-amd64 it works
> without the '-r' flag.
>
> I actually wanted to remove that flag, but then it will break the
> scripts using it.
>
> I will make a new release that ignores that flag but still accepts it as
> parameter, but runs always in raw mode.
>
> I think this would be the proper approach.
Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour
in the past. You could of course keep the old code in there using some #ifdef option for those
that want to try it. Or introduce a new flag that switches from raw to multicast mode.
Raw mode always works, but in some cases may have some more CPU overhead. Not sure
if it is a noticable difference...
Rob
Hello,
Another update...
To keep everything as simple as possible and since this seem to work on
all systems, only raw socket mode is used (parameter -r is ignored, so
you don't have to change anything in your startup scripts).
Please note that no functionality has actually changed compared to 1.13,
so if you are happy with your current setup, no change is needed.
These changes are basically aimed to newcomers and will bring nothing
new to existing users.
Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.15.tgz
44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.15.tgz
or from GitHub:
git clone https://github.com/yo2loj/ampr-ripd.git
Have fun,
Marius, YO2LOJ
I think it is a good idea!
The password has often confused newcomers and made it harder to debug an intial setup.
How about the -r flag? Some time ago it became necessary for me to use it, apparently due
to changes in the kernel around multicasting. Is this still the current situation on the latest
Debian release? Or can ampr-ripd again work without -r?
Depending on this, it may be good to make some change in that default too.
Rob
Dear 44net group subscribers,
My name is Jakub Kramarz (SP0NGE) and I'm writting on behalf of Hackerspace
Kraków foundation (callsign SP9HACK) in Poland and I'd like to say hello to
this community :-)
We're a group of Linux and networking professionals, web and embedded
developers, security researchers and finally radioamatours
who has recently started our small, personal war to bring HAM radio back to
young people in our country.
In recent time, we've successfully:
- in cooperation with SP9KGP club, we held 3 comprehensive HAM radio
courses in Kraków, converting 40 enthusiasts to fully-fledged radio
operators (~ the number of Polish Amateur Radio Union's new members in
whole country),
- held an important role in securing radio communication during World
Youth Day 2016,
- operated multiple occasional stations (supporting Great Orchestra of
Christmas Charity, promoting Woodstock Festival Poland, ...),
- supported Radioreaktywacja (Radio Reactivation) initiative, who
"infects" the youngest with our hobby, by sharing hardware and knowledge,
- and, finally, contributed to numerous open source and open hardware
radio-related projects, eg. mcHF QRP firmware
I hope we'll be able also take a part in AMPRNet project and contribute
to digital communications over radio.
Serdecznie pozdrawiam / Best regards,
Jakub Kramarz
http://about.me/jkramarz
Sent from Makita TD090DWE impact driver
I'm on the 15th floor, 17 Miles from Tampa in St Petersburg, getting 20mbit/s
with some refraction through glass in the club here.
73's
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
> Please be aware the protocol is RIP44, **NOT** RIPv2. You must install
> and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d).
He uses a solution devised by Marius to work around that problem on a MikroTik router.
Rob
Ronen,
Please be aware the protocol is RIP44, **NOT** RIPv2. You must install
and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d).
See: http://wiki.ampr.org/wiki/RIP
73,
-Lynwood
KB3VWG
I tried to follows the instructions that written here
http://www.yo2loj.ro/hamprojects/ampr-gw-README.txtwww.yo2loj.ro<http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt>
www.yo2loj.ro
Setup example - please adapt ===== (ASSUMPTIONS: public ip is 89.122.215.236, router's ampr ip 44.182.21.254, WAN interface is PPPoE-In): You ...
I have a working tunnel on the router called UCSD (the tunnel interface have no IP adress)
my router is in bridge mode because it connect to cable modem before of it and sit on a DMZ address of the cable modem
It uses ether1-gateway interface as the 44 net address (4.138.1.1)
it uses ether2-master-local as the ip connected to the Cable modem (it uses 192.168.1.180 and default gateway to the cable modem ip which is 192.168.1.1)
I have no firewall working and i get no RIP routes
I have changed the tunnel interface name in the instructions to meet my interface name ..
on the VRF if i chose the tunnel interface the routes (or maybe the tunnel) stop and i cant access anymore the 44 net hosts from the outside world and i see no rip info
when i change the interface to the ether1-gateways (the one that have the 44 net address) the routes are ok the hosts are accessible from the outside world but i still not seeing any rip info
what is wrong ?
how can I debug it ?
if needed i can provide password to the router since it is accessible from the outside world
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
> Let's not forget...
> If you are unable to get RIP broadcasts for any reason, you can get the
> encap data from the portal as a json file via its API.
Sure, but please note that this does not solve the underlying problem of not being able to
receive unsolicited IPIP traffic I mentioned. When that is the reason (rather than inability
to follow installation and debugging instructions), the result will be a partially-working
gateway.
That gateway will be usable to contact other stations on the AMPRnet, but those other stations
will not be able to contact your systems. Outgoing connects are OK, incoming connects are not.
While some people my consider that a usable system, it is not a desirable situation.
The AMPRnet is more peer-to-peer than the internet in general, in that anyone is expected to
be both a participant and a consumer, not only a consumer as is usual on the internet.
Rob