> Subject:
> [44net] ripv2
> From:
> Brian Rogers <n1uro(a)n1uro.ampr.org>
> Date:
> 09/01/2013 12:12 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> There appears to be at least one valid route missing in the rip
> broadcasts. aa6hf is not received via rip however it is using the munge
> script... is there an issue in the portal?
I receive the routes from RIP and his route is OK.
44.17.0.128/31 via 67.49.91.65 dev tunl0 proto ampr-ripd onlink
Greetings,
I'm again planning the setup of a gateway here at the Balogna Capitol,
much to the wonderment of a few. Prelim's are done, ie: static ip,
registering in the portal, etc. Now I'm back to a place I've been
before, automating the startup, and configuration. Something I'm
surprised we haven't overcome with a gui by now, and unfortunately way
above my pay scale.:)
I did have this working before, so I'm hoping with little changes I'll
have the init.d scripts and all updated. I'll certainly make them
available, maybe on the wiki when I'm done. I realize that it will take
changes to make them work on other distros. Maybe it's time to see what
the commonalities are, in hopes of developing a standard config tool.
I'd certainly like to take this off list till there is something worth
showing.
Anyone interested?
Best regards,
Willie, WJ3G
Someone with a Microtik is evidently broadcasting on the AMPRnet tunnels.
Dest address 255.255.255.255
Source address 0.0.0.0
UDP port 5678
Please stop!
Michael
I'd like a copy too.
Is there anyway we have have a centralized place for stuff like this?
I have to admit that wiki's aren't really for me. Editing them I find painful.
And there are a number of scripts and software packages that I have
been trying to archive.
--
And a couple messages ago the question was asked "Has anyone tried to
use transverters from 2.4GHz to 432 Mhz?" Does such a transverter
exist?
A $40 Ubiquiti 2 GHz bullet coupled with a few watt (2.4 Ghz to 432
MHz) transverter might work better than a $170 mini PCI radio card
combined with a $85 router board and all that.
http://www.xagyl.com/store_us/product.php?productid=31
There are some impressive 802.11 networks being built by European
amateurs. There also seems to be quite a lot of talent with microwave
design over there.
Hi Hessu,
I am trying to get rip44d working on my Raspberry Pi.
For some reason, I cannot get it to receive the 44.0.0.1 -> 224.0.0.9 transmissions.
The socket is listening on port 520, when I trace tunl0 I see the packets arriving
every 5 minutes, but the rip44d (running with -v) remains absolutely silent.
Any idea what that can be?
I saw that there is a 2nd set of transmissions, from 169.228.66.251 to my internet
address, oddly from port 520 to port 34348.
With some small changes to rip44d, to change the source address check and the
port number, and to remove the multicast handling, it receives those packets
perfectly and the routes are added.
Do you have any idea what this can be? The Pi is running Linux 3.6.11+
(raspbian wheezy), and I installed the perl modules just as you explain on the wiki.
Of course I could make my changes conditional and add a flag to listen to this
alternate transmission, but I don't know about the status (maybe they will stop
sometime?). It could be better to fix the problem, if I knew how...
73,
Rob PE1CHL
> Subject:
> Re: [44net] rip44d
> From:
> "Kutche, Jerry (Mitchell) USA" <JKutche(a)lehighcement.com>
> Date:
> 08/30/2013 12:40 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>, Heikki Hannikainen <hessu(a)hes.iki.fi>
>
>
> Is your pi in the DMZ? I had to do that with HP Linux BOX a non-pi.... Might try that?
>
> Jerry Kutche
> Electrical Supervisor
My Pi is in a datacenter, directly connected to Internet. Not behind a NAT router, that is.
I have not further researched the matter, as I have solved it by using ampr-ripd and not using
multicast. I think there is something missing or not configured that is related to multicast.
The kernel config is:
CONFIG_IP_MULTICAST=y
# CONFIG_IP_MROUTE is not set
Multicast routing is not enabled. On my home PC (SuSE Linux), it is enabled.
Maybe this is a requirement even for the reception of multicast datagrams.
Rob
I noticed that there are some ham projects of developing transverters
from 2.4 GHz to lower ham radio bands.
I wonder if anyone tried something like this to convert WiFi devices to
70 cm band? Could that work?
Pedja
YT9TP
The tunnel interface is a gateway to the rest of the class A network.
You have to allow this by setting a netmask of netmask 255.0.0.0
An your second ethernet interface to your radio LAN, you may set a
smaller netmask.
Steve
Eric,
Today, the list of tunnels, whether distributed by the encaps file or via RIP, are really just a list of whatever is configured in the portal. Even though they may be distributed by RIP, RIP is being used merely as a distribution mechanism. The existence of an entry in the list tells you nothing about whether that tunnel is actually up or not -- only that it has been configured in the portal. So, even if there were multiple RIP speakers, you'd get the same info except for the main gateway/default route.
What I think you're describing is more like a route reflector such as are used in Internet BGP networks. The clients would identify themselves to the main gateway, and the main gateway would reflect that info back to all other clients. That would provide the dynamic routing that would be helpful. And, if the clients could announce additional routes to the server, we could have dynamic alternate routes. Couple that with regional reflectors and the option to listen to more than one reflector so you can get dynamic default route, and I think we've got something.
The code for BGP route reflectors is public domain, so I wonder if it makes sense to adapt it to RIP.
Michael
N6MEF
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Eric Fort <eric.fort(a)gmail.com>
Date: 08/27/2013 1:33 AM (GMT-08:00)
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Multiple gateways for same route
(Please trim inclusions from previous messages)
_______________________________________________
ok, multiple static routes to the same place I can see why not. We do have
dynamic routing available to us though via RIP. Would RIP or another
routing protocol not handle this in the case of the route being unreliable
and drop that route? Why must routes be persistent rather than dynamic?
In a larger sense and I realize we're not there yet it would seem that
rather than having to know the routes to all other 44net hosts from boot it
would be much easier to have each area (for instance each /16 or maybe in
some cases each /24) to have a designated router (say at .1) or possibly
use multicast to discover one's local router. thus the initial config is
simplified as it has a single route to the 44net gateway for it's area from
which it may discover via dynamic routing other routes. no more need to
manually distribute and update a routing table. This seems to be something
to work towards.
On Thu, Aug 15, 2013 at 7:55 AM, <Bob(a)qbjnet.com> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> No they shouldn't both be allowed. There isn't a way to dynamically choose
> the
> route based on whether one or the other connection is up. Packets sent to
> the
> down route are simply lost.
>
> Regards,
> Bob
>
>
> "Eric Fort <eric.fort(a)gmail.com> says:"
> > (Please trim inclusions from previous messages)
> > _______________________________________________
> > are these 2 entries for a single route or 2 separate routes to a single
> > destination? It seems to me they are actually separate redundant routes
> to
> > the same /21. should redundant routes not be allowed? It would seem
> quite
> > the reverse that redundancy being useful and importaint these ought to be
> > allowed to stand so long as they are valid routes to the specified /21.
> >
> > Eric
> > AF6EP
> >
> > On Thu, Aug 15, 2013 at 2:54 AM, G1FEF <chris(a)g1fef.co.uk> wrote:
> >
> > > (Please trim inclusions from previous messages)
> > > _______________________________________________
> > > Hi Marc,
> > >
> > > No, there should not be two entries for one route and the portal should
> > > not allow this to happen, so I will look into how it occurred and
> amend the
> > > code as necessary.
> > >
> > > Thanks,
> > > Chris
>
> --
> /~\ The ASCII | Bob Brose N0QBJ
> \ / Ribbon Campaign | http://www.qbjnet.com/
> X Help cure | mailto:bob@qbjnet.com
> / \ HTML Email | public key at http://www.qbjnet.com/key.html
>
> There are only 10 types of people in the world: Those who understand
> binary, and those who don't
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
> http://www.ampr.org/donate.html
>
> Subject:
> Re: [44net] Multiple gateways for same route
> From:
> Eric Fort <eric.fort(a)gmail.com>
> Date:
> 08/27/2013 10:33 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> ok, multiple static routes to the same place I can see why not. We do have
> dynamic routing available to us though via RIP. Would RIP or another
> routing protocol not handle this in the case of the route being unreliable
> and drop that route?
This has been discussed many times here. Maybe you need to have a look at
the archive. There are many existing solutions for this problem, of course. They
all have their advantages and disadvantages, when seen from an amateur viewpoint.
However you need to understand that the sending system has no information about
"the route being unreliable" and the receiving system has no way of making the sending
system try other routings. That is why a working automatic routing protocol is always
much more complex than RIP (which works like the method used by NET/ROM)
There is little point in rehashing time after time how much better everything could be,
when there is not going to be a change anyway.
Rob
