44net

44net@mailman.ampr.org

4 participants
3196 discussions

Re: [44net] Telnet To JNOS From Public IP Users Not Working
by Rob Janssen 10 Dec '16

10 Dec '16

> Your JNOS is trying to respond directly to the incoming connections rather > than traversing an encap tunnel. This will not work as the upstream > hardware does not know about you and your 44net allocation. You receive > packets over the encap bridge but you respond back directly. > As for how to fix it? Dunno. We need to somehow encap your outgoing default > route for your 44 IP address so that packet response is along the same path > that it came in. Is that the issue? When I telnet to him from internet I do get "established" suggesting that something gets back... But when it is as you write, what you need is "policy routing". that means, the capability to select a (default) route based on criteria like the source address (your 44-net address or your public IP address). The first has to go to amprgw, the second has to go to your ISP. Does JNOS even offer that? It can be solved with Linux or a sophisticated router like MikroTik or OpenWRT, but I am not sure a bare JNOS system can do this. Rob

2 1

Re: [44net] Telnet To JNOS From Public IP Users Not Working
by Rob Janssen 09 Dec '16

09 Dec '16

> Subject: > [44net] Telnet To JNOS From Public IP Users Not Working > From: > "Charles Hargrove" <n2nov(a)n2nov.net> > Date: > 12/09/2016 07:13 PM > > To: > 44net(a)hamradio.ucsd.edu > > > I am having trouble getting users to telnet from their homes to my JNOS box > located at 44.68.41.1 on port 2300. Their seems to be an asynchronous > connections as they try to transverse the UCSD portal. I see my responses > going back to them, but they are just hanging on their side. I have in my > autoexec.nos file "route add default tun1 44.0.0.1" as their is a tunnel > interface between the JNOS and the linux box that it is running on. Does > anyone have any ideas? Thanks. I get a connect but no text. Normally this means there is an MTU issue somewhere, but in this case (trying from net-44) the welcome text appears to be too smal for that kind of problem. it could be a firewall issue as well. Why do you set the default route to 44.0.0.1 instead of 169.228.66.251 ? Is that normal for JNOS? Rob

4 3

Telnet To JNOS From Public IP Users Not Working
by Charles Hargrove 09 Dec '16

09 Dec '16

I am having trouble getting users to telnet from their homes to my JNOS box located at 44.68.41.1 on port 2300. Their seems to be an asynchronous connections as they try to transverse the UCSD portal. I see my responses going back to them, but they are just hanging on their side. I have in my autoexec.nos file "route add default tun1 44.0.0.1" as their is a tunnel interface between the JNOS and the linux box that it is running on. Does anyone have any ideas? Thanks. -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 449.025/123.0 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan "We are fast approaching the stage of ultimate inversion: the stage where the government is free to do anything it pleases, while the citizens may act only by permission." - Ayn Rand

1 0

Re: [44net] LoRa
by Steve L 27 Nov '16

27 Nov '16

>Are hams allowed to use spread spectrum modes in USA? Yes. Speaking of rules... I once asked about data data rates and bandwidth rules for ham radio in other countries. I am interested in learning about spread spectrum rules, and encryption rules for the hobby in other areas for anyone who cares to share. Steve KB9MWR

2 1

Re: [44net] LoRa
by Steve L 27 Nov '16

27 Nov '16

Dean, Thanks for sharing. Range will be the big thing at least for me, so if you get around to testing that, I hope you'll share your results. Though I am really leaning toward the 400 MHz modules. If there continues to be hold up on the MMDVM boards, then I'll likely order some LoRa modules for my winter project instead.

1 0

LoRa
by Steve L 27 Nov '16

27 Nov '16

Since we really need some other data radio options in the hobby, I wanted to mention LoRa. It's a chirped spread spectrum technology used for low power WAN applications, with air transfer rates: 300bps-31.2Kbps. There are 433 MHz modules, as well as 900 MHz and 2.4 GHz. As a staring place, WA2KWR has some code here: https://github.com/fcolumbu/LoRa_Projects/wiki Steve, KB9MWR

2 1

Re: [44net] LoRa
by Rob Janssen 27 Nov '16

27 Nov '16

