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
POL: Potrzebuje pomocy.
Jak modem podłączę pod ttyS0 (iobase 3f8 irq 4) na płycie głównej modem
działa idealnie nadaje
i odbiera. A jak podłączę go do ttyS1 (iobase 2400 irq 177) na karcie I/O
to tylko odbiera nie
chce nadawać
ENG: I need help.
How do I plug the modem into ttyS0 (iobase 3f8 irq 4) on the main board
modem works perfectly
transmits and receives. And when I connect it to ttyS1 (iobase 2400 irq
177) on the I/O just
does not want to give answers
------
POL: Mam komputer z 2 modemami Baycom
Linux CentOS 5, Kernel 2.6.18-274.18.1.el5ax25.2,
używam sterownik: baycom_ser_fdx
ENG: I have a computer with two modems Baycom
Linux CentOS 5 Kernel 2.6.18-274.18.1.el5ax25.2,
I use the driver: baycom_ser_fdx
------
POL: Używam modemów Baycom, podłączone do karty I/O PCI
Modemy tylko odbierają (Rx) ale nie nadają (not Tx)
ENG: I use Baycom modems, connected to the I/O PCI
Modems only receive (Rx), but does not transmit (Tx not)
------
POL: A to konfiguracja karty I/O z komendy: lspci -vvv
ENG: And this is the configuration I/O card with the command: lspci-vvv
Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:3253
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 177
Region 0: I/O ports at 2400 [size=8]
Region 1: I/O ports at 2000 [size=8]
Kernel driver in use: serial
------
ttyS0, iobase: 0x03f8, irq: 4 (mainboard)
ttyS1, iobase: 0x2400, irq: 177 (Card I/O)
ttyS2, iobase: 0x2000, irq: 177 (Card I/O)
------
baycom_ser_fdx: version 0.10 compiled
hdlcdrv: version 0.8 compiled
POL: Może ktoś mi powie dlaczego na ttyS0 działa idealnie a na karcie I/O tylko
odbiera ....
Gdzie mam błąd. Może w baycom_ser_fdx.c ???
ENG: Can someone tell me why the ttyS0 works perfectly and on the I/O only ....
Where do I receive an error. Maybe baycom_ser_fdx.c???
--
73 de Janusz / SP1LOP
===== Janusz J. Przybylski, SP1LOP ==================
Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003
=====================================================
Dear Bob VE3TOK (and thanks to VE3ZDA and N2NOV),
Your entry is on my route table, I'm using rip44d (not encap), so my
updates are live. The IP of my gateway is correct in the Portal. I use
the -a switch to remove my own route (and have updated it to the correct
IP); and I still receive rip44d updates over AMPR (showing that I have
not lost connectivity to the Main AMPRGW).
From testing connectivity to your subnet, I have determined that my
44GW is operational; and that some gateways may not have yet updated
their encap.
Thanks for your help; I waited a few days to to be sure that was not the
case; as I know all stations do not have dynamic routing updates, I'll
wait longer next time.
73,
Lynwood
KB3VWG
http://44.60.44.10/tools
@kb3vwg-015:~$ ping 44.135.85.1 -c 10
PING 44.135.85.1 (44.135.85.1) 56(84) bytes of data.
From 44.135.85.30: icmp_seq=7 Source Quench
From 44.135.85.30: icmp_seq=8 Source Quench
From 44.135.85.30: icmp_seq=9 Source Quench
From 44.135.85.30: icmp_seq=10 Source Quench
--- 44.135.85.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9003ms
@kb3vwg-015:~$ traceroute 44.135.85.30
traceroute to 44.135.85.30 (44.135.85.30), 30 hops max, 60 byte packets
1 kb3vwg-001.ampr.org (44.60.44.1) 0.724 ms 0.238 ms 0.218 ms
2 linux.ve3mch.ampr.org (44.135.85.151) 51.890 ms 55.835 ms 60.720 ms
3 port.ve3mch.ampr.org (44.135.85.30) 63.642 ms 62.613 ms 66.477 ms
@kb3vwg-015:~$ ping 44.135.85.30 -c 5
PING 44.135.85.30 (44.135.85.30) 56(84) bytes of data.
64 bytes from 44.135.85.30: icmp_req=1 ttl=39 time=53.9 ms
64 bytes from 44.135.85.30: icmp_req=2 ttl=39 time=51.8 ms
64 bytes from 44.135.85.30: icmp_req=3 ttl=39 time=87.4 ms
64 bytes from 44.135.85.30: icmp_req=4 ttl=39 time=52.7 ms
64 bytes from 44.135.85.30: icmp_req=5 ttl=39 time=51.9 ms
--- 44.135.85.30 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 51.899/59.607/87.406/13.919 ms
Steve,
I am running EchoLink Proxies at 44.60.44.253:443 and 44:60.44.254:80
I am woking on a SIP based VoIP system, it is not up at this time.
~Lynwood
KB3VWG
Hey folks,
I'm going to stand up a quagga server over at 44net-tunnel-endpoint.org
in the next week or so. Would any of you be willing to give me a
private feed of the v4 table (and v6 if you've got it) using a reserved
AS number on my end? It's been a while since I've done this, so be
gentle with me ;-)
From http://tools.ietf.org/html/rfc1930:
10. Reserved AS Numbers
The Internet Assigned Numbers Authority (IANA) has reserved the
following block of AS numbers for private use (not to be advertised
on the global Internet):
64512 through 65535
Thanks much!
C.J.
44net-request(a)hamradio.ucsd.edu wrote:
> Last time I tried doing
> whois on a name it failed. The spammers have made it impossible to put up a
> whois because they mined them all for valid emails so organizations had to
> abandon it.
Maybe it varies between TLDs. I never got much spam that I could trace to .nl domain
name registration (note that .nl now no longer reveals contact info via whois, but they
used to in the past).
On the other hand, what really buried me in spam is registering for some port
numbers and a organization unique ID at IANA. They published the requester's
mail in a text file on their site, and for port numbers it is in /etc/services. I have
had to abandon some mail addresses because of it.
Rob
44net-request(a)hamradio.ucsd.eduwrote:
> Rob,
>
> I have a dutch licence and there is nothing in there about host names.
>
> Is this only a requirement for unattended gateways as these need a
> separate licence
> from the government there?
>
> Bob (Boudewijn) VE3TOK
I reply to this item only to avoid posting several messages, but I have read the other replies as well.
Back in the days when we were still doing a packet network, the situation was like this:
The license said "each packet should be identified by the callsigns of the station where the
traffic originates from, and the station that is actually transmitting the packet".
This made point-to-point packet legal, as well as digipeated packet. Both comply to that
requirement.
The method used by NET/ROM was illegal. It transmitted packets from the nodes using a modified
originator callsign. The packets had the callsign of the original source, but not the callsign of
the node that was transmitting them. When I adapted NET/ROM into NET, I created a system
where the exit node transmitted a "faked" digipeated packet that looked like if the node had
actually digipeated a packet (while it in fact was making a downlink connection). That made it
formally compliant to the license requirements, and was also more convenient for the users as
it showed where the traffic was actually coming from. The same thing was done in Germany,
in other software.
Then look at IP. An IP packet transmitted via the network and sent by a node/router has the
AX.25 callsign of the node transmitting it, but does not carry the callsign of the original source.
Someone consulted the authorities about it. He got the assertion that it would be accepted
as identification if there would be a publicly available mapping between IP address and callsign,
so they could consult that when wanting to determine the source of the traffic.
All the time after that, the hosts file for the Netherlands has been publicly available both on
the BBS system and on telephone BBS (in those days) and Internet (later). And there was the
Internet DNS with this information.
It may be that the current license no longer explicitly states the callsign requirements, there
have been changes. I just have continued to always use the callsign as part of all hostnames
assigned to allocated IP addresses within 44.137... (callsign.ampr.org or label.callsign.ampr.org)
Note that all this is only the situation in the Netherlands, I have no idea how regulations are
in the US or elsewhere. Also note that all this is mostly academic, as packet radio is now
formally illegal in the Netherlands except for stations with a "notice of variation" for unattended
operation.
Why that, you ask? Well, it went like this. There has always been a NOV requirement for
unattended stations. Nodes, repeaters, BBSes etc required such a notice from the authorities
to allow operation without the operator being present. User's packet stations did not require
this NOV as long as the operator was present during use of the station. And many operated
on the edges of what was really allowed, it wasn't really enforcible anyway.
(e.g. the station transmitting a file while you are watching TV or sleeping, is that "attended"?)
Of course an unattended phone repeater also requires a NOV. To get one, one needs to fulfill certain
criteria like a minimal distance to another repeater on the same band. And there is co-ordination
to distribute the limited number of channels. There are always some people do not want to play
within those rules and started operating "attended repeaters" on all kinds of imaginable
channels, and D-STAR hotspots, sometimes after a request for an NOV was denied to them.
It somehow irritated the authorities and they redefined the "attended" requirement: it must be
the operator himself, either directly or via some authenticated link guaranteeing it to be only him,
who keys the transmitter. A repeater or hotspot, where the transmitter is keyed by the reception
of a signal not from the operator, is now declared to be in requirement of an NOV no matter if
the operator is actually present or not.
And it is also stated that there will be increased effort to monitor and effectuate this regulation.
Unfortunately, a packet station, even with the operator sitting at the keyboard, is now outside
these bounds. The transmitter is keyed as a result of someone transmitting towards you, if only
to transmit an acknowledgement. And this is explicitly no longer allowed in the definition.
I have no idea if this has been the intention and what they now actually think about packet.
It is very likely that we are only the victim of the desire to regulate the phone repeater mess,
and it was not the intention to disallow point-to-point packet or user-to-node packet as well.
Rob
I am glad to see that IPv6 being available Looking forward on the
progress.
K6DLC
--
Daniel Curry
PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92
IPv6 Sage Certified
San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]
All,
Has anyone attempted to setup an AMPR gateway using Microsoft Windows (http://technet.microsoft.com/en-us/library/cc940485.aspx)?
I surmise that the tunnel setup is straightforward; and ActiveState ActivePerl (http://www.activestate.com/activeperl) can be used to run RIP44d, I have not reviewed the RIP44d file as of yet; but I assume editing the line that adds routes to the Routing Table would be all that is needed. The Perl Packages 'interface' and 'IO-Socket-Multicast' are available through ActivePerl for Windows, has anyone tried a Microsoft setup before; did you have success/failure?
I wanted to make sure no one has already tried the Windows OS before I explore; and if they have, can they provide some insight and instructions.
73,
Lynwood
KB3VWG
44net-request(a)hamradio.ucsd.edu wrote:
> the DNS functionality is a separate module and is not tied to the name of the IP/subnet, not everyone uses their callsign as the DNS name
But that is a license requirement! We need a mapping between IP address and callsign for legal use of IP on amateur radio....
(ID requirement)
Rob
