Good afternoon,
It would see that 44.133.48.66 is popping, snmpding, and other
amounts of traffic from time to time to various ampr.org systems
and doing so *without warning* type of thing. I just got hit with
a bunch of SNMP requests, others have been hit with POP requests.
Can anyone find out who the owner of that particular system or
network is, so that I can contact the entity or person.
Or perhaps a bit more draconian, can someone deal with it.
Thanks in advance.
Maiko Langelaar
VE4KLM
Greetings,
I've been doing some work to get the IPIP tunnel information into a router on
a daily basis, has anyone else automated this?
I was wondering how the reachability of this from the global routing table of
the public internet works, if at all. Everything I've been reading says this
is all separate, but we do interconnect at a couple locations. I must admit
I'm new to this, but is 44/8 intended to be totally separate a la the GRX
network?
Granted my use of this space is for high speed wireless networks on the ham
bands, I have little interest in the 9.6 kilobaud TCP/IP packet radio.
I've got some of the 900MHz FHSS gear hacked to run in a narrower channel, and
I've been experimenting with running some of the 5ghz units in the ham band at
5cm (5mhz channel is able to do about 10mbit/s). My intention is to have it
all work across hardware routers, ie cisco/ALU/juniper rather than maintain a
bunch of linux boxes.
Thoughts?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
By default rip44d is using the interface tunl0, it seems:
my $tunnel_if = 'tunl0';
You seem to be using tun0 in your networking scripts, so i suppose you either need to adjust the default, use the -i option to change the interface used by rip44d, or change the tunnel interface name to match so the rip44d is listening on the right interface.
Pieter.
Sent from a mobile, sorry for any typoes...
Hi all,
I've just set up my net44 gateway using a Debian machine running in the
cloud with a static IP. My plan is to use this machine as an
IPIP-to-OpenVPN adapter so that I can run my subnet from home via my LTE
connection, with will not support IPIP. I set up the machine with Debian
linux and rip44d.
I'm currently receiving the routing table from 44.0.0.1, and I'm able to
ping several net44 machines in my area (44.4.2.153 and 44.4.50.1 for
example), however, my linux machine is not able to ping 44.0.0.1. At first
I assumed that this was a security policy, however, I'm also not able to
access the ampr.org website from that machine now. in addition, I'm unable
to ping my machine's net44 address from the internet.
Is this a result of gw.ampr.org not updating it's gateway list, and thus
not knowing how to route to me, or have I missed something obvious?
Also, if anyone with a properly maintained gateway list could ping me
at 44.4.36.1
and let me know the result, I'd appreciate it.
Thank you,
Blaine
--
Blaine Forbort, K1QV
Vallejo California
Hello Miro:
Your local Coordinator can set that up for you.
> Hello,
> How can you add a name ampr.org as lz4ny.ampr.org be directed to IP
> 44.185.1.1 tried by portal.ampr.org but it does not.
> We will be happy to direct me where I can find more detailed information
about the entry of names in ampr.org or setup dns server in Debian can
add and edit names zone Bulgaria - 44.185.xx
>
>
> 73, Miro, LZ4NY
Hello,
How can you add a name ampr.org as lz4ny.ampr.org be directed to IP
44.185.1.1 tried by portal.ampr.org but it does not.
We will be happy to direct me where I can find more detailed information
about the entry of names in ampr.org or setup dns server in Debian can add
and edit names zone Bulgaria - 44.185.xx
73, Miro, LZ4NY
-------------------------------------
Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg
> Subject:
> Re: [44net] Distributed BGP Announce
> From:
> Brian D Heaton <ky9k-lists(a)ky9k.org>
> Date:
> 07/29/2013 05:54 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> My experience is with Cisco's "ip tcp adjust-mss xxx". It works 100% in all cases I've seen. Some very large deployed networks use that functionality. The only times we have issues is when folks remove that statement thinking it is redundant to
> MTU size. (We set both)
>
> 73-KY9K/Brian
>
>
> On 7/25/2013 8:59 AM, Marc, LX1DUC wrote
>>> Also as it only really efficts TCP, I solve it on my GRE tunnels with
>>> ip tcp adjust-mss 1436 in cisco
>>> set interface $interface ip tcp adjust-mss 1436 in juniper
>>> tcp-mss-adjust 1436 under an SDP config in Alcatel-Lucent
>>
>> What is your experience with that setup? Does it always (99.999% :-D) work? If so, count me in an let's go with it.
>>
>> 73 de Marc, LX1DUC
I probably invented that :-)
I introduced it into my version of NET (derived from KA9Q NET) in august of 1995, to avoid the
fragmentation that frequently occurred when forwarding IP datagrams over NET/ROM transport.
In my version, the MSS was automatically calculated from the MTU of the incoming and outgoing
interface in the IP routing code. It worked very well. (MTU discovery did not exist back then)
In 2001, Cisco introduced it in IOS and I realized I should have patented it :-)
From changelog:
PE1CHL.950819:
TCP SYN packets are examined when routed, and the MSS option will be
adjusted down to the maximum MSS possible on the incoming and outgoing
interfaces. Thus, a more optimal end-to-end MSS is chosen, and
fragmentation is avoided (e.g. when running IP over NET/ROM somewhere
inbetween the endpoints)
Rob
So how are folks actually making use of all this nifty routing
technology on the air with Amateur Radio these days?
I don't remember the last time I've seen an "ampr.org" email address
here on the list. I kinda remember the last time I had one that
worked...
Bill
On 7/25/13 2:59 AM, Marc, LX1DUC wrote:
> By defautl GRE provides an Layer3 MTU of 1476 bytes. How will you cope
> with packet fragmentation or in case DF=1 with ICMP type=3 code=4 (The
> datagram is too big. Packet fragmentation is required but the 'don't
> fragment' (DF) flag is on.) filtering.
Yes, but this is why we have PMTUD. It works fine so long as ICMP is not
blocked. If ICMP is blocked, then some one along the path needs to get some
clue. I've only encountered this on private networks (LAN's, and packet cores
where IT runs it). Generally it's fixed with me screaming "YOU'RE BREAKING
THE INTERNET STUPID!" ;)
Also as it only really efficts TCP, I solve it on my GRE tunnels with
ip tcp adjust-mss 1436 in cisco
set interface $interface ip tcp adjust-mss 1436 in juniper
tcp-mss-adjust 1436 under an SDP config in Alcatel-Lucent
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
