44net March 2013

44net@mailman.ampr.org

33 participants
19 discussions

by Maiko Langelaar

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

10 years, 9 months

Newbie issue

by lleachii＠aol.com

Marc, LX1DUC, Per Brian in a Jan 22 note: 44.0.0.1 responds to pings received from the Internet. It does not respond to pings coming into it over an encap connection to it, for some reason that I've not been able to figure out. I believe it to be a difficulty in getting it to recognize decapped pings. If you are receiving the rip44 announcements, you have properly configured your tunnel to receive IP-in-IP encapsulation from 44.0.0.1. Feel free to use: http://44.60.44.10/tools or http://kb3vwg-010.ampr.org/tools I see your encap as: 44.161.202.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.203.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.229.0 via 46.29.183.253 dev tunl0 onlink window 840 Also, I am unable to ping 44.161.229.126. What script/configuration did you use to enable your tunnel; did you specify a local or remote IP (un-needed)? Feel free to look at my script at http://44.60.44.13/startampr 73, Lynwood KB3VWG

11 years, 6 months

CentOS 5-Baycom-Card I/O Help please

by Janusz Przybylski SP1LOP

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 =====================================================

11 years, 7 months

RIP44d issue/bug

by Marc, LX1DUC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good morning, I saw some odd routing during my tests. So I analyzed the routes added by RIP44d. I modified the code to log the command string to add routes, my suspicions where confirmed: rip44d v1.2 adds every route with a prefix length of /32: (examples) Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.161.0.0/32 via 141.75.245.225 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.129.0.0/32 via 118.22.1.194 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.147.0.0/32 via 121.99.232.227 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.183.0.0/32 via 130.208.168.63 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.94.0.0/32 via 141.224.128.8 dev tunl0 window 840 onlink table 44 All these routes should be /16 I'm trying to figure where the issue comes from, but I'm not a perl addict, so any help is welcome. I have already confirmed that the RIP message contains the correct netmask: IP Address: 44.161.0.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.161.0.0 (44.161.0.0) Netmask: 255.255.0.0 (255.255.0.0) Next Hop: 141.75.245.225 (141.75.245.225) Metric: 1 73 de Marc - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVNjWAAoJEHFIN1T8ZA8vteEP/2oD1ic40dvnuZSOOdvS+NNw BZEaIlI9gmIZ6P2FqJO4ZOs/kXLdKnxDa9hNgAV5+4bZAZyiGQIHFd1+rwIAaZKN quzJ1h7SzYKOJYDRiMIQO8nYdDzNMYKb4H5GhSpCiDWGHnt+OJA+uV8ZXHClj7QV y2AvJDKgrcRaf3Lr4kwghVnIHlmqibxPI2fFv8DuG8sBvIkxjtUJ21MOUq6nJD8z HaCpJRS8169Syl3jq/8DogEvKfjkehaNmczyxWfWcN1t93Lxh+pPGu88iDhh1pNS 3CpVw7nY1aV88fQUURMNRJqB5IEDLyL9z/A6oU8t4u095SS6wj3wbzs7HpY37Oc4 UsLbqLlH88wkc1AnW5PrrzNLNyjEX4/3y1zywhwJFaVWUGRTAVKC3fB8Q4hhg0/M r6q5LfjbFJzvZYppvsoqDMCAYHsAcg5lTP92+I1/86avntSW1Kj8bIJnrr/wGfZz zbURMk+9U2WJlX6mnmm/Z0a/Lo+l3/T74CzXDDmr8dvEaMB9r7AeTx3M7h6H/jBi yNrFZtwCg/ZMDcCR8jtAN8dqNOYht5uL/+N9dPZy50cyMhLjxVItl6BXrUYdXGqD 2p8zXKjwc8iPLuirvXs3cFK4dioDyJviMDTPSXss01zMBpLqj80UVltIV+xmMRf9 x6fcW9WXhFYoLN56hrti =0CVp -----END PGP SIGNATURE-----

11 years, 9 months

Re: [44net] Gateways Unreachable after Dynamic IP Update

by lleachii＠aol.com

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

