Hello,
Yesterday, I applied the latest updates on my Debian7 Wheezy (x64)system
running, including a kernel update. I have a Kantornics TNC in kiss mode
connected to a prolific USB serial adapter, working in single channel mode
(no mkiss).
The result was that my TNC doesn't work properly anymore: Rx works
properly until the first transmission (which happens on the radio
correctly). After that, no more data is received from the TNC - Tx working
correct. After a TNC reset, it works again until the first Tx. I will try
to find the exact cause of this behavior.
I would suspect either an issue in the USB driver, or in the ax.25 stack.
Please exercise caution on this update.
73s de Marius, YO2LOJ
All,
I'm giving a presentation on the use of ham data networks for public
service. I have in mind examples like:
-- deploying mesh networks at art-and-wine festivals to provide VoIP
connectivity to info booths, video surveillance of parking lots, etc.
-- deploying mesh or other WiFi networks at a bicycle or foot race to report
statistics, etc.
But rather than just offering ideas of what COULD be done, I'd like to show
the folks some examples of what others have ACTUALLY DEPLOYED. What I'm
looking for is:
-- Description of the event (event name, purpose, who attends, how big,
etc.)
-- Description of the data networking need (why bother? Why not use
commercial facilities? etc.)
-- What services you deployed: VoIP, video, file server, .
-- What network you deployed: equipment, architecture, and why you did it
that way vs. any other alternatives you considered
-- Lessons learned
-- Pictures and/or diagrams, if you have them, are important
Although this is the right group to target with this request, I don't want
to burden this list with replies. So please make replies off-list.
Thanks much in advance,
Michael
N6MEF
n6mef(a)mefox.org
All,
Happy New Year!
A few months ago, an AMPRNet user requested 44Net allocations. One
subnet is announced on the Public Internet using BGP. The other is a
standard 44 gateway, with the exception that it's Public IP address is
the BGPed 44/8 address.
Since, on the ICANN Internet, 44/8 is one flat network routeed via BGP;
and allocations within AMPRNet are often islands gateways with a non-44
IP (since, under ICANN logic, this means both the WAN and LAN interface
are on the same network) routed using RIP44; this presented a problem
with our current schema.
Using Linux routing, I solved the problem by adding the 44 subnet to a
special routing table, and adding the Public-facing gateway address to
my Public-facing route table. Hence, these routes and rules ignore the
"invalid" RIP44 gateway announcement.
Here's the script:
NOTE: make sure the BGPed IPs have a higher priority (lower number) than
the standard AMPRNet ip rules.
########################################
### SPECIAL CASE - FOR THOSE WHO BGP
### AND HAVE SUBNETS BEHIND 44 ADDRESSES
### THIS ADDS THE BGPed IP TO THE MAIN TABLE
ip rule add to 44.24.221.1/32 table main priority 42
### THIS ADDS THE ROUTE TO A SPECIAL TABLE
ip route add 44.24.240.0/20 via 44.24.221.1 dev tunl0 onlink table 22
### THIS TELLS THE ROUTER TO REFERENCE THE
### SPECIAL TABLE TO ACCESS THIS SUBNET
ip rule add to 44.24.240.0/20 table 22 priority 43
73,
-Lynwood
KB3VWG
Subnet 44.48.0.40/29 is down for a while..
ETA unknown. Problem unknown. Time to effect repairs not available. For a
while..
Have backups.. standing by.
73 Jerry N9LYA
HF Skipnet Coordinator
HF Skipnet Midwest HUB
ARRL Net Manager - Packet Indiana
AmprNet IP Coordinator Indiana
Indiana Packet Coordinator
Sysop N9LYA/K9BBS/W9BBS/W9OTR
W9OTR Hoosier Amateur Radio Digital Society
W9HU Hoosier Radio Society
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4257/8911 - Release Date: 01/11/15
New 44net user/coordinator here.
Following the wiki (at ampr.org) I think I found an issue with the
documentation when using Ubuntu 14.04.
The ifconfig multicast command I believe has been deprecated. It didn't set
multicast on my ampr0 device. I was able to set the flag on when I ran the
following command after referencing the manpage (
http://linux.die.net/man/8/ip) -
ip link set dev ampr0 multicast on
Can someone help me figure out if that's the only line deprecated? I
suspect the onlink route might also be awry because when i run 'ip route' I
don't see the route to send traffic to amprnet gateway at UCSD
Thanks!
Rial F Sloan II
KJ4IKD
GA AMPRNet Coordinator
Hello Maiko,
Is a general bruteforcing, root and admin attemps logins (telnet), see all
hour of all days, very more attemps with "root" in all 44.152...
73 de Gabriel YV5KXE
yv5kxe.ampr.org
Message: 1
Date: Thu, 8 Jan 2015 09:37:29 -0600 (CST)
From: Maiko Langelaar <maiko(a)pcs.mb.ca>
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: [44net] lots of telnet attacks from china, australia
Message-ID:
<alpine.LNX.2.02.1501080934570.12131(a)shodan.physics.umanitoba.ca>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Is it just my system ?
I'm seeing many many login attempts as root on telnet.
Are they targetting just 44 ?
Maiko / VE4KLM
As we're a technically savvy bunch, can I ask that when posting to the list
with a new message not to reply to another and then change the subject?
This breaks threading and will cause issues when looking at the archives.
I'm simply asking this as a user of the list who uses a threading MUA.
Thanks & 73's
W9CR
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
I run a software that watches the log book. It's called "Fail2Ban".
I have it watch many system logs including JNOS. I have it set to look for
3 failed attempts from the same IP address and then it bans that IP address
for a month.
It must ban at least 20-30 ip addresses a day. Most are from China.
Wm Lewis
KG6BAJ
At 07:37 AM 01/08/15, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>
>Is it just my system ?
>
>I'm seeing many many login attempts as root on telnet.
>
>Are they targetting just 44 ?
>
>Maiko / VE4KLM
>
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> "John Wiseman" <john.wiseman(a)cantab.net>
> Date:
> 01/04/2015 10:09 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Wouldn't the simplest solution be to modify the rip44 process so it doesn't
> delete routes that haven't been announced for a while, or at least for a
> much longer period?
>
> IPIP tunnels and RIP have the major advantage that they allow those who have
> a dynamic IP address to participate in net44. I feel it is important that we
> remember that we are radio hams first, and should use solutions that can be
> used by the majority of hams, not just those network professionals who want
> to play a being an ISP.
>
> 73,
> John G8BPQ
That sounds like a good idea, John.
The ampr-ripd has a route lifetime of only 600 seconds. Routes are announced every
300 seconds, so when two subsequent announces are incomplete we lose the route.
It happened again this morning at 08:05 local (07:05 UTC). My route again was lost, and
recovered at 08:10.
I think I'll recompile ampr-ripd with a bit larger timeout. Marius, what do you think?
Does this have any negative consequences? (e.g. to change EXPTIME from 600 to
3600 or even 7200)
However, aside from that, the source of the problem should be located, or it will bite us
again in the future. There could be big packet loss on the link from UCSD, or maybe
some buffer overflow internal to the RIP server (I think it sends big bursts of data rather
than slowly throttled streams), or it could be the RIP server somehow sends shortened
information because it temporarily does not have the full route list, e.g. because the
portal sends an incomplete list.
This has to be investigated or else it will come back. I predict.
(I mention this because I recently had a long discussion with someone who thinks that
we can live with malfunctioning solutions because we are amateurs. I think we should
strive for correctly working systems anyway. And that a system that works well in practice
is always better than a system that works well in theory but does not work in real life)
Rob
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 01/05/2015 10:54 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Yes, the latest version drops subnets for which the gateway is set inside
> their own subnet, sice this breaks routing.
>
> Marius
>
> -----Original Message-----
> From:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu
> [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob
> Janssen
> Sent: Monday, January 05, 2015 22:28
> To:44net@hamradio.ucsd.edu
> Subject: Re: [44net] Tunnel mesh is (mostly) down
>
> ...
> It could be that the latest version that I now downloaded hides that problem
> with 44.140.0.1
> but I can easily see if other routes are appearing/disappearing regularly.
> ...
>
> Rob
There is still something wrong with that network.
Now that the 44.140.0.1 gateway is rejected, a gateway 192.16.126.18 inconsistently
appears in the route table (sometimes it is there, sometimes it isn't).
But that gateway is not listed at all in the portal!
In the portal there is a gateway at 44.140.0.1 that advertises to be the gateway for
subnet 44.140.0.0/16, of course wrong. The 192.16.126.18 would be fine, but it does
not appear in the gateway listing at portal.ampr.org. But it is broadcast (occasionally)
in the RIP broadcast.
Difficult to follow what is going on here, I would say there is insufficient error checking
somewhere.
Rob
