All,
Does anyone receive connection reset when navigating to http://netalyzr.icsi.berkeley.edu
I wanted to examine my connection (and perhaps determine the source of my random packet loss [between 5-10%]).
~73,
Lynwood
KB3VWG
On Sun, Feb 26, 2012 at 3:44 PM, Chris Maness <chris(a)chrismaness.com> wrote:
> On Sun, Feb 26, 2012 at 12:01 PM, Raymond Quinn <w6ray(a)sbcglobal.net> wrote:
>> Hmmm. I see you have a link with Brett, WA7V.
>>
>> He also has static addresses, and was able to assign a commercial IP address
>> to his linux box, as well as his NOS side.
>>
>> You might want to consult him on how that is done.
>>
>> In the mean time, does your JNOS have a LAN address of 192.168.x.x ??
>>
>> It is behind a DSL Modem/Router. It is a 2wire. However, I have 5 static
>> IPs. It does not allow me to use one of the public IPs for Jnos. It does
>> not add that IP to the local network list for configuration, and therfore
>> does not permit traffic to Jnos. I therfore had to use the munge script to
>> build tunnels in Linux. This is ok, because it does protect Jnos from
>> attacks.
>>
>>
>> Chris,
>>
>> It appears that you have the same or quite similar setup that I have. I have
>> my Linux box with a public static IP address and use that in the POINTOPOINT
>> line. Eventually, the Linux box will appear in the 2wire and when it does,
>> should automatically allow all traffic to that static address.
>
> It does exactly that.
>
>>
>> (Of course, at present JNOS is locking up after a few hours, but that is
>> unrelated)
>>
>> If you don't hear from Brett, I am willing to share what I have worked out.
>> I still have more to do, but it may get you started. As always, make sure
>> you make a backup of your current setup should it not work as mine does.
>>
>
> It works just fine save one host on AMPR-NET. I wouldn't care save he
> is my friend and one of the closest *NOS BBS to my site.
>
> I had also been in touch with AT&T customer service. The suggested I
> purchase a Motorola router from them. I wish my Linux box was back
> behind a Cisco on a commercial T1 like it was in the beginning. I had
> direct 44net-to-inet connectivity. However, the AT&T network is
> controlled by the packet Gustapo goose stepping with their tight
> firewall rules. I guess that is good for the brain dead masses, but
> it kind of makes playing with the stuff we do a pain in the toosh.
>
> Thaks es 73's
> de Chris KQ6UP
My Linux box can ping his Linux box, so that is good. I am not sure I
have the whole doted quad with a forward slash business down. I think
this is his encap.txt entry:
route addprivate 44.16.2.32/27 encap 173.60.166.190
Since I believe that 44.16.2.46 is included in that subnet. Is the
above subnet 44.16.2.32-64?
Thanks,
Chris Maness
Hmmm. I see you have a link with Brett, WA7V.
He also has static addresses, and was able to assign a commercial IP
address to his linux box, as well as his NOS side.
You might want to consult him on how that is done.
In the mean time, does your JNOS have a LAN address of 192.168.x.x ??
B
At 10:42 AM 02/26/12, you wrote:
>On Feb 26, 2012 10:20 AM, "William Lewis"
><<mailto:ec@n1oes.org>ec(a)n1oes.org> wrote:
> >
> > Chris:
> >
> > Is your station by chance sitting behind a home internet router?
>
>It is behind a DSL Modem/Router. It is a 2wire. However, I have 5 static
>IPs. It does not allow me to use one of the public IPs for Jnos. It does
>not add that IP to the local network list for configuration, and therfore
>does not permit traffic to Jnos. I therfore had to use the munge script
>to build tunnels in Linux. This is ok, because it does protect Jnos from
>attacks.
>
>Thanks,
>Chris KQ6UP
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
On Sun, Feb 26, 2012 at 11:34 AM, William Lewis <ec(a)n1oes.org> wrote:
>
> Hmmm. I see you have a link with Brett, WA7V.
>
> He also has static addresses, and was able to assign a commercial IP address
> to his linux box, as well as his NOS side.
>
> You might want to consult him on how that is done.
>
> In the mean time, does your JNOS have a LAN address of 192.168.x.x ??
>
> B
No, it does not have a 192.168.x.x address. If a host makes a DHCP
request on the local lan, the router leases 192.168s and does NAT for
them. I have configured the linux box with two IP's bound to the
ethernet card 76.238.148.147 and 192.168.1.33. That way I can build
static routes in all my desktops and laptops to be able to reach JNOS
directly. I can connect with everyone accept for K6HR.
It looks like our gatway PUBLIC IP's are not talking. If I try to
telnet to my Linux box I get:
tel 76.238.148.147
Trying... The escape character is: CTRL-T
*** busy from 76.238.148.147:telnet
Telnet is enabled as a service on my Linux box. I had noticed this
error from almost everyone all the time when I tried to set up JNOS
with a public IP. That is why I had set up my gateway with Linux
doing the IP over IP tunnels. Now it is working with 99% of the
hosts.
Chris
On Feb 26, 2012 10:20 AM, "William Lewis" <ec(a)n1oes.org> wrote:
>
> Chris:
>
> Is your station by chance sitting behind a home internet router?
It is behind a DSL Modem/Router. It is a 2wire. However, I have 5 static
IPs. It does not allow me to use one of the public IPs for Jnos. It does
not add that IP to the local network list for configuration, and therfore
does not permit traffic to Jnos. I therfore had to use the munge script to
build tunnels in Linux. This is ok, because it does protect Jnos from
attacks.
Thanks,
Chris KQ6UP
Chris:
Is your station by chance sitting behind a home internet router?
At 07:57 AM 02/26/12, you wrote:
>I can't connect or ping k6hr.ampr.org, nor can he ping me.
>
>I can ping and connect to GVCITY.ampr.org, but pinging towards my side
>is flakey for him.
Hello everyone, I am new to the group. I am the sysop of a new BBS
kq6up.ampr.org. I just recently got back in to packet radio, and
found a lot of renewed interest in packet radio in my local area. I
decided to put up another JNOS BBS. It has been about 10 years since
I have had a BBS. I have had more users in the past month (from the
radio port) than I did over entire lifetime of my last BBS.
I can connect to almost everyone that I have tried to in the ampr-net
world. I am building my tunnels in Linux. I am having connectivity
issues with two host (both have fresh encap.txt files).
I can't connect or ping k6hr.ampr.org, nor can he ping me.
I can ping and connect to GVCITY.ampr.org, but pinging towards my side
is flakey for him.
Should I try running RIP and forget about it, or are these problems
fairly easy to track down and fix?
Thanks,
Chris Maness
I wrote a paper back in the 1995-1999 time frame when packet was
fairly active in my area regarding when and why to subnet. I received
about an equal number of complaints from the linear-allocation
advocates versus the subnetting advocates with good reasons on both
sides for doing one or the other.
I have searched my old hard drives for my original document but I
can't seem to find it so I will outline the basic scheme again.
My first plan was to dedicate bits in the address plan for
geography/frequency and other factors but Brian talked me out of
making any plan more complex than it already was. He also informed me
of his reservation of the first 2 bits in the third octet for his use
in future, something I was unaware of when I assumed the post. This
made the CIDR mask 44.18.0.0/18 instead of the expected /16.
This gave me effectively only 6 bits in the third octet to play with.
Next came the question of how big to make the subnets. I don't have
multiple counties to play with and I don't coordinate a whole state so
topologically my region is pretty flat, being two counties, but still
geographically very large, San Bernardino being the largest county in
the U.S. but sparsely populated. Considering the population of hams in
the region and the number of hosts addresses within 44.18/16 I didn't
expect to have a problem running out of addresses no matter what
scheme we chose.
I was pretty much stuck with subnet 0, being the linear assignment
scheme I inherited from the previous coordinator and we simply
followed the pattern initiated in Los Angeles County where the ham
population was more active and dense.
My research into the RFCs and the nature of subnets and CIDR masks led
me to a proposal to mask the subnet bits downward and the host bits
upward, I don't recall the source of the document at this time but it
might have been an RFC.
Thus, the zeroeth subnet could stay in place as two-meter and mobile
nodes and the _first_ subnet would be 32, not 1 as you might expect in
a linear scheme.
The bits map as follows:
44.18.0.0/18 The S.B. & Riverside Co. Group
6 bits reserved for CIDR subnets within the group.
c = CIDR, x = hosts
00101100.00010010.00cccccc.xxxxxxxx
The CIDR mask for the subnets becomes 44.18.0.0/24 and the total
number of subnets is 64.
The CIDR bits are allocated in sequence from MSB to LSB, thus:
Subnet Bitmap
0 00101100.00010010.00000000.xxxxxxxx 44.18.0.x/24
1 00101100.00010010.00100000.xxxxxxxx 44.18.32.x/24
2 00101100.00010010.00010000.xxxxxxxx 44.18.16.x/24
3 00101100.00010010.00110000.xxxxxxxx 44.18.48.x/24
4 00101100.00010010.00001000.xxxxxxxx 44.18.8.x/24
5 00101100.00010010.00101000.xxxxxxxx 44.18.40.x/24
...
63 00101100.00010010.00111111.xxxxxxxx 44.18.63.x/24
By growing the subnets downward and the hosts upward linearly, if a
subnet were to become overpopulated with hosts, it can expand upward
into another subnet:
2 00101100.00010010.00010000.11111111 44.18.16.0/24
rolls over into
x 00101100.00010010.00010001.00000000 44.18.33.0/24
I then becomes possible to allocate entire subnets to a single group,
(e.g., ARES, RACES) and a single band (6 meters) without regard to the
number of hosts needed in that subnet.
Connectivity and routing in Southern California can be sparse and
geographically large, for instance, a 2 meter and 6 meter digipeater
on Big Bear covering San Bernardino and Ontario California and
reaching into Arizona and Nevada but seeing less than two dozen active
nodes.
The implications for static routing are straight forward. To get to
any subnet one merely needs to route to the nearest host in 44.18/18
and the most any host needs is 63 routes.
This was my solution, your mileage may vary. I never received any
feedback regarding this solution until I googled this:
http://www.snarked.org/~scdcc/tcpip-18.html
I'll be interested in reading the comments from the list.
This might be a good time to implement a rwhoisd server for the whole
44/8 network. This way for the people who want to register a block of any size
we can have an easily accessible and viewable whois entries. Also anyone,
anywhere can find out what is assigned to who regardless of it's block size and
regardless if there are DNS entries or not. Then it would fall back to the
regional coordinator if no entries were made for the query being checked, and
then back to the top parent of Brian for 44/8 of no coordinator assigned. This
is a proven method as ARIN has been using this for years on their whois server.
Works very well.
Assuming that if 44.X.X.0 is assigned something in DNS that it's broken
into a /24 I believe is not a good idea as it might actually be a smaller or
larger subnetmask. /24 can be very wasteful if you're not using most of it. I
would say it would be more common to hand out /27's or /26's.
This would also lend it's self nicely into IPv6, since that is
supported as well if we get space.
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
On Sat, 25 Feb 2012, Brian Kantor wrote:
> Date: Sat, 25 Feb 2012 10:13:48 -0800
> From: Brian Kantor <Brian(a)ucsd.edu>
> Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] On the Issue of Subnets
>
> So it seems to me that we have two classes of people requesting address
> allocations from their local coordinators:
>
> 1. those who are planning to operate a regional router (radio- or
> tunnel-based gateway)
>
> 2. those who are planning to use an existing router.
>
> How should we handle these?
>
> It's apparent that some scheme like Geoff's for allocating a subnet block to
> the first group is wise. It's probably not necessary to actually register
> the network (0'th) address nor the broadcast (all-ones) in the DNS but
> they're still part of the allocation. Still, the entire block (a /24 in
> Geoff's scheme) should be reserved by the coordinator for that router
> operator.
>
> Do we (for a /24) enter 254 addresses into the DNS every time we register a
> router block? I don't think that's necessary, although we've done it for a
> select few blocks.
>
> At our current level of usage, perhaps it's enough to register only the first
> 4 or 8 or 16 addresses in the block so that experiments can begin, and
> register more as activity grows.
>
> In effect, this makes each router/gateway operator a delegated coordinator
> for his subnet block, as all further allocation from his block has to be
> coordinated with him.
>
> Is this getting too complicated?
>
> Ideas?
> - Brian
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
