> Subject:
> Re: [44net] New Linux Boot Scripts for Testing
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 08/03/2015 01:45 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Ok. It seems I got that wrong.
> Actually there is no reply via tunnel. I can ping your system only via the
> public internet.
>
> Marius
Same for me, Marius!
I did (just as for N1URO) detailed tracing of the network traffic and although there is outgoing encapsulated IPIP
traffic to his advertised gateway, there is no reply whatsoever.
It is still unclear to me if there is some problem with the operation of the network, or a systematic bug in the
scripts that some people use. This time I thought I could download a script and have a look, maybe I see
some problem, but I cannot access the site from any address I tried... :-(
Rob
What might want to be considered in future portal enhancements under
the gateways details section is a checkbox for if that particular
gateway uses 1)rip44d by OH7LZB 2) ampr-ripd by YO2LOJ 3) A munge
script Really if nothing else for statistical purposes.
I realize gateway ops could be listing this voluntarily in the gateway
note section till then.
It might also be a good idea to have another field to list the radio
LAN connectivity speed. (So people know to go gently with broadcast
pings and nmap)
It might also be nice to list the BGP connected subnets somewhere on
the portal. For those not aware, you can see that now by:
http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44\."
I am running Marius' ampr-ripd version, routes show "proto 44"
root@kb9mwr# ip route show table 44
<clip>
44.182.69.0/24 via 5.15.186.251 dev tunl0 proto 44 onlink window 840
44.182.83.0/24 via 95.76.237.2 dev tunl0 proto 44 onlink window 840
44.185.1.0/24 via 109.107.73.62 dev tunl0 proto 44 onlink window 840
44.185.4.0/24 via 109.107.73.62 dev tunl0 proto 44 onlink window 840
etc..
kb9mwr@kb9mwr:~/test/ampr/ampr-ripd-1.13 $ grep "proto" ampr-ripd.c
* Observation: All routes are created with protocol set to 44
req.rtm.rtm_protocol = RTPROT_AMPR;
Marius can you explain the purpose of that for us? I am not completely
sold that is the problem, but at the same time I don't pretend to
understand the proto 44's purpose either.
Thanks.
Steve, KB9MWR
------ Quote ------
Can everyone verify their AMRPRNet tunl0 route tables do not include the
following value:
"proto 44"
This appears to have somehow entered some stations routing tables, the
value should be "table 44" for routers using a separate routing table,
as defined in STARTAMPR; or by using '-t' switch with RIP44d.
The ROUTING PROTOCOL value "proto 44" is invalid for routing on AMPRNet,
and I understand it should be zero (0) or unspecified.
- Lynwood
KB3VWG
> Subject:
> [44net] New Linux Boot Scripts for Testing
> From:
> <lleachii(a)aol.com>
> Date:
> 08/02/2015 08:23 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> The files and README are located here for those on AMPRNet:
>
> http://44.60.44.10/amprnet_docs/start_ampr_version
From AMPRnet, I cannot reach this system at all. From another internet address, I get a 403 error.
How do you route to 44.137.0.0/16?
Route from here to you is via a tunnel:
44.60.44.0/24 via 96.255.40.79 dev tunl0
Tunnel endpoint cannot be pinged, 44.60.44.10 neither.
Packets go out into the tunnel, nothing comes back.
Same problem as with N1URO.
Rob
Folks:
I am using a pretty old munge package. I looked on the wiki/portal but I
could not find the scripts, just references to it. Is it hidden somewhere?
Thank you,
Assi
Just a friendly reminder that M$ will be releasing Windows 10 online,
and millions of desktops are expected to suck up bandwidth because of
this. Packet loss may be a very normal thing tomorrow.
--
A computer once beat me at chess, but it was no match against
me in kick-boxing - Emo Phillips
73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
> Subject:
> Re: [44net] RIPv2
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 07/27/2015 05:44 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Mon, Jul 27, 2015 at 08:26:08AM -0700, Assi Friedman wrote:
>> >Addressing residential internet service with DHCP is a problem with the
>> >encap method. Does RIPv2 address this problem?
>> >Thanks,
>> >Assi
> Short answer: Not really.
>
> If you're referring to the dynamic nature of some home connections where
> the address may vary from hour to hour or day to day, there is no good
> solution to the problem.
It is interesting to see that the implementation of home connections varies so much over
the world. Over here there is a legal obligation to always be able to produce the name
and address of the subscriber that owned an IP address at a certain point in time, and it
appears that most providers have taken the easy way of assigning a fixed IP to each subscriber.
DSL connections all have a fixed IP. Cable connections usually have an IP that is fixed
as long as you do not turn off the cable modem for a few days or so. There is no hourly
or daily cycling of addresses anywhere.
Truly dynamic IP is only in use here on mobile connections, and often they are behind NAT
so not possible to use an ipip tunnel on them anyway. I have implemented OpenVPN and IPsec
on our gateway so those users still can get connected to AMPRnet.
I would think that when your address really changes hourly, and you want to be on an AMPRnet
tunnel, it would be best to arrange something similar, a VPN to a system on a fixed address.
It should be easy to arrange for such a thing, e.g. with a group that share a cheap VPS for it
that can also be used for mail, a webpage etc.
Rob
> Subject:
> Re: [44net] N1URO and traceroute. Was: Iperf server for public use
> From:
> Brian <n1uro(a)n1uro.ampr.org>
> Date:
> 07/26/2015 10:13 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
> My firewall rules were already installed fine and without incident 4th
> of July weekend when botnets were flooding my subnet, including the
> internet searching to exploit LogJam (which killed eBay and Yahoo as
> examples)
I still cannot ping you, I see no replies from you arriving on our external interface.
So presumably something is wrong, but it may not be the same firewall rules.
Those were probably applied to input, while this is something at output or a
problem with the routing / rules.
I think it worked OK before.
Rob
More of a Linux question, but worth a shot since others have probably been
to this rodeo before. I have come across an issue starting AMPRnet
automatically at boot. The ipip.routes script seems to fail starting the
tunl interface when ran by the system by the rc.local script.
Interestingly, when ipip.routes is ran in the crontab (nightly update) there
are no issues. So this is specifically related to the rc.local script.
Anyone else run into this issue?
Thanks,
Assi kk7kx
