44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] 44Net Digest, rip44d
by Rob Janssen 30 Aug '13

30 Aug '13

> 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

1 0

Anyone tried to use transverters from 2.4GHz to 432 Mhz?
by YT9TP Pedja 29 Aug '13

29 Aug '13

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

1 0

Re: [44net] (no subject)
by kb9mwr＠gmail.com 28 Aug '13

28 Aug '13

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

3 3

Re: [44net] Multiple gateways for same route
by Michael E Fox - N6MEF 27 Aug '13

27 Aug '13

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 >

4 3

Re: [44net] Multiple gateways for same route
by Rob Janssen 27 Aug '13

27 Aug '13

> 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

1 0

Multiple gateways for same route
by Marc, LX1DUC 27 Aug '13

27 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, while analyzing the routing table on my Mikrotik router, I noticed that there are 2 gateways for 44.136.0.0/21: 114.198.116.219 203.5.58.162 The encap file has both as well: route addprivate 44.136/21 encap 203.5.58.162 route addprivate 44.136/21 encap 114.198.116.219 I have tried to create 2 routes for some of my networks via the portal, but the portal complains with the words "The network overlaps an existing entry". I'm now interested to know, if these 2 routes are intended to co-exist? If yes, how can one create those entries via the portal. If no, which one is correct and why are there 2 entries? 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDJ/oAAoJEHFIN1T8ZA8v8EoP/0HHZn+S4SB0EiqJKjZR8gJG GL7imNQ0sTZUBE6QMQzXs5+Dr6D++jEYyO36AlqgR0Z2SABs/HFhbuHYV+9Bvb+n m01m8eKDFJam3uqXGQjsvV5gH/nC8nVJ0hgdsMolatu8B8WBUR02QQDkgq2u11pP GLwffzANg4/FPLLShYZKk2IL6unh0GFqvW2bePQUZ+8OQv2X1UyDR2jWg4gi7sOO 6imU3CVfKfc53SfPox2De7nLGxsKZsk2O/RCxHEom0MKYCdWtNmoszOTDpxNmkPd cVJfEZ7zOIBHW+ZYFtsCy1GfoanDlel0jOMm5zNe4WkxeCjPtvD/46vxpPOAh2xk 84lDA3oWY2LYKny6c6YD7zFEcHcX84gR+6gdFFvuaiKU99RizFK0XORJxdVqU4tT TSBCCt+oW6sPCAJe2vuorA9TyqLMwc6RDg98ZdoEEAYQJke7/CgTBkP+A6EY/U15 HCWk6cXIvHsu2j33K4HoqoaJa74yZMctTnumMu+E4x2Kw+OtCFJfsNt3dTAqeWkr uuKpeqnjWqPAnT6l3uQOTknwfara79Cw9zWfaG2nnRS8gcIki+Voe+gWAOdiObbF m0dcmsCBqcyFaRtBHyR0N4BuQC/o5H6rQBgzNFDW54EKraRPLokuM9fW6PF1YJ1l +TItkIm+J2u9xwlSJbXq =invI -----END PGP SIGNATURE-----

9 9

Re: [44net] Routing Tables
by William Lewis 26 Aug '13

26 Aug '13

