44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 04 Aug '15

04 Aug '15

> 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

4 10

Re: [44net] New Linux Boot Scripts for Testing
by Steve L 03 Aug '15

03 Aug '15

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\."

2 1

Re: [44net] New Linux Boot Scripts for Testing
by Steve L 02 Aug '15

02 Aug '15

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

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 02 Aug '15

02 Aug '15

> 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

1 0

AMPRNet Munge script package
by Assi Friedman 29 Jul '15

29 Jul '15

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

2 1

Tomorrow 2015-07-29
by Brian 29 Jul '15

29 Jul '15

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.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Re: [44net] RIPv2
by Rob Janssen 28 Jul '15

28 Jul '15

> 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

2 1

Re: [44net] N1URO and traceroute. Was: Iperf server for public use
by Rob Janssen 28 Jul '15

28 Jul '15

> 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

1 0

ipip.routes and rc.local
by Assi Friedman 27 Jul '15

27 Jul '15

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

4 3

Packet loss through UCSD?
by Assi Friedman 27 Jul '15

27 Jul '15

Folks: I just brought my ampr host back online after moving to a new facility. My initial configuration is to enable internet <-> amprnet connectivity. So I have all traffic in both incoming and outgoing directions routed IPIP'd via UCSD. The host is Linux Fedora based (will be transitioning to CentOS sometime...) and I used the guidelines set on the wiki. One unexpected thing is packet loss. I am seeing very slow performance using this approach and rather poor packet loss. Are there any issues or QoS policies implemented on the amprnet router at UCSD? Thank you, Assi kk7kx/4x1kx AMPRNet host: kk7kx.ampr.org (icmp & http only for now) Internet host: phantom.kiloxray.com (hosts kk7kx)

11 30

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net