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
Whoever owns station iq0rf.cisarnet.ampr.org. please top transmitting
to ve3zda.ampr.org.
It's been repeatedly sending encapped lines since yesterday and getting
nowhere of course....
here's an example of the line I'm getting...ever second or two.....
16:37:34.478957 IP 94.101.48.134 > 192.168.1.150: IP 44.208.0.1 >
224.0.0.5: OSPFv2, Hello, length: 56 (ipip-proto-4)
73, Don - ve3zda
Just something I've noticed, I'm sure there are gurus on here that can
add to it, or totally take it apart - I'd like to hear your thoughts.
> First of all, I hope everyone had an okay christmas. As well, I
> would like to wish everyone the best for the upcoming new year.
>
> Has JNOS always been 'slow' ?
>
> This might be hard for me to explain, but when you are connected
> to a JNOS station and you hit enter to send a command, you may have
> noticed it might take a 'second' for it to be 'processed'. It's not
> a lightning fast response time is it now. I noticed this while trying
> to connect to my own JNOS via a 3 'wire' led/phototransistor dummy
> serial load (bounces data right back at the same interface). And to
> be frank, I've noticed it in many other occasions. Forwarding should
> never take so long, netrom is always painfully slow, and so on.
>
> Was it always like this (for the linux version) ?
>
> Or did this start happening back when I did the kernel change, back
> when I was somewhat forced to use the setcontext() functions instead
> of setjmp() calls and such. Version 2.0e and earlier use setjmp()
> methodology, 2.0f and older use the setcontext() functions.
>
> Was the DOS version the same too ?
>
> SOOOO - Want to see JNOS go like lightning ? It's easy enough :
>
> edit timer.h, change MSPTICK to 1 (normally it's 55)
>
> rm domain.o main.o rspf.o timer.o unix.o
>
> make
>
> CONSEQUENCES - your timers will expire much faster now, but the system
> clock will be fine. But as an experiment, give it a try, tell me what you
> think. Not sure if this was always the way it was, perhaps due to inadequate
> CPU for it's time, I don't know.
>
> I'm going to play with this a bit, a patch will be released in the near
> future so that the timers behave, but JNOS will suddenly come to life !
>
> I've known about this for some time, but my experimenting that I've been
> doing over the christmas holidays kinda brought it up again. Never thought
> how noticing the delay between laser diode flashes can refresh one's memory
> on the topic.
>
> Maiko Langelaar / VE4KLM
>
> howdy all, have been looking into inter-operability of INP3 with netrom
> quality-based routing, and see there has been work done for older
> kernels but cannot find anything recent:
>
> http://sharon.pi8zaa.ampr.org/users/pe1rxq/inp3.html
>
>
> Maiko has ported this code to jnos I believe, but I don't see any
> linux-native ports of the code more recent than kernel 2.6.4...I'm
> running linux mint 10 and
> mint 13 in my machines, and the kernel is much newer, haven't tried the
> patch yet on the newer 3.0+ kernels, anyone had any experience with this?
> Cheers,
> John
Hi John,
I ported the patch to kernel 2.6.35, which I believe is what Mint 10 is based on.
However, I found serious deadlock issues that arise when nodes are withdrawn. For details, and a link to the ported patch, see my post here:
http://www.spinics.net/lists/linux-hams/msg03116.html
73, Matt VK2RQ
There is a tunnel on the encap list that needs correction (recursive
routing):
route addprivate 44.131.192/29 encap 44.131.192.1
I have also noticed that routing from the public internet doesn't go any
further than the 132.239.255.131 host at UCSD, but I've only spot test a
few hosts other than myself.
If anyone is interested in using a Cisco router for GW connectivity, I
have a 7206 (non VXR) chassis(empty) up for grabs/trade.
73
Jason
