> Subject:
> Re: [44net] 44.151.29.29/32 F4LTS
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 02/25/2015 08:25 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>> >I would be happy to scrap the Portal and go back to the procmail
>> >scripts that Jim Fuller developed and operated for decades.
>> >Things worked, and worked dependably, back then!!
>> >
>> >The Portal is way too "vaccuumous" for me:(
>> >
>> >--- Jay WB8TKL
> Hello Jay,
>
> I assume that like any development project, Jim's solution didn't work
> 100% from the beginning either. Cut the developers of the portal some
> slack and report your issues here, so the issues become known and can
> be fixed (or someone may provide a workaround).
>
> Anyway the thanks to all the developers on the project!
>
> 73 de Marc
I agree with that in principle, but I have reported several issues and rarely ever was anything
changed to solve those issues, while in the meantime things were changed that caused
even more issues (like the mandatory selection of a registered subnet for an IPIP tunnel),
or that added features that were not near the top of any wishlist observed here (like an API).
What I need in my daily work as a coordinator in a network that has been springing into life
again is a usable mechanism for address assignment, and a way to edit an existing structure
into the new database. Without those present, I have to work around the system and tell
people to ignore features and make requests in a separate mail.
That would be fine if there would be visible progress, say a new feature every month or two,
but I have a hard time seeing any.
Rob
The other day I helped another 44net user troubleshoot his IPIP
configuration by running a traceroute from our network. He asked,
"what is the last working hop?" I decided it might be useful to the
community at large to release a tool that allowed doing this test from
our network without waiting for me to run a command.
Here it is:
http://trace.hamwan.net/
It is simply a web interface to mtr. I hope this allows people to
confirm their IPIP tunnels are working properly.
The tool is published on non-44net IPv4 and IPv6 addresses, in case
your tunnels aren't working properly yet. (This plan might not be as
good as I'd hoped, because the DNS is still on 44.24.240/20.) The
source IP for the actual traceroute will be 44.24.241.98.
If you would like to deploy this on your piece of 44net, or improve
the code, the source is available here:
https://github.com/kd7lxl/mtr-web
Tom KD7LXL
Hello Andrew et al.
I would like politely remark, that although I participate
in portal.ampr.org development, my only task (so far)
to which I volunteered, is polish language version
of portal.ampr.org
Surely, working closely with the source code of portal
I spotted some minor mistakes, misprints and so on
which I always passed to Chris for review.
But to be candid, myself I introduced to the code
(fortunately ONLY in polish language version!)
some mistakes which made this part of code
temporary unusable; Chris needed to correct them!
All of us, we are just(?) human beings. We make
mistakes, we forget things... Also, all of us,
we have our private life, family, health problems...
And what Chris perfectly pointed out, sometime
life unexpectedly, without any excuse - intervenes!
Thus making our life much harder and tough...
With best regards from Gdynia.
_____
Tom - SP2L
(ex sp2lob)
__________________________
Send from Sony Xperia Z1
http://aqua-mail.com
On 2/26/15 4:25 PM, Andrew Ragone (RIT Student) wrote:
> To clarify, too, this would be not only for the portal but the website as
> well ... in which everyone could contribute to web content / wiki to
> describe aspects of 44net and IP in Amateur Radio.
have you seen http://wiki.ampr.org/index.php/Main_Page ?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
> Subject:
> [44net] 44.151.29.29/32 F4LTS
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 02/14/2015 12:21 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Good evening,
>
> is Eric F4LTS on this list or does anybody have his contact data?
>
> Eric has added network 44.151.29.29/32 with Gateway 44.151.29.29, once
> the IPIP interface on my router comes up, the route for
> 44.151.29.29/32 via 44.151.29.29 comes up, which in turn takes down
> the interface which disabled the route, which allows the interface to
> come up... a fine loop.
>
> I had to filter his network 44.151.29.29/32 from the results I fetch
> via the API in order to keep my log size down.
>
> I'm not sure if the portal should allow the gateway for a network to
> between inside that same network. I think it makes no sense but please
> correct me if I'm wrong.
>
> 73 de Marc, LX1DUC
It is certainly not correct... fortunately ampr-ripd ignores such routes after it was found
that other people (like SA0BXI) had created them and they caused encapsulation loops.
But of course you are right, the portal should simply refuse to store such incorrect
information in the first place. It should issue an error message that makes the user
think again about what they have requested.
I am a bit disappointed about the progress in the portal development. Sure it can happen that
people are temporarily busy and have to postpone things a bit until more time is available,
but the portal as it is now has halted the development of amprnet and left everything in
a stalemate situation. The DNS part needs to be finished, the allocation of subnets has
to be much more flexible, overrides have to be made available to coordinators, and some
address management tools have to be added. When it is decided that this cannot be done
in the time available to the developer, it may be better to switch to another management system
like the hamnet-db.
73,
Rob
In the wiki example...
http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example
Under Protecting the Gateway...
The following OUTPUT command is not accepted.
sudo iptables -A OUTPUT -i lo -j ACCEPT
The error reads:
"iptables version 1.4.14 can't use -i with output"
Any suggestions?
--
Leo , N5JEP
I'd propose a purity test.
😀
On February 15, 2015 12:35:30 PM EST, Mitch Winkle <mitchwinkle(a)gmail.com> wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>Being a ^M "offender" I can tell you that the ax.25 and Uronode and
>axMailFax software have no issues with said ^M characters in the
>axports
>file. The blank line issue has been well known for years but to my
>recollection, only for NetROM's nrports file. I (until yesterday) had
>a
>blank end line on my axports file to no detriment.
>
>Tom thank you for following your hunch, and hopefully we can get that
>documented for the "fbb" script for us newby types.
>
>Mitch
>
To whom it may concern.
As some issues lately discussed on both lists
evidently show, there is not to much attention
paid to REAL PURITY of all, or at lest some
linux config files, in particular axports file.
It is CRUCIAL, that axports file:
- CAN NOT contain ANY EMPTY line at all!
If additional space is necessary between
lines then usual spaceholder "#" is fine,
- CAN NOT contain ^M (CR - in hex 0x0D)
code at the end of any line!
NOT RESPECTING above two rules may result
in unpredictable behavior of many AMPRNet
software, not to mention FBB BBS, URONode.
Presence of ^M (CR) code can be viewed
and corrected, for instance, in Midnight Commander,
VI and well known Emacs editors.
>From the other hand, simple and friendly editors
like nano and joe, apparently are useless...
There are few nifty tools that may one use for
removing ^M characters, even from bunch of files
without editing. Best known is dos2unix available
for all linux like distros.
Best regards
_____
Tom - SP2L
(ex sp2lob)
__________________________
Send from Sony Xperia Z1
http://aqua-mail.com
Hello,
his email is eric.f4lts(a)gmail.com
I have already contact him.
Best regards,
Ludovic - F5PBG.
Le 14/02/2015 20:00, 44net-request(a)hamradio.ucsd.edu a écrit :
> Good evening,
>
> is Eric F4LTS on this list or does anybody have his contact data?
>
> Eric has added network 44.151.29.29/32 with Gateway 44.151.29.29, once
> the IPIP interface on my router comes up, the route for
> 44.151.29.29/32 via 44.151.29.29 comes up, which in turn takes down
> the interface which disabled the route, which allows the interface to
> come up... a fine loop.
>
> I had to filter his network 44.151.29.29/32 from the results I fetch
> via the API in order to keep my log size down.
>
> I'm not sure if the portal should allow the gateway for a network to
> between inside that same network. I think it makes no sense but please
> correct me if I'm wrong.
>
> 73 de Marc, LX1DUC
What is it that makes this route:
44.140.0.0/16 via 192.16.126.18 dev tunl0 proto ampr-ripd metric 44 onlink
appear and disappear all the time?
The gateway 192.16.126.18 does not work. In the portal there is a gateway 44.140.0.1
for 44.140.0.0/16, also BAD of course. This has been discussed before.
Why hasn't it been deleted?
How can it be that there are TWO gateways for the same 44.140.0.0/16 network in
the portal? And why is the 192.16.126.18 one appearing and disappearing every few hours?
Please whoever is responsible for this, debug this. It has been an issue for many months,
it has been discussed before, but nothing has happened.
SA0BXI apparently is not reading the list. I thought that was a requirement for being
a gateway. As he has never replied to any discussion about his network, why don't
we simply delete his entries?
Note that 44.140.0.0/16 is BGP announced, so when there is no faulty entry at least
it will work for some setups. Right now it is just dead.
Rob
