44net

44net@mailman.ampr.org

3196 discussions

portal issue?
by Brian 18 Nov '14

18 Nov '14

It appears some subnets have been purged from the portal. Can we restore from a backup? -- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel. 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Which HAM Radio is good for connect with PC
by Ernest.Tse＠Pacswitch 18 Nov '14

18 Nov '14

An embedded and charset-unspecified text was scrubbed... Name: not available URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20141118/0763fce…>

1 0

Re: [44net] ampr-ripd 1.12 released
by Rob Janssen 17 Nov '14

17 Nov '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd 1.12 released > From: > "SP2L-wp" <sp2l(a)wp.pl> > Date: > 11/17/2014 08:02 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, Marius et al. > > WOW!!! > What a nifty script! > > Isn't small mistype here: > > while read d ip <--- "d" is it correct? > do Hi Tom, Yes, it is correct. It reads the output of the diff command which has lines like: < 1.2.3.4 > 5.6.7.9 It puts the < or > into $d and the IP address into $ip. Then it either deletes or inserts the IP address in the list using the case/esac on $d. You can copy/paste the script and run it and check using: iptables -L ipipfilter -vn to see if it works OK. You can run it again and nothing should change. When all is OK you can change the ampr-ripd startup to add the -x option and modify the firewall to use ipipfilter instead of ACCEPT for -p 4. Make sure in the startup sequence of the system you run the script once before the firewall is loaded, so that the ipipfilter target does exist before the rule for -p 4 is loaded. I have my own script that sets up the entire firewall, so I call the script from there. Rob

1 0

External address changed
by Rob Janssen 16 Nov '14

16 Nov '14

For those who have not yet implemented RIP or automatic import of encap.txt: The external address of the gateway for 44.137 has changed from 194.109.64.198 to 213.222.29.194 in preparation of the setup of direct BGP routing of 44.137.0.0/16 Rob

1 0

Beware of Mikrotik RouterOS v6.21 and v6.22
by Marc, LX1DUC 13 Nov '14

13 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear YLs and OMs, beware of the latest Mikrotik RouterOS version 6.21 and 6.22. It generates strange IPIP packets adressed to the remote endpoint of an IPIP tunnel. The IPIP packets itself contains an IP packet that is addressed from the remote endpoint to the mikrotik router. Pseudo packet capture Frame: 1 Time: 0 Internet Protocol Version 4, Src: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik), Dst: Re.Mo.Te.IP (Re.Mo.Te.IP) Internet Protocol Version 4, Src: Re.Mo.Te.IP (Re.Mo.Te.IP), Dst: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik) Frame: 2 Time: 10 Internet Protocol Version 4, Src: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik), Dst: Re.Mo.Te.IP (Re.Mo.Te.IP) Internet Protocol Version 4, Src: Re.Mo.Te.IP (Re.Mo.Te.IP), Dst: Mi.Kr.Ot.Ik (Mi.Kr.Ot.Ik) and so on, almost every 10 seconds. Once I downgraded to version 6.20 the strange packets seem to have stopped appearing. If someone discovers the origin of this issue and knows of a way to avoid the issue other than downgrading, please let me know. Thanks to PE1CH for notifying me after seeing the strange IPIP packets on his system. 73 de Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUZTQXAAoJEHFIN1T8ZA8vGwAP/2qJuWXQLG4x3S2zPkQFll15 PA9H/ytSxxfdDsKe7tCf7Ky0qmxUV6WNVbq19/Ag1q6Ld+cBhKbWHa7BOVK9hjV0 8NO2ZV5D7KtYkhSLpNE9othhdtU/hRouevEQy/qoO6EvJxE4fEpbOrMiNX6aTAeQ bnqBWeGsuds7/qHFjOrID0jrfYXdddMW4e9cXwRJRfiFafBIwwLaNHhlKXORaXQy 23mPs+woFskGPk4VXDxWXMuOe3TeWzpxpwldYHaPRhzfUmGBj0ogQ1tSJPiMYMy8 Rc8iE4NtmZMyP0b6IdnoIjveloCpILDIwCHD8ZRba4KSs3aRVcyLih3v67zuu3Jf i+K7BCKXNFIQtGoY7IQQawRF8AP7vxL30r9J9pgKk7IjURDTBWRDbyZb201gdfbp PKV+XBlm+Hq9kxs04BIYeYBES+iVLMOJYtLPQtF906EEc1RuzjjvoKu+BVqIB+vk IRLSBqLsU4V7CM/aj2gvik4TyC2huBjhqpvxNUXeAP5CyMSfqJ8OZZmOYEGyWmZc vif4F5HhwCjPCaQr0OCqUIKuH/hd+/4qXrFtSnTOYPT+mRCMNg1PW/IvkysS86+5 orQ1J+OeqUnfwHrXvR26l9Yo+SqKie3k+1v9iYyv6ZS7eKFKqseL+lPgQmdnnJl4 gY65U+kkGw27RtlLYw5+ =+9vG -----END PGP SIGNATURE-----

