44net December 2012

44net@mailman.ampr.org

5 participants
5 discussions

44.133.48.66 !!!
by Maiko Langelaar 12 Apr '14

12 Apr '14

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

4 5

(no subject)
by Don Moore 31 Dec '12

31 Dec '12

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

1 0

Discussion about JNOS 'slowness' ...
by Maiko Langelaar 27 Dec '12

27 Dec '12

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 >

1 0

Re: [44net] INP3 recent work?
by Matt VK2RQ 19 Dec '12

19 Dec '12

> 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

2 1

Gateway entry / pub routing
by Jason R Begley 12 Dec '12

12 Dec '12

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

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net December 2012