11 years, 10 months

Overlapping gateway subnets

by Michael Fox - N6MEF

I know this is fine in regular IP routing, but is it o.k. with the AMPRgw? I have a gateway that serves a /28 address space. I'd like to do some testing using a couple of the addresses in that space on a different gateway. So, I'd like to add another gateway entry for just those two addresses without modifying the existing gateway entry for the /28. Regular IP longest match should prefer the /32 matches for the new gateway over the longer /28 match for the existing gateway. But before I implement, I wanted to verify whether or not this would be o.k. with the portal database, the amprgw RIP routing mechanism, etc. BTW, this would be a nice, generalized solution for a backup gateway. That is, if the more specific route goes away, the more general route could be used. So, is this o.k. to do or not? If not, why not? Thanks much, Michael N6MEF

11 years, 10 months

Newbie issue

by Marc, LX1DUC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello and sorry to bother you with this. I have added a gateway (46.29.183.253) via the portal and I have added subnets to it. I can see the encap.txt has been updated and I do receive RIPv2 Multicast Messages from 44.0.0.1. I have setup rip44d and it is populating my routing table. Example: #ip route get 44.0.0.1 44.0.0.1 via 169.228.66.251 dev tunl0 src 44.161.229.126 cache window 840 However when trying to ping 44.0.0.1 from 44.161.229.126 I don't get any replies. I have followed the outgoing ICMP packets, they get encapsulated on my gateway and the outer IP destination address is 169.228.66.251. The packet travels without troubles thru AS51405 (the home network of 46.29.183.253) and I can actually see the packet going out to the transit network (currently AS5577, in case you're interested). So I'm really really sure that the IPIP packet containing the ICMP echo request makes it out into the Internet. I have also ran traces on all of the ingress connections towards AS51405 and I cannot see a single coming back from 169.228.66.251. Is there anything I'm missing? I really appreciate your help. BTW I'm allowing inbound packets carrying protocol 4 and ICMP on the gateway, but as I don't see packets addresses towards my gateway in the upstream network, I'm guessing it's not the firewall on my gateway H-i. vy 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRUrArAAoJEHFIN1T8ZA8vXkUP/38puOAwTWz38Y9UEinjz+HM kBLQKzeYUkVH/f1xjjVuqaiqzXss37XeAL9XeRIqkJ8znanWac8LznYl42Zvyrph BVaRvp6+M3m4CRnNpy7LuRFfTW+DVNIS88TR+jiD+GYxXFiXc7sQSL98ozPPHYSu QUl2pb4qqXXkVOmwjbcUami4HsBj18oCtcwE+qVwv73EBlW/S0ff6HiYawnuJPzK yznMEeStR58K1+9IfX+o6S406JT8VnBJDQ7W6WHU0aHv3qLA+FM7Mk5DBEtHJRE5 5lwkqFwq71XSmQAX2oGWaC1rTk6pBJoSgjGAEssioP7D1hqJAHuc2fR15zDQkxXW L7z39xc/J2z7sZleqlqldjeY9+7pA+w6opJTaZFjdMdf+yq/zuJPpWv36Pm616xy zPnNorLHwe2WJL79+4ZPzDZamp355ATO7LFF38sx8rHJiXGuP+wb1Udi2fSG9J1O 5jYM4XHKWQnVRdTeit2WkUoEW0c+pgN0nsQ4iReXEragXdmhnpXmQhagKZP10/S5 0TMplR1D/3LLVTMRnjhxyUfY9ZtA6dw1S9DyZQadeJh6Y0KD5QoistEOgXqMnoZS a+c5GN/cc/BSxdHrLnc+yk9FxjL+I2fuU6bwuf27fjcXuTSoGglqZMCMM636Rkj1 scOCTXhoQdfwIeA5aV/z =Yi7/ -----END PGP SIGNATURE-----

11 years, 10 months

Questions

