| |
N1URO > PACKET 08.01.19 07:54l 91 Lines 3724 Bytes #999 (0) @ WW
BID : 15319_N1URO
Read: GUEST
Subj: Re: G4APL > Re: Node excessive Broadcasts
Path: IW8PGT<IR2UBX<F1OYP<ON0AR<GB7CIP<N1URO
Sent: 190108/0539Z @:N1URO.#CCT.CT.USA.NOAM #:15319 [Unionville] $:15319_N1URO
From: N1URO@N1URO.#CCT.CT.USA.NOAM
To : PACKET@WW
Paul (et al);
> Thank you Brian for the above comment.
You're most welcome. Just trying to be helpful.
> Yes Brian, I quite often Bang my VERY BIG DRUM !!!!
> That your URONODE software that you share with us
> is a
> USER FRIENDLY FRONT-END
> (it is NOT a SYSTEM or a SYSTEM BUILD)
> that sits on top of the
> Linux Kernel, Libs, software binaries, ax25, libs, tools,
> app, netrom and other related code as configured by the Sysop.
There's many however who think otherwise including other developers. For
them I hope this clarifies things for everyone. I took great steps to make
how the netrom part of it interacts with other systems and received some
incredible input from W0RLI/SK on it, while reading the Software2000 specs
(the creator of NetRom) to make it as efficient as possible to command the
kernel stack. I'm very glad it works out well for those who use it.
> As you know, I run a very complex firewall(s) rule set here
> across all my Interfaces.
Yes, this I know quite well!
> What I am 'saying' we need to stop these unwanted data
> broadcast coming INBOUND ON OUR ISP Paid for BANDWIDTH..
I totally agree. Unless links are coordinated, I doubt they'll function
properly. This is important to maintain the integrity of any network ham
or otherwise.
> Yes I am blocking the worse offenders that are hitting
> the firewall and logging them (as I am interested
> the 'Abuse of our Network' as part of my Network Management
> Monitors).
Sometimes you have to do this as unfortunate as it is.
> Blocking at the local firewall Does not STOP the ISP bandwidth
> being used up. It is still being 'Clocked' on the ISP download
> to the Home User.
> As in the example made by Paul ZL4AX recently.
Absolutely and I also made mention of this to Paul. The junk traffic still
needs to pass through the end point CPE (customer premise equipment) in
order for the firewall to do it's job which still means the meter on the
byte count keeps ticking even if you drop the frames. Some countries and/or
ISPs don't charge by the bytes, others do and for those who are charged by
the byte count this is extremely unfair to those sysops who are trying to
run a service for their community and for other hams to enjoy. Coordinating
links is only common courtesy between sysops and when they're done right
everyone can enjoy them - sysops and users!
> The main point I am trying is to do.
> Is to encourage others to learn and do the same for 2019.
Point well made and would be a great new year's resolution!
> Others will find your IPTABLE rule set a good example of how to
> to apply or modify the behaver of the inbound 'Network Abuse'.
It helps one direction only but still helps. Fortunately with the
native linux stack even if a node injects you with itself and its
neighbors link is not allowed until the sysop sets it to link on
the receiving end so as far as a non-ham entering the network there
is still that level of security. Automapping is not an option and this
is a very good thing in this case!
> Amateur Radio Networking, learn and experiment.
Absolutely and there's plenty of us "village elders" around still to help.
As for those who use IPs assigned by their ISPs the use of 44-net may be
even more beneficial as they do keep watch and try to verify who's on it
is indeed a licensed ham and not some pirate posing as one. You also get the
added benefit of error correction at the IP level rather than lacking it
at the UDP level and the links are static IP based, not dynamic which can
screw up links if DNS is lost. Just some things for others to think
about.
73 de N1URO
Read previous mail | Read next mail
| |