3 4

Attn LX gateway
by Rob Janssen 13 Nov '14

13 Nov '14

I am getting a constant stream of nested encapsulated packets from 46.29.182.226 Something is going wrong there. Rob

2 1

Re: [44net] Gateways with external address in net-44
by Rob Janssen 12 Nov '14

12 Nov '14

> Subject: > Re: [44net] Gateways with external address in net-44 > From: > Brian <n1uro(a)n1uro.ampr.org> > Date: > 11/12/2014 02:07 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, 2014-11-12 at 10:16 +0100, Rob Janssen wrote: > >> >Ok, but then I think those gateway entries should not be distributed via RIP. >> >When they are directly routable, should we use a tunnel to reach them? > That's only half the equasion. The other half is when one is SAFed > (Source Address FilterED) and they policy route 44/8 via their tunnel > interface, and anything else via UCSD... Yes that is the problem. I need to policy route on source address because of SAF and I use a separate routing table for the tunnels with a default to UCSD. This fails with that 44.24.240/20 with gateway 44.24.221.1 network. We are building a gateway for 44.137.0.0/16 which in fact has already been running since the summer but the process of getting the provider to agree to route BGP has taken much longer than anticipated. Anyway, this gateway (which of course is not affected by SAF itself) has a separate public IP (194.109.64.198) for use by the IPIP tunnels to other gateways. I think that is a better method, it avoids lots of confusion and complicated policy routing rules. Maybe the routing will work again once we have our country gateway up and running with BGP and direct outbound routing of net-44 traffic (without having to tunnel to UCSD). I plan to work out a routing configuration without separate net-44 routing table at that time. Rob

1 0

Re: [44net] Gateways with external address in net-44
by Rob Janssen 12 Nov '14

12 Nov '14

Brian Kantor wrote: > Those are valid gateway entries; those particular 44-net addresses > are directly routed via BGP advertisement. > - Brian > Ok, but then I think those gateway entries should not be distributed via RIP. When they are directly routable, should we use a tunnel to reach them? There is a problem because when the destination of the tunnel is within the net-44, the routing gets in an encapsulation loop. Rob

6 10

Re: [44net] Gateways with external address in net-44
by Bryan Fields 12 Nov '14

12 Nov '14

+1 On November 12, 2014 12:15:25 PM EST, Tom Hayward <esarfl(a)gmail.com> wrote: > >I think we're getting a bit ahead of ourselves here proposing new >special announcements. > >Here's another idea: don't assume anything spans the whole 44/8. >Instead of policy-routing 44/8, policy route for each of the routes >found in the encap. 44.24.221.0/24 isn't in the encap, so you should >source packets to it from your commercial ISP source IP. UCSD is not >involved. > >Tom KD7LXL -- Bryan Fields 727-409-1194 http://bryanfields.net

1 0

Gateways with external address in net-44
by Rob Janssen 12 Nov '14

12 Nov '14

When I was working on my gateway I noticed that stations use a 44-address as their external address. For some time there has been the gateway to 44.24.240/20 with gateway 44.24.221.1 This morning I noticed gateways with address 44.151.94.28 and 44.140.0.1 but they have been removed in the meantime. I want to notice that my gateway cannot route traffic to gateways like that, due to the policy routing used to separate internet traffic and tunnel traffic. And I think that many other gateways have a similar setup and have the same problem. Is there any official policy on the external gateway address? Is it allowed to be in net-44, and if not, wouldn't it be better to check this in the portal and reject submissions like this with a suitable error message? I suspect part of those entries are just the result of misunderstanding by a newcomer, and we help them getting things working by hinting at this incorrect configuration. Rob

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net