OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   06.03.04 14:30l 238 Lines 9200 Bytes #999 (0) @ WW
BID : 2969-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 04, 11/14
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<IK1ZNW<ZL2TZE<VK3TE<
      ZL2BAU<ZL2BAU<ZL3VML
Sent: 040306/1121Z @:ZL3VML.#80.NZL.OC #:20459 [Chch-NZ] FBB7.00i $:2969-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 04 Mar 2004 19:44:21 -0500
X-Message-Number: 80

>>Ah, but we can do it overnight in SOFTWARE at the IGates but it
>>would take 10 years to replace all the firmware digis. Thus, it is
>>orders of magnitude easier to do it at the Igates.

>>>Jeff King <jeff@aerodata.net> 3/4/04 2:54:00 PM >>>

>Yeah, but what are you fixing? IMHO, nothing, your just 
>covering the problem up. The fragile low speed RF lans 
>will be continued to be trashed by people who don't care 
>that their paths are excessive.

Not at all.  One of the biggest problems with abusive paths trackers which
dont listen on RF anyway.  THus you cannot contact them on RF but they are
watching themselves on the APRS-IS.  Thats where they will see that their
path is not desired in their area because the local IGate marks his packets
as excessive.

>Better to address the problem, then attempt to cover it up, 
>which ultimately means it will never be fixed.

But this will fix a large majority very quickly at the source and give them
instant feedback.  Soon everyone will get the message better than they are
now.  Its a LOCAL fix done LOCALLy where needed, and only impacts the
absuer in that area.  But the fix is only software and can be easily
implemented.

>And why would it take 10 years to replace all the digi's? 

Actually, it would take forever, because 80% of the digi owners will never
change their hardware...

>I'm making the  assumption most of those running Wide's 
>actually care, and I'm sure they do,  so if they could fix the 
>problem, they could. It has been idenfified DigiNed, plus 
>a KISS rom could fix the problem. 

Yep, and it has been 5  years since DIGI-NED came out and how many digis
run it?  2%?  There is the proof that you cannot fix it at the digis...

>And for your claim doing it "overnight in SOFTWARE" 
>at the igates, why do you  think that is true but not true 
>at high profile digi's? 

Well that's so obvious I'm suprised  you asked! Because you can download a
new IGate in 1 minute and it doesnt cost a cent.  Whereas to replace a digi
takes WEEKS of planning and cost and TIME!!!

>The first assumption, is the guy running a home igate would 
>update his software.... where as a guy  running a high profile 
>digi (in addition to his home station) would not.

No, it is saying thta one of those options is 50 times easier and human
nature says that the easy one will get done and the harder one will NEVER
get done in many areas...

Bob

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 4 Mar 2004 19:48:46 -0500
X-Message-Number: 81

Steve,
Maybe you misread my email because I never said that everyone should use a
two hop path.  If you are talking about my "smart digi" email, I just used
to hops for an example.  The region area would be depicted per the area or
could be automatically figured inside the digi itself so it could be a
flexible system.  It would also know where the nearest I-Gate is so it could
route traffic in that direction as well...  I'm talking about a concept,
nothing in stone.

If you were referring to something else, I apologize because I don't
remember.  Please email me off the list to get me back on track...

Thanks,
Eric KF4OTN

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 4 Mar 2004 19:52:38 -0500
X-Message-Number: 82

But I think this goes against Steve's (K4HG) position in which I agree.  If
there is an area that requires a longer path (the Keys) then why block it?

-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu] 

Steve said:

>No, it only solves 2 and part of 4. There is still no impact on the amount of
>data appearing on the local RF network.

Not directly, but VERY MUCH indirectly.
I still think the majority of users want to be seen on the IS Hence, they
will see the error messages and will fix itt.

>this does nothing to educate the user, because with a position,
>when they go to the find.cgi page they will see nothing but 
>a message saying no position, the weather page will say 
>no data, the message page no messages.

No, it will display his original packet like this:

LID>APRS,WIDE7-7,RELAY7-7:Packet Truncated due to too-big-path in
area...