Your routes look correct. Traffic will follow the most 'precise' given route. For example, lets first use a made-up route to 44.2.12.75. Since your table does not show a 'specific' subnet, it will use your rule of "44.0.0.0 169.228.66.251 255.0.0.0" But, if you use a route to 44.2.14.3, your tables show a more precise route to that address, so your traffic will use your route rule of "44.2.14.0 50.79.156.221 255.255.255.248" The only thing I see in your route that may or may not be of concern, is the third line. Not sure what your interface "rose0" goes too, but I see a possible conflict with the route right above it. You basically have two (2) routes listed for traffic to 44.0.0.0/8 Other than that, that looks good. As everyone's setups are custom, I don't know what that interface "rose0" does for your system. Bill At 03:32 PM 8/24/2013, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Hi all, > >My routing table after my AMPRnet GATEWAY has got all the routes via >RIPv2 using rip44d, looks like this: >------------------------------------------------------------------------------------------------------- >Kernel IP routing table >Destination Gateway Genmask Flags Metric Ref Use Iface >0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 eth0 >44.0.0.0 169.228.66.251 255.0.0.0 UG 0 0 0 tunl0 >44.0.0.0 0.0.0.0 255.0.0.0 U 30 0 0 rose0 >44.0.0.1 169.228.66.251 255.255.255.255 UGH 0 0 0 tunl0 >44.2.1.32 76.14.161.185 255.255.255.248 UG 0 0 0 tunl0 >44.2.10.0 71.130.72.52 255.255.255.248 UG 0 0 0 tunl0 >44.2.11.1 71.130.72.52 255.255.255.255 UGH 0 0 0 tunl0 >44.2.14.0 50.79.156.221 255.255.255.248 UG 0 0 0 tunl0 >44.2.14.100 50.79.156.221 255.255.255.255 UGH 0 0 0 tunl0 >44.2.50.0 68.189.32.222 255.255.255.248 UG 0 0 0 tunl0 >44.2.50.0 208.74.106.137 255.255.255.0 UG 0 0 0 tunl0 >44.4.2.152 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0 >44.4.2.153 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0 >.... >More routes >------------------------------------------------------------------------------------------------------------- > >Is this correct or am I dending all AMPRnet traffic through UCSD.EDU ? > >-- >73 de SV1UY >Demetre Ch. Valaris >e-mail: demetre.sv1uy(a)gmail.com >Radio e-mail: sv1uy(a)winlink.org >(to use my radio e-mail put //WL2K in the beginning of the subject line) >http://www.qsl.net/sv1uy >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net >http://www.ampr.org/donate.html

4 5

Re: [44net] ipip tunnel
by lleachii＠aol.com 26 Aug '13

26 Aug '13

Marius, 172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN. 44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding. I have my tunnel isolated from my 44LAN and Local/WAN network for testing and troubleshooting purposes. This ensures that I'm in fact routing if a packet moves from one network to another. My eth0 is my public facing LAN - which has a 192.168 IP scheme, IP-in-IP is passed to that network from my Public IP address by my Router. eth1 is my 44LAN with the IP address of 44.60.44.1/24. my setup script can be seen at http://44.60.44.13/startampr 73, Lynwood KB3VWG

9 24

Re: [44net] 44Net Routing tables
by Rob Janssen 26 Aug '13

26 Aug '13

> Subject: > Re: [44net] Routing Tables > From: > Bob Tenty <bobtenty(a)gmail.com> > Date: > 08/26/2013 08:23 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > The default route to 169.228.66.251 is in most munge scripts I have seen. > The motivation was that you are reachable in that way if a new gateway > pops up and you don't refresh your ipip routes at a regular basis. > > 73, > > VE3TOK I also need it for the return route to sources outside net 44. That is why I have it as a default route in table 44. When someone outside net 44 connects me, I need to return the packets encapsulated to amprgw where they are decapsulated and returned to the internet. (every responsible ISP has source address filtering these days) Rob

1 0

Re: [44net] 44Net (no subject)
by Rob Janssen 26 Aug '13

26 Aug '13

> Subject: > Re: [44net] (no subject) > From: > kb9mwr(a)gmail.com > Date: > 08/24/2013 10:06 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > 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 > > > Subject: > Re: [44net] 44Net (no subject) > From: > "Marc, LX1DUC" <lx1duc(a)rlx.lu> > Date: > 08/24/2013 10:12 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Netmask surely has a relation to broadcast packets, but not multicast. > > Several user on this list use /32 (255.255.255.255) netmask on their > tunl0 interface. > > 73 de Marc It is not completely clear to me what the netmask on tunl0 really does. I understand what it does on a local network, but not for tunl0. For the routing, it does not appear to influence anything. And at least by setting it this way, I avoid having that unclear route for 44.0.0.0/8 that is added when tunl0 is created. Maybe it breaks multicast, but I don't know how. The non-working multicast could as well be the result of something else, e.g. the limited config included with the Raspberry Pi that is not really intended to be a complex router (but quite capable of it). With the -r option to ampr-ripd things appear to work OK. I use the policy-routing configuration, not a flat routing table. There is a main routing table with routes for the local network (at the datacenter), and the default gateway. There is a separate route table 44, with the default route to amprgw, the specific route for my subnet at home and the local running NET, and the ampr-ripd also adds all the specific tunnel routes in that table. There are policy routing rules that select this routing table when the source or the destination of the packet is in network 44: 44: from 44.0.0.0/8 lookup 44 45: from all to 44.0.0.0/8 lookup 44 Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net