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
-----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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJU3obzAAoJELyI73cdFgugm20P+gJyN53Z3Gs+WPMhrK+erP+Y
YolVkDxUbUHWEXIcT/pnYwSmv0oDw2DQYzGaES4vHeJgb1sTQrbyPXXi72dHSkLe
7NEjwYz2DH1R3udikQ1yGE24vlQAWWqQYgT4KJ5zOqwmX2INfv+3apgBGvWDUArv
sUxPYkywkHLld+N1hGEtlrDjg6wm1FoRoEDdhsbSV1laJ+Nyra+EVn2VuIc5rJKN
nDlqa3OYtP2cy0POEmUb3HGbTIszjaWNksrdEof9kNARGCpula/mI2iQpwtJeKqy
iw+QtJv72vICHNYgwAdu/bzTvgAgbosfm6WYG/g3IgupPsZBdC64fZ0Z0pn8bB5x
koWFGx9g/z/gWjUPuG0UPPzWlozftpiQWlz9qO3/5aSfy0Kn6koFjDl9cA0Q53kS
zWI0cuDK4giJQ/fy/vDojzgNnZp511Rm3WScZx9ZI/WbRE696mnLEckADmlZGg0U
dAFJDrJNYkujiZDFJWN0ZMjiZO9nEMwgSTLhr7f5xF4l3M7nfhw+dy13lqRPB68q
Mhi+NfWz6Ko+jdjLEtBVxOB2UbfUVG+aY5QVa+ctWStigN8d3hyAZ2oiXgtho1m2
m+WK912ObDyzH4waPOyQiMuf3hbnk0064WkJdHvXN5N2ZvW/0ld5FSwe5qF2NEt5
WAP3tvG3Yhsx4YNSuHe6
=XilB
-----END PGP SIGNATURE-----
> Subject:
> [44net] Incomplete table with ampr-ripd
> From:
> Brett Mueller <wa7v(a)wa7v.com>
> Date:
> 02/10/2015 06:14 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Greetings Marius and all,
>
> Just over a week ago, I finally compiled and installed ampr-ripd 1.13 on my
> gateway firewall / router, a Slackware 13.1 with 2.6.33.4-grsec-smp
> (home-rolled Grsecurity kernel). Compilation and execution seems to work just
> fine, but I get an incomplete AMPRnet routing table (currently only about 30
> routes).
>
> Ideas what could be preventing me from getting a full routing table? Any place
> besides the usual logging locations where I could find some clues? Debugging
> arguments, perhaps?
>
You may have some systematic packet loss along the route to your system.
I experienced some problems some time ago (although not as severe as you describe)
and I changed EXPTIME from 600 to 7200 in the source.
That helps when there is occasional packet loss. Of course when there is systematic loss
due to a very small queue at some point, it will not help much.
Rob
Chris (or anyone),
Any idea when the DNS portion of the web page will be online? Being able
to manipulate my own DNS entries is the only thing keeping me from being on
network.
Thanks,
-Don
I am using ampr-ripd for the node OK2KOJ-5 44.177.10.253
(As well as for node OK2PEN-5 44.177.10.10).
The node is registered at amprnet but I cannot get the
encrypted password for running correctly ampr-run.sh and
find-pass.sh utilities.
Can somebody tell me how can I get my encrypted password
to configure it into those a.m. utilities ?
Thank you
Libor sysop of OK2KOJ-5 and OK2PEN-5 ampr nodes.
Greetings Marius and all,
Just over a week ago, I finally compiled and installed ampr-ripd 1.13 on my
gateway firewall / router, a Slackware 13.1 with 2.6.33.4-grsec-smp
(home-rolled Grsecurity kernel). Compilation and execution seems to work just
fine, but I get an incomplete AMPRnet routing table (currently only about 30
routes).
I use a separate kernel routing table for all my encap routes, and since I
didn't want to interrupt my operational services while I tested ampr-ripd, I
simply added a parallel 'test' table to rt_tables and had the daemon place its
routes there. In order to see what has been populated, I manually run 'ip
route ls table test' and observe the results.
My command line argument to launch the daemon is
ampr-ripd -t test -p <cRyPtIcPaSsWoRdHeRe>
Interestingly, when I have it save routes to the encap.txt file, the file
itself gets a MUCH longer list (400-something lines), even though the table
has a small fraction of that. One more observation is that the routing table
does not appear to change from whatever it initially populates with (and yes,
the daemon is still visibly running). I do have iptables set to accept UDP 520
from 44.0.0.1 on the INPUT chain.
Ideas what could be preventing me from getting a full routing table? Any place
besides the usual logging locations where I could find some clues? Debugging
arguments, perhaps?
Many thanks! 73,
Brett, WA7V