by Marc, LX1DUC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening dear OMs, I'm really new to this Mailing-List. I have been reading through the information available online but I have a few remaining questions: - - Can there be more than 1 coordinator for one single area (e.g. 2 OMs handling a country conjointly)? - - Do the former tunnels still exist for delegations which haven't been moved/migrated to the new portal? (Or are they offline from the Internet side of things?) - - The new system/portal seems to favor a mesh network of tunnels, are intra-country tunnels (no directly connected to the AMPR gateway but connected via a local gateway (which in turn is connected to the AMPR gateway)) depreciated or unrecommended? - - When I checked a few years ago, very very few networks within 44.0.0.0/8 were announced in the DFZ (like 1 or 2), this seems to have increased. Is it recommended today to announce a delegation or parts of it directly? I'm sorry if these questions have been answered before, I really tried finding them, but I might have searched using the wrong terms/words. vy 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRTip1AAoJEHFIN1T8ZA8vRPAP/0oCcMWjMfOnlvdYxsp3+wUY WVlwG92jKXVxrdXMKDVA+bqqyW6S5+xfMAA/nry0p+m/BbVOALLskcGeZncVspzu MjZzmC+9ueO1hRRiQ9F6gFN0X+tTHDCHJRdJo83J0W4acw8WgFTQv/hxk9DuvySt zzMJp7K0YKfh6bHsyvML4iePh4+Ra0B+3xyW8Dp0hnoesasRuCDBUSuENyp3NGL3 4fRH0FUYB29B+hbXH6aWZlbYe1DhwkrX7V/azeRmbDdgkTFBnfb/uj/+Sqp/H7d/ 80nznr/su/ylxiGgW+fmBcoosbXcGlCzQ75/wT2Hf54k40zOeCPLI37Chc8CRVGd /XgL/UyodGzg/SyJg0bQ/T63v969y/7xvdvUaXH182JyObNextPN+m5Ur6evMjIq s6KhiGoJoLTfFEv/pEIDPPnITSwyx7dWw8IzAUp+UbscbaRNGbywp/T/GuhYpKhR N3z2JJmrKXULp3rW/SYhSuYiMi72VVy83I/vnkVzK8J7CM09b06oenPLpt6Af8r8 2AEVbTKI0nmjBcg7lR9t+FxQSzMC+N3Jglt0RTjI76Uq5PpOdcBHL6/ISmXkYwk9 2H8yBkDz6suy1g5QPxu2WjCntIcgOZYYGNMAYxHRU69XbQMk/9x1BScGmhSMKIeR U8de5N0G64S6JxdgtovR =AKXa -----END PGP SIGNATURE-----

11 years, 10 months

encap.txt

by Jann Traschewski

Hi guys, there are some "suspicious" entries in encap.txt: route addprivate 44.131.192/29 encap 44.131.192.1 route addprivate 44.24.115.17/32 encap 44.24.115.17 There are even some other gateways listed with IP-addresses out of 44/8. 73, Jann DG8NGN -- Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

11 years, 10 months

Re: [44net] Portal registrations

by lleachii＠aol.com

Bill, WA7NWP, I'm not sure this is best suggestion for many reasons: - There was a discussion a few weeks back where it was determined that all stations do not necessarily run telnet (while having others test connectivity to my station, some were attempting to telnet to me). For example, my station is not a TNOS/JNOS based router, and therefore does not provide Converse (the telnet-based service we're referring to) by default. Under that guideline, my allocation would be purged. - We also determined that, while all stations should make their IP addresses ping-able, that was not necessarily the case (either by intent or error). - For various reasons, AMPRNet allocations may not necessarily be online or available through AMPR - A Station does not necessarily have to download the encap to have a working allocation (one could manually add static routes from the portal list or use RIP44, for example) - It would be impossible to use the download guideline for those using the RIP44 routing protocol, as it is multicast; and doesn't know what stations are receiving it or using it We have to be mindful that all stations may not be identically configured, use the same Operating Systems, routing protocols nor system configurations to accomplish connectivity to AMPRNet. 73, Lynwood KB3VWG On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Automate it for now and the future... If a client doesn't > ping/poke/telnet/download or whatever within 30days/3months/whatever - > purge the entry. You know - just like DHCP but at a higher level.. > :) > > Bill, WA7NWP

11 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2013