> Since we really need some other data radio options in the hobby, I > wanted to mention LoRa. > It's a chirped spread spectrum technology used for low power WAN > applications, with air transfer rates: 300bps-31.2Kbps. There are 433 > MHz modules, as well as 900 MHz and 2.4 GHz. Indeed it is interesting, I have looked at it as well when a local telecom company recently announced it has deployed a country-covering network. (by mounting LoRa equipment at all cell towers and locations) They use 900 MHz, which is not a ham band here. But 433 could be useful. It is unfortunate that the datarate is too low for many applications. It could be interesting for APRS-like mobile datacomm or other telemetry, which is also what the commercial network is for. Rob

2 1

postfix/smtp/smtpd flood...
by SP2L 23 Nov '16

23 Nov '16

Greetings. Lately my small amateur server been severely flooded with similar activities: Nov 21 22:54:01 linux postfix/smtp/smtpd[26048]: connect from unknown[200.7.249.218] Nov 21 22:54:02 linux postfix/smtp/smtpd[26048]: disconnect from unknown[200.7.249.218] Nov 21 22:55:01 linux postfix/smtp/smtpd[26048]: connect from unknown[83.70.149.33] Nov 21 22:55:04 linux postfix/smtp/smtpd[26048]: disconnect from unknown[83.70.149.33] Nov 21 22:56:59 linux postfix/smtp/smtpd[26066]: connect from mail.devaney.net[96.91.214.49] Nov 21 22:57:00 linux postfix/smtp/smtpd[26066]: disconnect from mail.devaney.net[96.91.214.49] Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: connect from unknown[83.70.149.33] Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: disconnect from unknown[83.70.149.33] Nov 21 23:02:27 linux postfix/smtp/smtpd[26203]: connect from unknown[186.33.182.12] Nov 21 23:02:28 linux postfix/smtp/smtpd[26203]: disconnect from unknown[186.33.182.12] Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: connect from unknown[unknown] Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: disconnect from unknown[unknown] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: connect from unknown[50.126.82.18] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: lost connection after HELO from unknown[50.126.82.18] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: disconnect from unknown[50.126.82.18] System logs were building up very fast! Created new entries for fail2ban porogram and got rid of this in a few minutes time! In jail.local file added: [postfix-auth] enabled = true filter = postfix.auth action = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp] logpath = /var/log/mail.log In filter.d folder added new filter postfix.auth.conf with regex: # failregex = ^%(__prefix_line)slost connection after (AUTH|UNKNOWN|EHLO) from (.*)\[<HOST>\].* ^%(__prefix_line)sconnect from unknown\[<HOST>\].* ^%(__prefix_line)swarning: hostname.* ignoreregex = # >From now on NO MORE such crap!!! Best regards. Tom - SP2L

1 0

Re: [44net] Wikipedia article on AMPRNet
by Steve L 06 Nov '16

06 Nov '16

Speaking of documentation... Every once and a while I get an email from someone, and it's not clear to them how the IP space is useful, "since everyone on the internet already has a publicly routeable address." Maybe that can be made clearer some where? Just a suggestion.

1 0

Re: [44net] Wikipedia article on AMPRNet
by Rob Janssen 06 Nov '16

06 Nov '16

> Ah, I stand corrected; I've updated the entry. The section on 44.128/16 was > pointing to an obsolete article that incorrectly gave the impression that > that subnet was unroutable like an RFC1918 network, whereas it's really just > reserved for testing. > Unfortunately, there's an article on www.eastnetpacket.net that incorrectly > states that it *IS* an RFC1918-style network and people outside the AMPRNet > are quoting it as justification for using the network AS an unrouted network. Well, that amprnets.txt file of course has existed and has been maintained on hamradio.ucsd.edu for many many years. I have 3 old copies and all of them mention that it may be assumed that any packets with 44.128 addresses are bogons, so this text has probably been there for at least a decade if not much more. Currently this file does not exist anymore at hamradio.ucsd.edu, I presume its function has been taken over by the "networks" menu item at portal.ampr.org. However, that listing does not mention 44.128.0.0/16 at all. When it is desired to change the definition of this subnet, it may be better to provide an explicit new definition, instead of trying to remove the old definition from internet without providing a new one. I think that is not going to work well, given the way information is stored, copied and archived on the web. Also note that this information on portal.ampr.org is only available to registered users, so it would be wise to put some information on a publicly available site as well (maybe a description of the subnetting of net 44 at the top level without all that country-specific info). That could be on the www.ampr.org site. Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net