>It does nothing to adress that this is enforcing your will  upon 
>others, even areas that accept these paths, and are denying access to a 
>resource that belongs to all of amateur radio.

No, it is only enfocing the will of the IGate sysops in each local area who
hopefully are in the best position to take 
action for their local area.  And this is fed back to the
user when he looks on the APRS-IS...  That is what we are looking for is a
feedback path to the user.

And we DONT WANT the feedback path on RF where
it just adds to the load. (and doesnt get to abusvie trackers
anyway...)

>Finally, while it would give me a way to see what is wrong,
>it still places me in the position of getting these emails, 
>investigating them, and answering them.

No this is not an Email thing at all,  It is simply a truncating and marking
of excessive paths at the source of entry into the APRS-IS.  The end user
then sees the feedback when he checks to see his packets on FINDU.

>I'm still very much opposed, you are taking a heavy-handed
>approach in a part of the system not being adversly affected.

I dont see it that way.  I see it as an easy way to get good 
LOCALLY derived feedback to users of abusive paths 
even if they are using trackers and not listening on RF
without adding any further load to the already challenged RF. It is trivial
to implement and thus has very good return on investment.  The ideas to
replace ALL 1000 digipeaters to solve the same problem WILL NEVER HAPPEN....
Hence, this idea to implement the filter when it can be done quickly and
easily...

>Instead of just wiping his data out, we could just shoot him
>or cut his coax. I'd rank the proposed solution just below 
>these two alternatives.

Those are good alternatives too, but not as easy to 
implement overnight in software.

>What is wrong with dealing with these as they become
>known, with a courteous email or snail mail, or a personal 
>visit? This is the way ham radio used to address operator 
>problems...

Because in 12 years of APRS it hasnt worked and with
more and more newbees getting on APRS without 
having evolved through APRS, they just dont get it.

>And as a last resort, after a ham has been educated,
>if he still refuses despite knowing he is causing interference, 
>it can be bumped up to the FCC. I suspect that if the ham 
>is approached in a friendly educational manner this will
>vitually never be needed!

This never works.  No ham likes being challenged.
That is why this truncation at the IGate is such a good
idea.  It says "you may use that path, but you are
not going to get into the APRS-IS with it."   THus
it is his choice.

Bob

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 04 Mar 2004 19:54:49 -0500
X-Message-Number: 83

>How do you combat  operators who run WIDE7-7? 

Some of the problem is because now 70% of all software used on APRS is now
UIview.  And UIview began in Europe where RELAY7-7, WIDE7-7 and TRACE 7-7
are common use.

I have asked Roger and all authors to put dialog boxes in their software
when users enter a long path that WARNS them of the damage to the network
of that selection.  APRSdos has had this from the beginning in 1992.  It is
fundamental for the software to warn users who might not be aware of the
consequences of such settings.

But last time I asekd Roger to please put these kinds of warnings in his
software,  he said no.

Now maybe that was some time ago, but now that his code is sweeping the
USA, it might be time to approach him again... before we are flooded with
the mess that results...

If his software does do warnings now, please correct me

de WB4APR, Bob

----------------------------------------------------------------------

Subject: RE: stir up the path pot!
From:     Jeff King <jeff@aerodata.net>
Date: Thu, 4 Mar 2004 19:58:30 -0500
X-Message-Number: 84

On Thu,  4 Mar 2004 19:38:56 -0500, Steve Dimse wrote:
>>If your goal is getting the packet into the APRS-IS system, the
>>quicker you can move it off RF and onto the internet system, the
>>better for both yourself and other users of the channel.
>>
>True enough, but there can be factors that make the placement of
>IGates impractical or expensive.

It is either true, or it is not. The statement I made stands on its own 
merits. I'm not demanding anyone do this, I am simply stating IF you can do 
this, it will lead to a more reliable system. This is why I was very clear to 
preface that I was responding technically.

...

----------------------------------------------------------------------



Read previous mail | Read next mail


 09.10.2026 17:52:09lGo back Go up