- 44net - mailman.ardc.net

USENET news on AMPRNet
by Brian Kantor 06 Sep '17

06 Sep '17

If you're one of the very few people who have ever taken advantage of the ability to read USENET news via AMPRNet and the news.ucsd.edu server, you should be aware that that server is failing from old age and will be taken out of service soon. We don't plan to replace it; Usenet itself is fading away. I co-authored the NNTP protocol some 31 years ago; that's a pretty good run for any internet standard. If you really need your Usenet fix every day, you might want to investigate www.eternal-september.org, which offers free Usenet access (but has very limited resources). - Brian

1 0

List Access
by Fredric Moses 06 Sep '17

06 Sep '17

Brian, Can we make this list open to just those named in the description of the group… amprnet users and gateway operators for ops related items. -- Fredric Moses - W8FSM - WQOG498 fred(a)moses.bz

2 1

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 05 Sep '17

05 Sep '17

> I think you meant /48’s or at least a /63 -- a /64 is meant to be the > smallest subnet -- it is not meant to be sub-divided any further. Because > some ISPs are allocating /64’s to their customers, I also think a ham-radio > allocation would be good. A /64 would be enough for a radio amateur with a simple network who wants to join a ham-radio network. It would surely not be optimal, but I would not expect an ISP that is that clueless (to allocate a single /64 to their customers) to be willing to route foreign network space to their customers. So what use would it be to have portable address space as a solution for that? Rob

1 0

IPv6
by John D. Hays 05 Sep '17

05 Sep '17

I added a few IPv6 addresses for those who want to try. dig -t AAAA k7ve.ampr.org dig -t AAAA nw7dr.ampr.org dig -t AAAA a.nw7dr.ampr.org dig -t AAAA b.nw7dr.ampr.org dig -t AAAA c.nw7dr.ampr.org dig -t AAAA ar-dns.ampr.org -- ------------------------------ John D. Hays Edmonds, WA K7VE <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>

6 5

Re: [44net] An anniversary of a sort - 36 years
by pidpawel 04 Sep '17

04 Sep '17

It's important to be aware of the timeline but this anniversary might also be a good time to look back at the history and think about the impact this assignment has made. What *new* technologies has been developed because of this network? Which crises have been mitigated using this network? Have it helped to spread the HAM radio "spirit" to the young people? What other good things have this network done? It's very sad for me to say that the only thing I can see about this network is a bunch of guys trying to stick with old technology (RIP? please.) at all cost and arguing who is more important in a tree of people allocating numbers. A /8 network is a great value nowadays, the IPv4 especially in Europe is in a huge crisis and getting new addresses is nearly impossible. From the other hand most of the address space in this network is unused but when you try to request allocation for yourself you can easily get rejected because of silly reasons. (I didn't even try to request one for myself after my friends showed me the coordinator responses.) There might be some things going on the used parts of the network but I couldn't find any example that could be genuinely useful to the world. Could you please prove me wrong or if I'm right try to consider sharing the address space with a "new" movement of hacking and hackerspaces? HAM radio should be all about hacking [1] but frankly speaking I don't see much of it in HAM radio space these days. There are some exceptions - i.e. "OFDM modem" thread from the last days but there are as rare as freakin' unicorns. This message is not meant to be mean. I'm just trying to pinpoint some things I've seen as an observer of this network and HAM radio (mostly in Poland but also the "worldwide" parts) and share some ideas how the things can be done better and provide a better value to the whole world. [1] https://en.wikipedia.org/wiki/Hacker_culture -- I wish you all the best SQ9PID

7 11

IPv6 Firefox add-on
by Tom Kloos 04 Sep '17

04 Sep '17

Hi, Try "sixornot" for IPv6 status: https://addons.mozilla.org/en-US/firefox/addon/sixornot/ It works great for me with FF release 55 and 56 beta. Depending upon what version of Firefox you're using the web site may say "This add-on is not compatible with your version of Firefox.". This is due to Mozilla killing off all add-ons not implemented with WebExtensions starting with FF version 57. sixornot will still run fine up through FF version 56. Download it anyway! After FF 56 you'll have to switch to the PaleMoon browser (sixornot works great on it for me too). 73, -Tom WS7S At 12:16 PM 9/4/2017, you wrote: >Does anyone know of nifty little firefox add-on that will denote that >you are connected via IPv6 to the site? I'd like to be more aware of >what all supports it in the course of my general browsing. I think >that could really bring an awareness. Kind like the more recent "This >site may not be secure" when Browsers detect login details over a non >HTTPS connection. > >Having to sniff it with netstat to tell if its 4 or 6 is less than appealing.

1 0

Re: [44net] IPv6
by Steve L 04 Sep '17

04 Sep '17

John, I see IPv6 to http://nw7dr.ampr.org/ with netstat: TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65219 [2001:470:b:40f::3]:http ESTABLISHED TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65220 [2001:470:b:40f::3]:http ESTABLISHED TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65221 [2001:470:b:40f::3]:http ESTABLISHED Pinging k7ve.ampr.org [2001:470:b:40f::2] with 32 bytes of data: Destination host unreachable. Destination host unreachable. Pinging nw7dr.ampr.org [2001:470:b:40f::3] with 32 bytes of data: Reply from 2001:470:b:40f::3: time=99ms Reply from 2001:470:b:40f::3: time=102ms Reply from 2001:470:b:40f::3: time=117ms Does anyone know of nifty little firefox add-on that will denote that you are connected via IPv6 to the site? I'd like to be more aware of what all supports it in the course of my general browsing. I think that could really bring an awareness. Kind like the more recent "This site may not be secure" when Browsers detect login details over a non HTTPS connection. Having to sniff it with netstat to tell if its 4 or 6 is less than appealing.

2 1

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> Phil Karn, KA9Q, invented the /N network-bits-width notation back in ham > AMPRNet-related documents in the 1980s, so it should be more properly > known perhaps as "Karn notation" rather than "CIDR notation". That certainly would be good, he has done tremendous work for the acceptance of internet protocols. > I like to bring this up from time to time to remind people that inventors > deserve credit especially when they don't charge for their inventions. Some time ago I noticed that my hack in PE1CHL-NET version 950819 (Aug 19, 1995): TCP SYN packets are examined when routed, and the MSS option will be adjusted down to the maximum MSS possible on the incoming and outgoing interfaces. Thus, a more optimal end-to-end MSS is chosen, and fragmentation is avoided (e.g. when running IP over NET/ROM somewhere inbetween the endpoints) pre-dates the addition of this feature in e.g. Cisco routers (ip tcp adjust-mss) by several years.... that would certainly have been patentable... > I'm reminded of this because Phil and I had dinner last night (he's > doing well, thanks) and got to chatting about the old days of packet > and AMPRNet. Great to hear that! Rob

1 0

Re: [44net] An anniversary of a sort - 36 years
by Steve L 04 Sep '17

04 Sep '17

>> I guess the more pertinent questions I have for Brian would be: >> >> Are there a plan so that folks who only have IPv6 commercial address >> or are suck behind carrier grade IPv4 with no firewall access (some >> cellular carriers presently) can participate with the amprnet? In >> other words are there plans to make amprgw dual stack? > >(I think you meant 'stuck', not 'suck'. Is that a Freudian slip?) > >There's no plan to make amprgw dual stack. I'm not sure that the question >is meaningful; what would it DO with an incoming IPv6-only packet? >It's not going to be a NAT64 gateway, that's for certain. Okay, its just something I have been wondering. I feel as commercial IPv4 addresses become more scarce, and more carrier grade NAT comes into play there will be more hams looking for solutions for the various internet ham radio services (IRLP, Echolink, D-Star etc), where they need the ability to control their port forwarding/firewall stuff. Basically I see a large number of folks seeking commercial VPN services. > >Interoperability of IPv4-only and IPv6-only hosts is a sticky wicket >that in my opinion NO ONE has solved satisfactorily. >- Brian I am slowing learning what a complicated mess it is (going to be) myself.

1 0

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> My interpretation of the question was whether the gateway would support > tunnels running over IPv6 to carry 44/8 traffic. That way, endpoints on > DS-Lite, for instance, could tunnel their 44/8 traffic over IPv6, and > those of us with dual stack might be able to avoid the usual issues with > routers that don't support IPIP encap packets over NAT properly. I'm not sure amprgw is the place to do that. The IPIP tunnel network is a mesh, and such endpoints would not be able to participate in the mesh. On the other hand, local gateways could offer this service to local users, when they are both on IPv4 (to participate in the mesh) and IPv6 (to service local users). E.g. we offer connectivity to local users on our gw-44-137 using various different protocols (all over IPv4): - IPsec tunnel - GRE (with or without IPsec) - L2TP/IPsec - OpenVPN Some IPv4-over-IPv6 protocol(s) could be added to that when the need arises. However, all ISPs offering IPv6 locally that I know of, offer dual-stack. There have been some requests to offer IPv6 inside our hamnet, but we are not quite ready for that yet (depending on support in routers etc). However, I never received a request to setup a tunnel over IPv6. Rob

2 1

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> Someone else with a more thorough understanding of the IPv6 address > allocation procedure can explain why there will never be a ham-radio-only > block of IPv6 addresses akin to the IPv4 AMPRNet 44/8. It would not be a good idea to have that, because we would again be faced with the difficulty to get it connected and routed. The whole tunneling and BGP issue all over again. When we just want some IP space on internet it is much easier to have everyone use the IPv6 netblock they get from their local ISP, and compile some list of netblocks that are assigned to hamradio that way. So everyone just connects their stuff to internet, and where required imports some list of netblocks that they want to talk to. The distribution of that list can be done using similar mechanisms as are now being used for the tunnel mesh: - use a file that is posted somewhere and that can be downloaded - use some API to retrieve the data (like on the portal) - use a central system that sends the info using some routing protocol (like the RIP daemon) - setup an ad-hoc mesh network that distributes the info peer-to-peer I think the latter option is the best. We can use multihop BGP where everyone connects to a couple of friends and maybe some higher-tier service in the country or continent and they advertise their local netblock(s) there. BGP will compile a table of all netblocks advertised by hams, without any need of a central service or authority. You only need to setup a couple of peerings (a full mesh is not required) so most outages will be covered. This table of netblocks will not be used for routing, only for source-address filtering for ham-only communication. The actual routing over-the-globe will be done directly by the ISPs, no tunneling or special arrangements required, the netblocks are just part of their standard allocation. Locally, you can route over radio in additional to this, using whatever routing protocol is locally customary. When properly configured, radio paths will be taken where possible and other traffic will be routed over internet. I am not the only one proposing this. Daniel Estévez EA4GPZ and others have written about it as well. The reason this is possible on IPv6 is that you normally get a large chunk of addressing space from your ISP so you can easily carve out netblocks to be used for different purposes. When getting IPv6 from your ISP, you should check that they DO assign you multiple netblocks, as is recommended in all IPv6 deployment strategies, but not all ISPs do understand that. (also, it is of course best when your allocation is static and does not change every day or so) Rob

3 2

Re: [44net] Outdated regulations [Was: OFDM Modem]
by Rob Janssen 04 Sep '17

04 Sep '17

> The one thing I know that we need to request is elimination of symbol-rate > restrictions, to be replaced with bandwidth restrictions. I think you should not focus too much on symbol-rate restrictions. As has already been written, using a high symbol-rate usually is impractical anyway. It is better to use techniques like OFDM that combine a high bitrate with a low symbol-rate. You only need to ensure that you can use the bandwidth that is technically required for the experiment you want to run, within the limits of the band and the bandplan, and without causing intentional interference to other users. (i.e. you don't use the entire band. you don't cover the existing small-signal and repeater allocations with your strong wideband signal, etc. spread spectrum allows for some co-existence of wideband signals and other users, but it is not what I am referrring to here) Rob

1 0

Outdated regulations [Was: OFDM Modem]
by Steve L 04 Sep '17

04 Sep '17

I just spotted this. Here is every US hams chance to make direct comments to the FCC. http://www.arrl.org/news/fcc-technological-advisory-council-investigating-t… Steve, KB9MWR

9 9

Re: [44net] An anniversary of a sort - 36 years
by Rob Janssen 04 Sep '17

04 Sep '17

> Ultimately, IPv4 just cannot handle the demands of the modern Internet, > the emergence of IoT (that being a good or bad thing is another matter), > etc. The world needs to move on to IPv6. Actually the problem is less for "the modern Internet" because that has transformed from a peer-to-peer network into a client-server network where most of the users are only connecting to a couple of services, and the presence of NAT is less of a problem. When IPv6 was designed, the designers still believed that every device should be able to communicate with every other device. A peer-to-peer network. That was already frowned upon at the time. Why would my refrigerator need to talk to yours? But as the problem if malvolent users (usually called "hackers" in the press, although that word originally has a different meaning) is becoming more and more prevalent, firewalls have been deployed everywhere and such communication is not possible anyway. Now, when ISPs deploy IPv6 for their customers, the routers they provide are by default configured with a stateful firewall that allows only outgoing connections and possibly has capability to "open" communication to some specific device/port. This is roughly the same as an IPv4 router with NAT and port forwarding. So, while some expansion of the address space is desirable due to the increasing number of users, it certainly is not as critical as the IPv6 proponents claim. (that also explains why the deployment of IPv6 has been such a fiasco) Rob

1 0

Re: [44net] Outdated regulations [Was: OFDM Modem]
by Steve L 04 Sep '17

04 Sep '17

Well we just heard a few days ago that some foreign hams don't have a bandwidth restriction, other than it fits in the band. I haven't heard of any ill effects from over there, but maybe someone from abroad can chime in. I can see it being a concern on HF, where the spectrum is more limited, but I am pretty much with Brain for above 50 MHz. Further more is takes a least a dozen years to make any headway with the FCC, so I highly recommend futuristic thinking when writing comments. Bruce Perens recommended basically do away with the bandwidth limits, and let gentlemans agreements take rule. I think that seems logical. Especially when the alternative is a 10-15 year re-revising the rule, piece meal approach game like we have been playing, that really just impedes innovation. But no one has to agree with me. You just have to file comments to make me happy :-) Further more, I see like less that 5% of the ham population being actually capable of sending a 2 MHz wide signal, so the point is pretty much moot (Everyone else has a Beofeng HT.) >Now imagine someone sending a signal 2 mhz wide on 447 mhz not really cool for the rest of the >Ham community. That is why we need band with limitation

2 1

Re: [44net] OFDM Modem
by Rob Janssen 04 Sep '17

04 Sep '17

> A couple of decades ago, the "GRAPES" WA4DSY 56kbit modem kit was > available for a moderate price. They weren't too difficult to put > together. Alignment did take a scope, but took only a few minutes. About > five people in San Diego had them. As far as I know, only three ever > made it onto the air here. I remember that modem, but also I remember that there were quite some issues at that time. It was not easy to reliably make 56k HDLC using affordable hardware at that time. For interrupt-per-character serial devices the performance of a PC-XT was not quite enough. There were DMA-based controllers but they were difficult to obtain, hard to find reliable drivers for, and expensive. Some people built 68000-based boards for that kind of datarate, and later for 1-2Mbps, also using DMA. I also considered using PC-LANA adapters that had all the data generating hw as a co-processor but were not AX.25 compatible. (they use the NETBIOS interface, I added IP over NETBIOS to my version of NET to be able to use them) However, no real radio link has ever been made here. Of course wide acceptation would have been even more difficult. Today, the computer performance problem no longer exists, but the problem of wide deployment of a locally designed solution still exists. Rob

8 8

Re: [44net] Outdated regulations
by Steve L 04 Sep '17

04 Sep '17

In an online conversation with Brian N1URO, we have both come to the same conclusion: We need a group such as TAPR to start getting more involved with the FCC and bypass the ARRL. I remember back when I never really understood TAPR. I knew what the name stood for, so I always assumed they were the voice representing the digital aspects of the hobby. Then I heard a 2008 Rain report where Steve Bible explained TAPR. http://kb9mwr.blogspot.com/2009/02/tapr-explained.html I wonder if there is any chance of them taking up the role that I thought there were about? And as I stressed before, I feel its important to have a futuristic thought process when making comments as it takes many years for regulator changes to actually happen. And in that light, this is from a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict and speculate what ham radio will be like in 25 years (2037): http://kb9mwr.blogspot.com/2013/09/amateur-radio-in-2037.html Listen to that when you have the time, add your own thinking and start drafting your thoughts to the commission. Steve

1 0

Re: [44net] OFDM Modem
by Rob Janssen 04 Sep '17

04 Sep '17

Very interesting indeed! You are probably aware that there is some activity on Digital ATV and the boards made for that purpose (and/or the cheap dongles they use) could be used for this as well. We have a Digital ATV repeater here that is currently under some reconstruction, and I have suggested putting some IP broadcast on the multiplex. Indeed, as you note, a Linux-based DVB receiver can easily put the demodulated and extracted IP traffic on its LAN interface. More than a decade ago I did some "experiment" logging the downlink of satellite-internet on a Dreambox and it just used standard features of its software. But your test of using this full-duplex (rather than just unidirectional as it was envisioned) surely is innovative. It could be useful here as well, indeed as you indicate to make links on amateur bands for which there is no commercial WiFi equipment. It is not straightforward to use that equipment with transverters, and a steady fullduplex link would certainly be easier. Some people are also working on a 70cm digital access with smaller bandwidth, there is little detail on what modulation they use, it would be interesting to see if using DVB-T2 in halfduplex more is feasible. Probably not, due to high turnaround delays. Rob

7 8

Re: [44net] Outdated regulations
by Steve L 04 Sep '17

04 Sep '17

My bad, I sent this again to the 44net list in error. To many mailing lists! Sorry guys..

1 0

Outdated regulations
by Steve L 04 Sep '17

04 Sep '17

I just spotted this. Here is every US hams chance to make direct comments to the FCC. http://www.arrl.org/news/fcc-technological-advisory-council-investigating-t… Here are some issues that I have been hammering the league on for quite some time; but really its time for everyone to review the Part 97 rules and write comments directly to the FCC. http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html Steve, KB9MWR

1 0

Re: [44net] Outdated regulations [Was: OFDM Modem]
by Steve L 04 Sep '17

04 Sep '17

Michael, The elimination of symbol-rate restrictions has already been proposed since 2013. That would still leave a 100 KHz data restriction for UHF (70cm), and some how that seems unfair when Image modes (ATV) have no restrictions and typically have a 6 MHz wide signal. Bruce Perens had some good ideas a few years back in https://ecfsapi.fcc.gov/file/7022090358.pdf A lot of it was related to codec2, but its all time for us to put on our thinking caps and write comments to the commission. I hope to see some familiar names in the coming days. http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html

1 0

Re: [44net] An anniversary of a sort - 36 years
by Steve L 03 Sep '17

03 Sep '17

Packet radio was a big lure to me when I was in high school in the 1990's. The mainstream internet hadn't yet blossomed, and I was always looking to tap into information networks (voice and data) so I could learn and build stuff. At the same time I read an article by Larry Kollar, KC4WZK on the Amateur Packet Radio Network that was floating around on dial-up BBS's and really caught my attention. One of my Elmer's gave me a pile of NE2000 coax LAN ethernet cards. That combined with watching the trace screen on the various NOS programs really helped my learn how it worked. So I was a young person back then, I can say it helped me immensely understand how the internet works. And I am still learning. (As that is what ham radio is to me). A few years back my internet provider started handing out IPV6 addresses. So on my personal network I started to implement dual stack. And then wondered what good this really does as you are still using a V4 address for the sites you connect to that don't yet support ipv6. Not like you are saving an IPv4 address. Then I learned the next phase would be carrier grade NAT. Fortunately or unfortunately (depending on how you look at it), we are not to that point yet where I live. But you can experiment with the Google NAT64 gateway etc. Since I have some legacy ipv4 radios., I wouldn't mind trying to run my own NAT64 gateway on Linux. But I haven't gotten that far yet. And the documentation out there is a bit foreign to me yet. Another thing I have been meaning to try and do is some sort of 10.x.x.x to 44.x.x.x. 1 to 1 NAT thing for the folks doing Broadband Hamnet/AREDN.

2 1

OT: Confirmed issue: AX.25 binaries failing to run on Raspbian Stretch with predictable network interface names
by David Ranch 03 Sep '17

03 Sep '17

Hello Everyone, I'm currently working Thomas Osterried and Ralf Baechle on this below issue but I thought I'd email this out to the list just in case you hit it. Both Thomas and Ralf have confirmed it and the root issue is the length of the Ethernet interface name which is due to Stretch's new default of using predictable network interface names. Below mentions how to revert back to the classic "eth0" interface naming convention which will get things working again. --David KI6ZHD While running Linpac on the console (not over SSH) on Raspbian Stretch, I would still see errors like "SIOCGIFHWADDR: No such device" but the program wouldn't crash. If I would run Linpac over an SSH terminal, it would crash. I then was comparing straces of linpac running on the console run linpac vs. the ssh run linpac and was gravitating towards various locale issues and trying different environment variables like LANG, LANGUAGE, TERM, etc but nothing was getting me the consistency of *not* crashing when using an SSH terminal. I was then noticing that in the SSH-based sessions of running Linpac, it was constantly coming back to the Raspbery Pi 3's Ethernet interface which is named "enxb827eb5f053b" in Stretch but it's "eth0" in Jessie. -- root@rpi3:/etc/ax25# ifconfig ax0: flags=67<UP,BROADCAST,RUNNING> mtu 253 ax25 KI6ZHD-6 txqueuelen 10 (AMPR AX.25) RX packets 68 bytes 5306 (5.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5 bytes 20 (20.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 enxb827eb5f053b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.24 netmask 255.255.255.0 broadcast 192.168.0.255 ether b8:27:eb:5f:05:3b txqueuelen 1000 (Ethernet) RX packets 735 bytes 55331 (54.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 559 bytes 109673 (107.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether b8:27:eb:0a:50:6e txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -- I've never personally been a fan of the new predictable network interface names but I've dealt with them. On a lark, I disabled the predictable naming convention and brought back the classic eth0 name per making the following change in the /boot/cmdline.txt file: https://serverfault.com/questions/741210/disabling-predictable-network-inte… With that in place.. No more crashes! Man.. that's VERY surprising to me but now that I'm paying very close attention, I'm seeing the same issues in the standard AX.25 programs! When I start the "axbeacon" program with no interface specified (that means it will listen on all AX25 interfaces), I'm seeing: strace -f /usr/bin/listen -artc 2> /tmp/beacon.strace root@rpi3:/etc/ax25# echo $? 22 I've attached that strace as well and it also has signs of persistent Ethernet naming issues (notice below that the full interface name is missing the "3b" at the end of the Ethernet interface name"): -- ioctl(3, SIOCGIFHWADDR, {ifr_name="enxb827eb5f05"}) = -1 ENODEV (No such device) dup(2) = 5 fcntl64(5, F_GETFL) = 0x20001 (flags O_WRONLY|O_LARGEFILE) close(5) = 0 write(2, "SIOCGIFHWADDR: No such device\n", 30SIOCGIFHWADDR: No such device -- I have confirmed this happens with both the 3rd party VE7FET's AX.25 sources ( https://github.com/ve7fet/linuxax25 ) and the standard .deb packages repos supporting Raspbian Stretch. It seems there is an even bigger issue for the Debian .debs as it's axlisten wasn't properly compiled with Ncurses support as it gives the addition error: -- Could not initialize color support. -- At least the beacon program doesn't crash like LInpac but all this confirms there is something wrong here that something just with Linpac. --David KI6ZHD

1 0

Re: [44net] An anniversary of a sort - 36 years
by Steve L 03 Sep '17

03 Sep '17

Well if you look back to the much earlier days a lot of good things came from the allocation. Most of it was the work of Phil Karn and a few others. And maybe it would be good to document that stuff, as most of it was before my time. I know Phil and Brian Kantor were active with the development of RFC's. This contribution was was something that extends beyond ham radio. Phil's NOS development really changed a lot of things. Lead to some FCC rules being changed etc. Again, I am not the person with all the history, but just wanted to make a few brief points. I do hear you though, now-a-days, ham radio in general is in a pretty sad state. You could easily replace the words "our /8 network is of great value these days" with our allocated frequencies are of great value these days. I do agree we really need to reach out to the hacker/makerspace people. I wrote this a number of years ago for our club: http://www.k9eam.org/2011/06/innovating-makerspaces.html There have been a small handful of us that attend their meeting and help them with things. A few got licensed, but so far no one has really dug in deep into the radio side yet. At least the goodwill has been established. Like anything in the hobby and world in general, it takes the right(ambitious) people to make amazing things happen. Steve > What *new* technologies has been developed because of this network? > Which crises have been mitigated using this network? Have it helped to > spread the HAM radio "spirit" to the young people? What other good > things have this network done?

2 1

Re: [44net] OFDM Modem
by Steve L 03 Sep '17

03 Sep '17

I feel Michael, N6MEF is right. There are a number of folks waiting for an appliance-like device. Even if it's lower speed. Like I said as long as it's priced right (about the price of a dual band radio is reasonable). While I'd really like to see a couple Mbps, as long as its capable of doing a gsm audio stream or something like that it will be fun. Something that will work in my car, with a raspberry Pi attached, to create my own digital voice thing of sorts, or maybe plug an IP phone into. Yes this day in age its sad we will settle for dial-up speeds, but hey its a start till someone like Bruce Perens takes over the ARRL :-) I have hemmed and hawed over plunking down the money on something other than a receive only SDR like the RTL, NooElec, SDRplay stuff that I have been playing with. But that 5-10 mW out of the BladeRF, etc really isn't useful to me. We need some low drive amps at a decent price. Steve

1 0

Re: [44net] OFDM Modem
by Steve L 02 Sep '17

02 Sep '17

I hope there is something. Wisconsin is the land of heavy tree cover, and where I am, the geography is pretty flat, so obtaining line-of-site really requires a well connected person/club to get access to commercial tower sites. So while lower speeds are less desirable, if there is some power behind the thing to go more than a few blocks non line of site, I'll give it a try if it's priced right. >Unless they've come up with a modulation scheme which overcomes the >multipath distortion of transmitted symbols, I believe line of sight is >practically a necessity. > >But I'll be the first to admit that my communications theory knowledge >is now many decades old. Perhaps there is a way around it. >- Brian

1 0

An anniversary of a sort - 36 years
by Brian Kantor 02 Sep '17

02 Sep '17

[Notice the entry in the middle of page 3. This is the first publication of the assignment of network 44 to amateur radio that we can find. - Brian] --- Network Working Group J. Postel Request for Comments: 790 ISI September 1981 Obsoletes RFCs: 776, 770, 762, 758, 755, 750, 739, 604, 503, 433, 349 Obsoletes IENs: 127, 117, 93 ASSIGNED NUMBERS This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Jon Postel. The assignment of numbers is also handled by Jon. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, or network number please contact Jon to receive a number assignment. Jon Postel USC - Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90291 phone: (213) 822-1511 ARPANET mail: POSTEL@ISIF Most of the protocols mentioned here are documented in the RFC series of notes. The more prominent and more generally used are documented in the Protocol Handbook [17] prepared by the Network Information Center (NIC). Some of the items listed are undocumented. In all cases the name and mailbox of the responsible individual is indicated. In the lists that follow, a bracketed entry, e.g., [17,iii], at the right hand margin of the page indicates a reference for the listed protocol, where the number cites the document and the "iii" cites the person. Postel [Page 1] RFC 790 September 1981 Assigned Numbers Network Numbers ASSIGNED NETWORK NUMBERS This list of network numbers is used in the internet address [33]. The Internet Protocol (IP) uses a 32 bit address and divides that address into a network part and a "rest" or local address part. The division takes 3 forms or classes. The first type, or class a, of address has a 7-bit network number and a 24-bit local address. This allows 128 class a networks. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class A Address The second type, or class b, of address has a 14-bit network number and a 16-bit local address. This allows 16,384 class b networks. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class B Address The third type, or class c, of address has a 21-bit network number and a 8-bit local address. This allows 2,097,152 class c networks. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class C Address One notation for internet host addresses commonly used divides the 32-bit address into four 8-bit fields and specifies the value of each field as a decimal number with the fields separated by periods. For example, the internet address of ISIF is 010.020.000.052. This notation will be used in the listing of assigned network Postel [Page 2] RFC 790 September 1981 Assigned Numbers Network Numbers numbers. The class a networks will have nnn.rrr.rrr.rrr, the class b networks will have nnn.nnn.rrr.rrr, and the class c networks will have nnn.nnn.nnn.rrr, where nnn represents part or all of a network number and rrr represents part or all of a local address or rest field. Assigned Network Numbers Class A Networks Internet Address Name Network References ---------------- ---- ------- ---------- 000.rrr.rrr.rrr Reserved [JBP] 001.rrr.rrr.rrr BBN-PR BBN Packet Radio Network [DCA2] 002.rrr.rrr.rrr SF-PR-1 SF Packet Radio Network (1) [JEM] 003.rrr.rrr.rrr BBN-RCC BBN RCC Network [SGC] 004.rrr.rrr.rrr SATNET Atlantic Satellite Network [DM11] 005.rrr.rrr.rrr SILL-PR Ft. Sill Packet Radio Network[JEM] 006.rrr.rrr.rrr SF-PR-2 SF Packet Radio Network (2) [JEM] 007.rrr.rrr.rrr CHAOS MIT CHAOS Network [MOON] 008.rrr.rrr.rrr CLARKNET SATNET subnet for Clarksburg[DM11] 009.rrr.rrr.rrr BRAGG-PR Ft. Bragg Packet Radio Net [JEM] 010.rrr.rrr.rrr ARPANET ARPANET [17,1,VGC] 011.rrr.rrr.rrr UCLNET University College London [PK] 012.rrr.rrr.rrr CYCLADES CYCLADES [VGC] 013.rrr.rrr.rrr Unassigned [JBP] 014.rrr.rrr.rrr TELENET TELENET [VGC] 015.rrr.rrr.rrr EPSS British Post Office EPSS [PK] 016.rrr.rrr.rrr DATAPAC DATAPAC [VGC] 017.rrr.rrr.rrr TRANSPAC TRANSPAC [VGC] 018.rrr.rrr.rrr LCSNET MIT LCS Network [43,10,DDC2] 019.rrr.rrr.rrr TYMNET TYMNET [VGC] 020.rrr.rrr.rrr DC-PR D.C. Packet Radio Network [VGC] 021.rrr.rrr.rrr EDN DCEC EDN [EC5] 022.rrr.rrr.rrr DIALNET DIALNET [26,16,MRC] 023.rrr.rrr.rrr MITRE MITRE Cablenet [44,APS] 024.rrr.rrr.rrr BBN-LOCAL BBN Local Network [SGC] 025.rrr.rrr.rrr RSRE-PPSN RSRE / PPSN [BD2] 026.rrr.rrr.rrr AUTODIN-II AUTODIN II [EC5] 027.rrr.rrr.rrr NOSC-LCCN NOSC / LCCN [KTP] 028.rrr.rrr.rrr WIDEBAND Wide Band Satellite Network [CJW2] 029.rrr.rrr.rrr DCN-COMSAT COMSAT Dist. Comp. Network [DLM1] 030.rrr.rrr.rrr DCN-UCL UCL Dist. Comp. Network [PK] 031.rrr.rrr.rrr BBN-SAT-TEST BBN SATNET Test Network [DM11] 032.rrr.rrr.rrr UCL-CR1 UCL Cambridge Ring 1 [PK] 033.rrr.rrr.rrr UCL-CR2 UCL Cambridge Ring 2 [PK] 034.rrr.rrr.rrr MATNET Mobile Access Terminal Net [DM11] 035.rrr.rrr.rrr NULL UCL/RSRE Null Network [BD2] Postel [Page 3] RFC 790 September 1981 Assigned Numbers Network Numbers 036.rrr.rrr.rrr SU-NET Stanford University Ethernet [MRC] 037.rrr.rrr.rrr DECNET Digital Equipment Network [DRL] 038.rrr.rrr.rrr DECNET-TEST Test Digital Equipment Net [DRL] 039.rrr.rrr.rrr SRINET SRI Local Network [GEOF] 040.rrr.rrr.rrr CISLNET CISL Multics Network [CH2] 041.rrr.rrr.rrr BBN-LN-TEST BBN Local Network Testbed [KTP] 042.rrr.rrr.rrr S1NET LLL-S1-NET [EAK] 043.rrr.rrr.rrr INTELPOST COMSAT INTELPOST [DLM1] 044.rrr.rrr.rrr AMPRNET Amature Radio Experiment Net [HM] 045.rrr.rrr.rrr-126.rrr.rrr.rrr Unassigned [JBP] 127.rrr.rrr.rrr Reserved [JBP] Class B Networks Internet Address Name Network References ---------------- ---- ------- ---------- 128.000.rrr.rrr Reserved [JBP] 128.001.rrr.rrr-128.254.rrr.rrr Unassigned [JBP] 191.255.rrr.rrr Reserved [JBP] Class C Networks Internet Address Name Network References ---------------- ---- ------- ---------- 192.000.001.rrr Reserved [JBP] 192.000.001.rrr-223.255.254.rrr Unassigned [JBP] 223.255.255.rrr Reserved [JBP] Other Reserved Internet Addresses Internet Address Name Network References ---------------- ---- ------- ---------- 224.000.000.000-255.255.255.255 Reserved [JBP] Postel [Page 4] RFC 790 September 1981 Assigned Numbers Internet Version Numbers ASSIGNED INTERNET VERSION NUMBERS In the Internet Protocol (IP) [33] there is a field to identify the version of the internetwork general protocol. This field is 4 bits in size. Assigned Internet Version Numbers Decimal Octal Version References ------- ----- ------- ---------- 0 0 Reserved [JBP] 1-3 1-3 Unassigned [JBP] 4 4 Internet Protocol [33,JBP] 5 5 ST Datagram Mode [20,JWF] 6-14 6-16 Unassigned [JBP] 15 17 Reserved [JBP] Postel [Page 5] RFC 790 September 1981 Assigned Numbers Internet Protocol Numbers ASSIGNED INTERNET PROTOCOL NUMBERS In the Internet Protocol (IP) [33] there is a field, called Protocol, to identify the the next level protocol. This is an 8 bit field. Assigned Internet Protocol Numbers Decimal Octal Protocol Numbers References ------- ----- ---------------- ---------- 0 0 Reserved [JBP] 1 1 ICMP [53,JBP] 2 2 Unassigned [JBP] 3 3 Gateway-to-Gateway [48,49,VMS] 4 4 CMCC Gateway Monitoring Message [18,19,DFP] 5 5 ST [20,JWF] 6 6 TCP [34,JBP] 7 7 UCL [PK] 8 10 Unassigned [JBP] 9 11 Secure [VGC] 10 12 BBN RCC Monitoring [VMS] 11 13 NVP [12,DC] 12 14 PUP [4,EAT3] 13 15 Pluribus [RDB2] 14 16 Telenet [RDB2] 15 17 XNET [25,JFH2] 16 20 Chaos [MOON] 17 21 User Datagram [42,JBP] 18 22 Multiplexing [13,JBP] 19 23 DCN [DLM1] 20 24 TAC Monitoring [55,RH6] 21-62 25-76 Unassigned [JBP] 63 77 any local network [JBP] 64 100 SATNET and Backroom EXPAK [DM11] 65 101 MIT Subnet Support [NC3] 66-68 102-104 Unassigned [JBP] 69 105 SATNET Monitoring [DM11] 70 106 Unassigned [JBP] 71 107 Internet Packet Core Utility [DM11] 72-75 110-113 Unassigned [JBP] 76 114 Backroom SATNET Monitoring [DM11] 77 115 Unassigned [JBP] 78 116 WIDEBAND Monitoring [DM11] 79 117 WIDEBAND EXPAK [DM11] 80-254 120-376 Unassigned [JBP] 255 377 Reserved [JBP] Postel [Page 6] RFC 790 September 1981 Assigned Numbers Port or Socket Numbers ASSIGNED PORT or SOCKET NUMBERS Ports are used in the TCP [34] and sockets are used in the AHHP [28,17] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers a service contact socket is defined. This list specifies the port or socket used by the server process as its contact socket. In the AHHP an Initial Connection Procedure ICP [39,17] is used between the user process and the server process to make the initial contact and establish the long term connections leaving the contact socket free to handle other callers. In the TCP no ICP is necessary since a port may engage in many simultaneous connections. To the extent possible these same port assignments are used with UDP [42]. The assigned ports/sockets use a small part of the possible port/socket numbers. The assigned ports/sockets have all except the low order eight bits cleared to zero. The low order eight bits are specified here. Socket Assignments: General Assignments: Decimal Octal Description ------- ----- ----------- 0-63 0-77 Network Wide Standard Function 64-131 100-203 Hosts Specific Functions 132-223 204-337 Reserved for Future Use 224-255 340-377 Any Experimental Function Postel [Page 7] RFC 790 September 1981 Assigned Numbers Port or Socket Numbers Specific Assignments: Network Standard Functions Decimal Octal Description References ------- ----- ----------- ---------- 1 1 Old Telnet [40,JBP] 3 3 Old File Transfer [27,11,24,JBP] 5 5 Remote Job Entry [6,17,JBP] 7 7 Echo [35,JBP] 9 11 Discard [32,JBP] 11 13 Who is on or SYSTAT [JBP] 13 15 Date and Time [JBP] 15 17 Who is up or NETSTAT [JBP] 17 21 Short Text Message [JBP] 19 23 Character generator or TTYTST [31,JBP] 21 25 New File Transfer [36,JBP] 23 27 New Telnet [41,JBP] 25 31 SMTP [54,JBP] 27 33 NSW User System w/COMPASS FE [14,RHT] 29 35 MSG-3 ICP [29,RHT] 31 37 MSG-3 Authentication [29,RHT] 33 41 Unassigned [JBP] 35 43 IO Station Spooler [JBP] 37 45 Time Server [22,JBP] 39 47 Unassigned [JBP] 41 51 Graphics [46,17,JBP] 42 52 Name Server [38,JBP] 43 53 WhoIs [JAKE] 45 55 Message Processing Module [37,JBP] 47 57 NI FTP [50,CJB] 49 61 RAND Network Graphics Conference [30,MO2] 51 63 Message Generator Control [52,DFP] 53 65 AUTODIN II FTP [21,EC5] 55 67 ISI Graphics Language [3,RB6] 57 71 MTP [45,JBP] 59 73 New MIT Host Status [SWG] 61-63 75-77 Unassigned [JBP] Postel [Page 8] RFC 790 September 1981 Assigned Numbers Port or Socket Numbers Host Specific Functions Decimal Octal Description References ------- ----- ----------- ---------- 65 101 Unassigned [JBP] 67 103 Datacomputer at CCA [8,JZS] 69 105 Unassigned [JBP] 69 105 Trivial File Transfer [47,KRS] 71 107 NETRJS (EBCDIC) at UCLA-CCN [5,17,RTB] 73 111 NETRJS (ASCII-68) at UCLA-CCN [5,17,RTB] 75 113 NETRJS (ASCII-63) at UCLA-CCN [5,17,RTB] 77 115 any private RJE server [JBP] 79 117 Name or Finger [23,17,KLH] 81 121 Unassigned [JBP] 83 123 MIT ML Device [MOON] 85 125 MIT ML Device [MOON] 87 127 any terminal link [JBP] 89 131 SU/MIT Telnet Gateway [MRC] 91 133 MIT Dover Spooler [EBM] 93 135 BBN RCC Accounting [DT] 95 137 SUPDUP [15,MRC] 97 141 Datacomputer Status [8,JZS] 99 143 CADC - NIFTP via UCL [PLH] 101 145 NPL - NIFTP via UCL [PLH] 103 147 BNPL - NIFTP via UCL [PLH] 105 151 CAMBRIDGE - NIFTP via UCL [PLH] 107 153 HARWELL - NIFTP via UCL [PLH] 109 155 SWURCC - NIFTP via UCL [PLH] 111 157 ESSEX - NIFTP via UCL [PLH] 113 161 RUTHERFORD - NIFTP via UCL [PLH] 115-129 163-201 Unassigned [JBP] 131 203 Datacomputer [8,JZS] Reserved for Future Use Decimal Octal Description References ------- ----- ----------- ---------- 132-223 204-337 Reserved [JBP] Postel [Page 9] RFC 790 September 1981 Assigned Numbers Port or Socket Numbers Experimental Functions Decimal Octal Description References ------- ----- ----------- ---------- 224-239 340-357 Unassigned [JBP] 241 361 NCP Measurement [9,JBP] 243 363 Survey Measurement [2,AV] 245 365 LINK [7,RDB2] 247 367 TIPSRV [RHT] 249-255 371-377 RSEXEC [51,RHT] ASSIGNED LINK NUMBERS The word "link" here refers to a field in the original ARPANET Host/IMP interface leader. The link was originally defined as an 8 bit field. Some time after the ARPANET Host-to-Host (AHHP) protocol was defined and, by now, some time ago the definition of this field was changed to "Message-ID" and the length to 12 bits. The name link now refers to the high order 8 bits of this 12 bit message-id field. The low order 4 bits of the message-id field are to be zero unless specifically specified otherwise for the particular protocol used on that link. The Host/IMP interface is defined in BBN report 1822 [1]. Link Assignments: Decimal Octal Description References ------- ----- ----------- ---------- 0 0 AHHP Control Messages [28,17,JBP] 1 1 Reserved [JBP] 2-71 2-107 AHHP Regular Messages [28,17,JBP] 72-150 110-226 Reserved [JBP] 151 227 CHAOS Protocol [MOON] 152 230 PARC Universal Protocol [4,EAT3] 153 231 TIP Status Reporting [JGH] 154 232 TIP Accounting [JGH] 155 233 Internet Protocol (regular) [33,JBP] 156-158 234-236 Internet Protocol (experimental) [33,JBP] 159-191 237-277 Measurements [9,VGC] 192-195 300-303 Unassigned [JBP] 196-255 304-377 Experimental Protocols [JBP] 224-255 340-377 NVP [12,17,DC] 248-255 370-377 Network Maintenance [JGH] Postel [Page 10] RFC 790 September 1981 Assigned Numbers Documents DOCUMENTS --------- [1] BBN, "Specifications for the Interconnection of a Host and an IMP", Report 1822, Bolt Beranek and Newman, Cambridge, Massachusetts, May 1978. [2] Bhushan, A., "A Report on the Survey Project", RFC 530, NIC 17375, 22 June 1973. [3] Bisbey, R., D. Hollingworth, and B. Britt, "Graphics Language (version 2.1)", ISI/TM-80-18, USC/Information Sciences Institute, July 1980. [4] Boggs, D., J. Shoch, E. Taft, and R. Metcalfe, "PUP: An Internetwork Architecture", XEROX Palo Alto Research Center, CSL-79-10, July 1979; also in IEEE Transactions on Communication, Volume COM-28, Number 4, April 1980. [5] Braden, R., "NETRJS Protocol", RFC 740, NIC 42423, 22 November 1977. Also in [17]. [6] Bressler, B., "Remote Job Entry Protocol", RFC 407, NIC 12112, 16 October 72. Also in [17]. [7] Bressler, R., "Inter-Entity Communication -- An Experiment", RFC 441, NIC 13773, 19 January 1973. [8] CCA, "Datacomputer Version 5/4 User Manual", Computer Corporation of America, August 1979. [9] Cerf, V., "NCP Statistics", RFC 388, NIC 11360, 23 August 1972. [10] Clark, D., "Revision of DSP Specification", Local Network Note 9, Laboratory for Computer Science, MIT, 17 June 1977. [11] Clements, R., "FTPSRV -- Extensions for Tenex Paged Files", RFC 683, NIC 32251, 3 April 1975. Also in [17]. [12] Cohen, D., "Specifications for the Network Voice Protocol (NVP)", NSC Note 68, 29 January 1976. Also as USC/Information Sciences Institute RR-75-39, March 1976, and as RFC 741, NIC 42444, 22 November 1977. Also in [17]. [13] Cohen, D. and J. Postel, "Multiplexing Protocol", IEN 90, USC/Information Sciences Institute, May 1979. Postel [Page 11] RFC 790 September 1981 Assigned Numbers Documents [14] COMPASS, "Semi-Annual Technical Report", CADD-7603-0411, Massachusetts Computer Associates, 4 March 1976. Also as, "National Software Works, Status Report No. 1", RADC-TR-76-276, Volume 1, September 1976. And COMPASS. "Second Semi-Annual Report", CADD-7608-1611, Massachusetts Computer Associates, 16 August 1976. [15] Crispin, M., "SUPDUP Protocol", RFC 734, NIC 41953, 7 October 1977. Also in [17]. [16] Crispin, M. and I. Zabala, "DIALNET Protocols", Stanford University Artificial Intelligence Laboratory, July 1978. [17] Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978. [18] Flood Page, D., "Gateway Monitoring Protocol", IEN 131, February 1980. [19] Flood Page, D., "CMCC Performance Measurement Message Formats", IEN 157, September 1980. [20] Forgie, J., "ST - A Proposed Internet Stream Protocol", IEN 119, M.I.T. Lincoln Laboratory, September 1979. [21] Forsdick, H., and A. McKenzie, "FTP Functional Specification", Bolt Beranek and Newman, Report 4051, August 1979. [22] Harrenstien, K., J. Postel, "Time Server", IEN 142, April 1980. Also in [17]. [23] Harrenstien, K., "Name/Finger", RFC 742, NIC 42758, 30 December 1977. Also in [17]. [24] Harvey, B., "One More Try on the FTP", RFC 691, NIC 32700, 6 June 1975. [25] Haverty, J., "XNET Formats for Internet Protocol Version 4", IEN 158, October 1980. [26] McCarthy, J. and L. Earnest, "DIALNET", Stanford University Artificial Intelligence Laboratory, Undated. [27] McKenzie, A., "File Transfer Protocol", RFC 454, NIC 14333, 16 February 1973. Postel [Page 12] RFC 790 September 1981 Assigned Numbers Documents [28] McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, January 1972. Also in [17]. [29] NSW Protocol Committee, "MSG: The Interprocess Communication Facility for the National Software Works", CADD-7612-2411, Massachusetts Computer Associates, BBN 3237, Bolt Beranek and Newman, Revised 24 December 1976. [30] O'Brien, M., "A Network Graphical Conferencing System", RAND Corporation, N-1250-ARPA, August 1979. [31] Postel, J., "Character Generator Process", RFC 429, NIC 13281, 12 December 1972. [32] Postel, J., "Discard Process", RFC 348, NIC 10427, 30 May 1972. [33] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981. [34] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, USC/Information Sciences Institute, September 1981. [35] Postel, J., "Echo Process", RFC 347, NIC 10426, 30 May 1972. [36] Postel, J., "File Transfer Protocol", RFC 765, IEN 149, June 1980. [37] Postel, J., "Internet Message Protocol", RFC 759, IEN 113, USC/Information Sciences Institute, August 1980. [38] Postel, J., "Name Server", IEN 116, USC/Information Sciences Institute, August 1979. [39] Postel, J., "Official Initial Connection Protocol", NIC 7101, 11 June 1971. Also in [17]. [40] Postel, J., "Telnet Protocol", RFC 318, NIC 9348, 3 April 1972. [41] Postel, J., "Telnet Protocol Specification", RFC 764, IEN 148, June 1980. [42] Postel, J., "User Datagram Protocol", RFC 768 USC/Information Sciences Institute, August 1980. Postel [Page 13] RFC 790 September 1981 Assigned Numbers Documents [43] Reed, D., "Protocols for the LCS Network", Local Network Note 3, Laboratory for Computer Science, MIT, 29 November 1976. [44] Skelton, A., S. Holmgren, and D. Wood, "The MITRE Cablenet Project", IEN 96, April 1979. [45] Sluizer, S., and J. Postel, "Mail Transfer Protocol", RFC 780, USC/Information Sciences Institute, May 1981. [46] Sproull, R., and E. Thomas. "A Networks Graphics Protocol", NIC 24308, 16 August 1974. Also in [17]. [47] Sollins, K., "The TFTP Protocol (revision 2)", RFC 783, MIT/LCS, June 1981. [48] Strazisar, V., "Gateway Routing: An Implementation Specification", IEN 30, Bolt Berenak and Newman, April 1979. [49] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Berenak and Newman, August 1979. [50] The High Level Protocol Group, "A Network Independent File Transfer Protocol", INWG Protocol Note 86, December 1977. [51] Thomas, R., "A Resource Sharing Executive for the ARPANET", AFIPS Conference Proceedings, 42:155-163, NCC, 1973. [52] Flood Page, D., "A Simple Message Generator", IEN 172, Bolt Berenak and Newman, March 1981. [53] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", RFC 792, USC/Information Sciences Institute, September 1981. [54] Postel, J., "Simple Mail Transfer Protocol", RFC 788, USC/Information Sciences Institute, September 1981. [55] Littauer, B., "A Host Monitoring Protocol"", IEN 197, Bolt Berenak and Newman, September 1981. Postel [Page 14] RFC 790 September 1981 Assigned Numbers People PEOPLE ------ [DCA2] Don Allen BBN Allen@BBND [CJB] Chris Bennett UCL UKSAT@ISIE [RB6] Richard Bisbey ISI Bisbey@ISIB [RTB] Bob Braden UCLA Braden@ISIA [RDB2] Robert Bressler BBN Bressler@BBNE [EC5] Ed Cain DCEC cain@EDN-Unix [VGC] Vint Cerf ARPA Cerf@ISIA [NC3] J. Noel Chiappa MIT JNC@MIT-XX [SGC] Steve Chipman BBN Chipman@BBNA [DDC2] David Clark MIT Clark@MIT-Multics [DC] Danny Cohen ISI Cohen@ISIB [MRC] Mark Crispin Stanford Admin.MRC@SU-SCORE [BD2] Brian Davies RSRE T45@ISIE [JAKE] Jake Feinler SRI Feinler@SRI-KL [DFP] David Flood Page BBN DFloodPage@BBNE [JWF] Jim Forgie LL Forgie@BBNC [SWG] Stu Galley MIT SWG@MIT-DMS [GEOF] Geoff Goodfellow SRI Geoff@DARCOM-KA [KLH] Ken Harrenstien MIT KLH@MIT-AI [JFH2] Jack Haverty BBN JHaverty@BBN-Unix [JGH] Jim Herman BBN Herman@BBNE [PLH] Peter Higginson UCL UKSAT@ISIE [RH6] Robert Hinden BBN Hinden@BBNE [CH2] Charles Hornig Honeywell Hornig@MIT-Multics [EAK] Earl Killian LLL EAK@MIT-MC [PK] Peter Kirstein UCL Kirstein@ISIA [DRL] David Lyons DEC Lyons@DEC-2136 [HM] Hank Magnuski --- --- [JEM] Jim Mathis SRI Mathis@SRI-KL [DM11] Dale McNeill BBN DMcNeill@BBNE [DLM1] David Mills COMSAT Mills@ISIE [MOON] David Moon MIT Moon@MIT-MC [EBM] Eliot Moss MIT EBM@MIT-XX [MO2] Michael O'Brien RAND OBrien@RAND-Unix [KTP] Ken Pogran BBN Pogran@BBND [JBP] Jon Postel ISI Postel@ISIF [JZS] Joanne Sattely CCA JZS@CCA [APS] Anita Skelton MITRE skelton@MITRE [KRS] Karen Sollins MIT Sollins@MIT-XX [VMS] Virginia Strazisar BBN Strazisar@BBNA [EAT3] Ed Taft XEROX Taft.PA@PARC [DT] Dan Tappan BBN Tappan@BBNG [RHT] Robert Thomas BBN Thomas@BBNA [AV] Al Vezza MIT AV@MIT-XX [CJW2] Cliff Weinstein LL cjw@LL-11 Postel [Page 15]

1 0

Re: [44net] OFDM Modem
by Steve L 02 Sep '17

02 Sep '17

Brian, You read my mind. You all have to excuse John, K7VE. He represents North West Digital and has a bias. They have been trying to develop a 70 cm data radio for a while. Same goes if you are on other lists and he brings up the DVSI/AMBE patents, as NWDigital sells a hardware AMBE device. The Oct 2013 ARRL proposal to modernize the rules for data transmissions appears stalled. So yes, if there is an image use, its classified as an image transmission, Not Data. The first person to use this angle was the late John Stevensen, KD6OZH. It has since been used by David Bern, W2LNX (2012 DCC), myself and others to experiment with the Doodle Labs and Xagyl 70cm 802.11 devices. Maybe we need to petition the FCC ourselves? I can't say I always fell the ARRL represents what we are doing very well. And their proposal did squat for VHF/UHF in my opinion. Steve, KB9MWR > On Fri, Sep 1, 2017 at 10:46 AM, Brian Kantor <Brian(a)ucsd.edu> wrote: > Why do all new-technology discussions about the ham bands degenerate > into arguments about USA rules? No wonder most innovation takes > place in other countries. > - Brian > > On Fri, Sep 1, 2017 at 9:26 AM, K7VE - John <k7ve(a)k7ve.org> wrote: >> Just remember, in the US, that 70cm data must fit in 100 kHz and be 56 >> kbauds (Same on the 219 Mhz band), but this is interesting work. 97.305(c) >> and 97.307(f)6 >>

4 4

Re: [44net] OFDM Modem
by Rob Janssen 02 Sep '17

02 Sep '17

> Just remember, in the US, that 70cm data must fit in 100 kHz and be 56 > kbauds (Same on the 219 Mhz band), but this is interesting work. 97.305(c) > and 97.307(f)6 We don't have such blanket restrictions here. Operating under the amateur radio regulations for individuals, you can do whatever you like within the limits of the band and conforming to established bandplans and social behaviour. With a special permit for unattended or automatic operation (required e.g. for a repeater) you get a frequency and bandwidth assigned, no technical details like a baudrate. Rob

2 1

OFDM Modem
by Ron Economos 02 Sep '17

02 Sep '17

Hopefully this isn't too far off topic. I've just completed testing of an OFDM modem using IP over DVB-T2. It uses an SDR transmitter and a commercial DVB-T2 receiver to implement the RFC 4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS). ULE is supported in the Linux kernel for DVB receivers. https://tools.ietf.org/html/rfc4326 It's a full-duplex modem capable of up to 50 Mbps (in both directions) in an 8 MHz bandwidth. The current test bed consists of an Ettus B200 SDR transmitter, PCTV 292e DVB-T2 USB receiver, Kuhne down converters for 13cm and 9cm, Microlab BK-26N diplexer and RFSpace TSA600 Vivaldi antenna. http://www.w6rz.net/IMG_0119.jpg http://www.w6rz.net/traceroute.png The transmitter is based on the DVB-T2 transmitter in GNU Radio and uses this OOT module for the ULE protocol. https://github.com/drmpeg/gr-ule To reduce the latency, I've merged the DVB-T2 blocks to avoid having so many buffers between blocks. https://github.com/drmpeg/gr-dvbt2ll Current test frequencies are 2305 and 3429 MHz with an 8 MHz bandwidth. The bit-rate is 28.6 Mbps (symmetrical). It's intended to replace commercial WiFi equipment for amateur WAN interlinks. Advantages: 1) Full-duplex. Adding power amplifiers, preamps, diplexers/duplexers is easy. 2) Frequency agile. Can work on any band above 420 MHz. 70cm through 5cm direct TX from the SDR and millimeter frequencies with an up-converter. 3) Bandwidth agile. 5, 6 ,7 and 8 MHz bandwidths. 4) May be legal on 70cm. Although I haven't implemented it yet, a small portion of the bandwidth can be used to send a low-rate video stream (for example, a still picture of your call sign for ID). This would classify the emission as digital ATV, not data. Disadvantages: 1) Latency is a bit high. It's currently 100 ms (200 ms round trip). This is a function of buffering in GNU Radio and the USB 3.0 connection to the SDR. An FPGA implementation of DVB-T2 and a different SDR architecture could solve this. 2) Cost. It's difficult to compete with commercial WiFi equipment. However, lower cost components can be used instead of the "Cadillac" test bed I constructed. For example, a ADALM-PLUTO at $99 could be used instead of the Ettus B200 for transmit. Two antennas instead of a diplexer and lower cost down-converters than the Kuhne units. 3) Requires a Linux computer to run it. An Odroid XU4 may be adequate, but I haven't tested it. 73, Ron W6RZ

7 7

Re: [44net] OFDM Modem
by Steve L 02 Sep '17

02 Sep '17

John, I was hesitant at first. Mostly because I think you are an okay guy. While my message might seem poor in taste, I stand by it. I feel if you are going to play the arm chair lawyer part, then you should be more transparent with your role with NW Digital. I don't see you pointing out other rules issues, just things in those two areas, which ironically are directly related to NWdigital. I do applaud your recent AMBE effort, offering a discount on the xlxd list to aide development efforts, rather than the usual approach. Moving forward I'd like to see less poo-pooing, and more doing not just on this list, but though out the hobby. Folks are expected to know the rules are part of their entrance test into the hobby. I am not an official observer, nor a lawyer, and suspect the same is with you. We have no obligation to remind others that obligation is on each operators shoulders alone. If you want to do things that help NWdigital, I don't have a problem with you becoming the person to spear-head a more aggressive data rules overhaul proposal to the FCC. This is because its not just beneficial to NWDigital, but to amateur radio as a whole. I can't speak for others on this however, as I am sure operators of other modes may feel differently. I do encourage you to survey the odds and consider working in this positive manner to have these modernized, over the "old-man get off my lawn approach" that I have seen. Now on to a new subject that is more productive please. 73 Steve, KB9MWR

1 0

ampr.org and 44.in-addr.arpa nameservice
by Brian Kantor 29 Aug '17

29 Aug '17

It's come to my attention that some of our worldwide slave nameservers are not updating when changes are made to the DNS on our master nameserver, 'ampr.org' (44.0.0.1). It will take me a while to contact the operators of those nameservers to ensure that their configurations are correct for them to get the latest changes as they occur. In the meantime, there may be differences in the answers you get regarding new entries in the DNS depending on which nameserver your query is actually made to. The way to tell if a particular nameserver is current is to examine the serial number in the ampr.org SOA record as retrieved from it and compare that with the SOA from ampr.org (44.0.0.1). I use the 'dig' tool for this purpose; there are other tools as well. - Brian

5 6

Still re 44.177.10.254
by Libor Berka 28 Aug '17

28 Aug '17

Hi all thanks for testing ping 44.177.10.254. I apologize re 44.177.10.254 node callsign. It's OK0NMG. For Brian: ok0nmg.ampr.org (or maybe gw.ok0nmg.ampr.org) was registered for 44.177.10.254 in ampr.org DNS some monthes ago, maybe years. But disappeared. It was registered by OK2OP (Czech coordinator) who unfortunately passed away and there is no Czech callsign coordinator up to now. I asked Chris who is listed in amprnet coordinators for Czech rep. but he says he is not able to provide DNS registering. For Peter ZL2BAU: Peter 44.177.10.10 is not changed and I do not know why it is impossible to ping it from your system. It can be pinged from N1URO, VE2PKT, VK6HGR and others. Re 44.177.10.254 - it is node OK0NMG:CZGATE. I am sysop of it as well. It is of different net then 44.177.10.10. For Tom SP2L: Thanks for test/reply. 73 Dalibor

2 1

Connecting via VPN
by Radu Draghici 28 Aug '17

28 Aug '17

Hello, I've just provisioned with a 44.182.24.0/24 subnet.I have a DD-WRT box on TP-Link TL-WDR3600 and a Ubiquiti NanoStation Loco M2.I want to interconnect with somebody via VPN for the moment. I am located in Romania and i have a static public IP from ISP. Can you please provide me a little help? Thank you in advance! Sent from my Samsung Galaxy smartphone.

1 0

44.177.10.254 hostname problem
by Libor Berka 28 Aug '17

28 Aug '17

Gentlemen my network 44.177.10.254/32 nor showing hostname (ok20nmg.ampr.org) nor accepting pings. How to correct it? 73 Dalibor

4 3

Hank Magnuski KA6M email address?
by Brian Kantor 22 Aug '17

22 Aug '17

Does anyone have a valid current email address for Hank Magnuski, KA6M (one of packet radio's pioneers)? The only address I have for him is decades old and doesn't work anymore. Thank you. - Brian

2 2

What does it look like being on a mountain top engulfed by fire?
by Brian Kantor 17 Aug '17

17 Aug '17

Background: HPWREN is the High Performance Wireless Research and Education Network, implemented using commercial wireless equipment and housed on several mountaintops around southern California USA. A recent news item from them has some impressive images that you folks may find interesting. You'll need a high-performance web browser/viewer and network connection to get the most from it. - Brian ----- Forwarded message Subject: What does it look like being on a mountain top engulfed by fire? A new HPWREN update: What does it look like being on a mountain top engulfed by fire? is available at http://hpwren.ucsd.edu/news/20170815/ The article, contributed by Paul Bourke, shows an immersive time-lapse animation of a four-camera 360 degree view in high resolution of the Whittier Fire near Santa Barbara in July 2017, projected onto the inside of a sphere, within which a viewer can pan, tilt and zoom. Older HPWREN news updates can be found at http://hpwren.ucsd.edu/news/ ----- End forwarded message -----

1 0

Re: [44net] Belgium AMPRNet coordination
by Brian Kantor 14 Aug '17

14 Aug '17

Ok, I've updated his email address in the portal to that address from the on4sax(a)on4sax.be address that it used to be, which has apparently been taken over by a domain parking service which does not deliver mail. We'll see if this address gets through. Thank you, Jan. - Brian On Mon, Aug 14, 2017 at 08:20:11AM +0200, Jan Poppeliers wrote: > robbie.delise(a)gmail.com > > 73, Jan > ON7UX > > > -----Oorspronkelijk bericht----- > Van: 44Net [mailto:44net-bounces+jan.poppeliers=online.be@hamradio.ucsd.edu] > Namens Brian Kantor > Verzonden: maandag 14 augustus 2017 7:25 > Aan: 44net(a)hamradio.ucsd.edu > Onderwerp: [44net] Belgium AMPRNet coordination > > Unless someone can supply me with a working email address for the Belgium > AMPRNet coordinator, Robbie De Lise ON4SAX, there won't be any more > allocations in the existing Belgium subnet because there is nobody to handle > them. I need a mailbox that is actually read and responded to, not just one > that doesn't bounce mail sent to it. Or if it's the case that he's turned > coordination over to someone else, I wish someone would let me know. > - Brian > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Belgium AMPRNet coordination
by Brian Kantor 14 Aug '17

14 Aug '17

Unless someone can supply me with a working email address for the Belgium AMPRNet coordinator, Robbie De Lise ON4SAX, there won't be any more allocations in the existing Belgium subnet because there is nobody to handle them. I need a mailbox that is actually read and responded to, not just one that doesn't bounce mail sent to it. Or if it's the case that he's turned coordination over to someone else, I wish someone would let me know. - Brian

2 1

DNS entry add and clean up
by Normand L 14 Aug '17

14 Aug '17

Hi folks. After many-many years of absence . I back in the amprnet world. I did allready put back mtlgw.ampr.org running on a raspberry pi. I got a few very interesting projects on going. I will need to do somes modifications in the DNS entry. In the past I was using a mail robot to do it , but no idea on how , I will definitly need a refresh on how 's done today. Your help will be precious. 73 Normand Ve2vax / VA2nq

2 1

Portscanning
by Rob Janssen 03 Aug '17

03 Aug '17

I notice extensive portscanning/vulnerability searching from IP address 44.26.108.60 It has reverse katagiri.desu.ne.jp which also matches with its forward. (kind of strange, as it is no ampr.org name and .jp has 44.129.0.0/16) Does anyone have an idea what is going on here? Rob

3 2

Re: [44net] I gave a talk tonight.
by Steve L 29 Jul '17

29 Jul '17

Brian I wish everyone took your stance on the rules that you talk about at roughly 41:46. That is pretty much how I do things myself. I agree 100 % on the arm chair lawyer thing not being productive and all it does is discourage experimentation and potential new folks. > https://www.youtube.com/watch?v=8EdDtLRgH7k&feature=youtu.be&t=1108 Its a good video overview of a well setup network. I plan to show it at a club meeting. Steve, KB9MWR

1 0

I gave a talk tonight.
by Tom Cardinal 28 Jul '17

28 Jul '17

I gave a talk tonight at one of our local clubs to see if any other local amateurs are interested in AMPRnet. I tried to stay out of the weeds to just give a general overview and did not present any slides. I did use slides as note cards on my iPad to keep from straying that I have now placed on my AMPR web server (n2xu.ampr.org) for the folks in attendance that might be more interested. There were about 20 or so folks in attendance and I think there are 3 or 4 that are interested. I will be doing another talk at the club where I was once President here in Fort Walton Beach and then for the folks that are more interested I will present another more in the weeds presentation at some point in the future. I'm big on trying to get 44net here on RF (slow 1200 or broadband at 5.8 GHz) down here and need others that are local in order to do so. I might be leveraging expertise here as I try to grow interest... so please bear with me and any new folks I bring aboard. With all that said, is there anyone out there performing intermediate routing... what I mean is anyone running a tunneled gateway and performing routing for other subnets over RF. I may request a second but separate allocation to experiment in that realm... I'd like to learn how to do that. I think it's a natural expansion for times when network connectivity goes out for an area where we can act as an RF gateway between the RF and the tunneled AMPRNet. My eventual goal is I'd like to bring the HAMWAN to the Florida panhandle... I think these are all baby steps to get there. Input, advice ideas and criticism are all welcome. -- Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce

7 8

Re: [44net] I gave a talk tonight.
by Steve L 28 Jul '17

28 Jul '17

The main problem if you ask me is this the over the air baudrate/bandwidth rules. These prevent anything at truly usable speeds on non-microwave bands. Has anyone heard anything on that plan to do away with the baud rate part that was proposed to the FCC in 2013? (Would have been nice to see 200 KHz wide on 70cm) Steve, KB9MWR -----Original Message----- > >I presume you mean routing other subnets over amateur radio frequencies. > >We used to do that. But there are two main problems with it here in the US. > >1) Encryption. More than half of websites are now encrypted and the percentage is growing every >day. E-mail encryption is also on the rise. And encryption is not allowed over US amateur >frequencies. So amateur frequencies are fast becoming impractical/irrelevant for real-world, >mainstream network traffic. > >2) 3rd party-initiated traffic. Routing inbound e-mail, even if unencrypted, over an amateur >frequency is a violation of Part 97, according to the FCC enforcement bureau. At least it was when >I asked them about this a few years ago. That's because anyone anywhere could initiate a >transmission on an amateur frequency without a license simply by sending you an email. So we >allowed only outbound email from hams to traverse the amateur frequencies. Inbound email >stopped at the gateway. It wasn't very practical, but at least a message could go out. > >We later got internet connections at all of our hub sites. So we turned each of them into their own >gateways. Users can access the site over amateur frequencies to download their mail since the >ham initiates that connection. But we still have to filter out encrypted email. And we're using Part >15 frequencies between hub sites. I suppose we could still use 44.x addresses. But since a 44.x >subnet can only exist behind one gateway in AMPRnet routing, we didn't see much point in that >either. > >Not trying to be a bummer. But the FCC regulations really squash creativity and innovation. > >Michael >N6MEF

1 0

Re: [44net] eth0 VM incoming IPIP, RIP [no chksum], like dhcp mangle issue ???
by Rob Janssen 27 Jul '17

27 Jul '17

> 1. There is no socket option called that in FreeBSD. Amprgw is not Linux. I am aware of that. Sometimes those socket options have the same name, sometimes not. When looking this up I got the impression that it was added to Linux copying from BSD, but it appears to be not the case. In the Apple variant of BSD the same option exists but it is named differently. > 2. We're not using the kernel socket mechanism to construct the UDP packets Ok... well, it is possible to calculate the checksum of course but it is a bit tricky as it is not only a checksum of the actual packet but also of a "pseudo header" that is temporarily added in front of it... But again, it should not be required. The 0000 checksum indicates "no checksum" and it is valid. I think Maiko has a different issue, maybe the problem with multicast sockets? (try -r option to force raw mode) Rob

1 0

Re: [44net] eth0 VM incoming IPIP, RIP [no chksum], like dhcp mangle issue ???
by Rob Janssen 26 Jul '17

26 Jul '17

Maiko, I think you are chasing a red herring. It is true that the RIP broadcasts have no checksum, but that is unlikely to be the cause of any problem you may have. Checksums are optional in UDP, these packets don't have them (I can confirm that in a trace on my gateway), but that is not a reason not to process them. It could be argued that it would be better to send the packets with checksum, which could be accomplished using the |SO_NO_CHECK socket option. Rob |

2 1

eth0 VM incoming IPIP, RIP [no chksum], like dhcp mangle issue ???
by Maiko Langelaar 26 Jul '17

26 Jul '17

Good day, This is bizarre, I confirm IPIP is definitely coming to my linux (running as a VM) : Here is a tcpdump of the eth0 (direct internet side) : 22:27:35.447588 IP (tos 0x0, ttl 50, id 59965, offset 0, flags [none], proto IPIP (4), length 552) amprgw.ucsd.edu > XXXXXX.members.linode.com: IP (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto UDP (17), length 532) gw.ampr.org.router > rip2-routers.mcast.net.router: [no cksum] RIPv2, Response, length: 504, routes: 25 or less Simple Text Authentication data: XXXXXXXXX AFI IPv4, gw.ampr.org/32, tag 0x0004, metric: 1, next-hop: amprgw.ucsd.edu AFI IPv4, .... I'm using iptables PREROUTING to route protocol 4 (IPIP) to my JNOS over tun0, most of of the traffic is working very nicely, not worried about that. However, if you look closely, this RIP broadcast is showing [NO CKSUM] ! I read somewhere there is a similar issue with DHCP packets (to VM of all things), the end result is that these particular packets are then dropped and never make it to the tun0 link, so JNOS will never see these. I have run tcpdump on the tun0 interface, and sure enough not seeing these at all. I've tried variations of the following command to 'fill in the checksum' but no luck : iptables -t mangle <missing other arguments> -j CHECKSUM --checksum fill This is only affecting my RIP broadcasts encapsulated in IP (so far), my usual 44 ntwk traffic over the tun0 link and JNOS is working fine, checksums all correct, etc. Help :) Maiko / VE4KLM

1 0

ve4klm.ampr.org issues
by Maiko Langelaar 25 Jul '17

25 Jul '17

Thought maybe this is the place to let people know (as a courtesy I suppose). I recently lost my static IP address (my bridge radio died after 12+ years or so), looking at other solutions. So in the meantime my existing IP address as noted in the encap.txt and rip broadcasts will simply not respond to anything. No worries about it being used by other entities, it's an IP on 'our system' that no one else will ever use for a long time down the road. I don't want to delete my entry in the portal, so I will try to get some form of Dynamic DNS hostname in place as soon as possible, since I am now using a DSL service as a temporary internet connection. It might be a while, just saying. Thanks for your understanding. Maiko / VE4KLM

1 1

Lost my subnet...
by jerome schatten 19 Jul '17

19 Jul '17

Yesterday I lost all the folks I had links with… Today after much head scratching I decided to look at my gateway on the ampr portal. The gateway addy is 174.6.225.73 and the subnet I had WAS 44.135.172.0/29 My 44 addy is 44.135.172.128 So at the portal it says: 'network not found' I don’t find this block of four addresses in the available networks list to add it back in. Help please. Confused in Vancouver jerome - ve7ass

3 5

MikroTik Routers
by Marc Williams 19 Jul '17

19 Jul '17

Good afternoon all, Unfortunately I made little progress with my home setup due to the joys of work and real life demands.Anyway sob story aside I have a little spare time again so I am looking to get a MikroTik router ordered.So my question is do I need to adhere to a minimum spec? The memory and processor specs seem to very greatly. Thanks in advance. Marc (2W0PNT)

4 7

Lost my subnet... Still More
by jerome schatten 19 Jul '17

19 Jul '17

And also, none of the folks I’m linked to can connect to me if they are using the rip broadcasts or the list. I’m probably not the only one that has this problem. I seem to remember a cleansing of the gateways that are inactive, maybe you can fix this so that those whose CPE no longer allows rip to function (the ‘bitten’) can still make use of the system. j. ve7ass ----------------- And of course I’m no longer in the gateways list… If this is because I don’t reply to pings, unfortunately I can no longer receive gateway broadcasts so that would be expected, no? jerome _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

2 1

Lost my subnet... More
by jerome schatten 19 Jul '17

19 Jul '17

And of course I’m no longer in the gateways list… If this is because I don’t reply to pings, unfortunately I can no longer receive gateway broadcasts so that would be expected, no? jerome

2 1

Re: [44net] MikroTik Routers
by Rob Janssen 18 Jul '17

18 Jul '17

> In my case, where we run a BGP session with Internet and publish our assigned segment, we use a CCR1036 having in memory the full BGP routing table, but even so, this is not a compulsory requirement for you. Indeed for doing BGP on internet you need such a router. To do BGP on AMPRnet (i.e. internal routes only) the RB750Gr3 is good enough. > In example, you can configure a less expensive router with only a default gateway to your ISP and/or to the ISP that runs the BGP session for you (if that would be the case). This is what we do at our gateway as well. The ISP advertises our network and routes the traffic to our system. > If you want to launch a traceroute from public Internet, just to demonstrate above setup, you can use 44.133.233.8 It does not answer to us. First hop is 88.26.246.131 via IPIP tunnel. > Being said that, and nonetheless, I don’t think a Mikrotik RB750 is a good idea as it quite skimpy to have many things running at the same time. > A Mikrotik RB2011 (no Wi-Fi) and above will be, for sue, very good platforms to play with. Remember the suggestion was not the RB750 but the RB750Gr3. This is an entirely different thing. It is more powerful than the RB2011. (but has less ports of course) Rob

1 0

Re: [44net] MikroTik Routers
by Rob Janssen 14 Jul '17

14 Jul '17

> Thanks Rob, so I can ignore all the wiki instructions then and follow the script and read me? Yes > I assume I don't want to use a dmz but put my vdsl router into dumb bridged modem mode? Well that is usually better (when you don't want to be bitten by DMZ bugs), however that complicates things a little bit. Maybe it is better to make that your second experiment :-) When you want to put the VDSL router in bridged mode, you probably also want the MikroTik to double-up as a NAT router for your normal internet use. In itself that is not a problem, it can do that. But it requires a little more study of the matter, especially when you want to be able to talk from AMPRnet to internet (no NAT) and at the same time want to talk from your RFC1918 LAN to internet using NAT. This involves using "policy routing", i.e. two route tables, one for each usage, and "IP Route Rule" settings to select the proper routing table based on source address. Like this: /ip route rule add src-address=44.x.x.x/28 table=ampr then put all AMPRnet routes in the table "ampr". the normal table "main" has the "internet" routes. Traffic from your normal LAN (e.g. 192.168.88.x) to normal internet addresses is routed via the "main" table where there is a default route to your ISP, traffic from your AMPRnet network 44.x.x.x/28 is routed to the "ampr" table where there are the 600 or so tunnel routes and a default route pointing to amprgw. You may also want to separate the LAN side in two different networks, either by reserving physical ports for each network or by using a tagged VLAN for one of the networks. Can be done as well. Almost anything can be done using these routers. However, trying to do it all at once and finding out everything with your network lying in shambles because you re-configured your VDSL router to bridge mode at the same time is not the easiest way forward :-) So, first experiment a bit with the modem in DMZ mode and the MikroTik behind it, find out how things operate, lock yourself out and find out how to recover, etc. Then you can more easily move on to a more complex configuration by adding the above mentioned things. Rob

1 0

Re: [44net] MikroTik Routers
by Rob Janssen 14 Jul '17

14 Jul '17

> Excellent thank you I now have one on order. > Does anyone know if the setup on the wiki is still current or given recent changes is there a new one? Well, the text about MikroTik router setup on the wiki is not something you would want to do, as it only installs a single tunnel to UCSD, but at the bottom it refers to the YO2LOJ site and the script you can find there (get the latest version) and the directions for installing it are the way to go to get it on the IPIP mesh. Of course you can use it in a lot of other ways (also at the same time), depending on the local radio network available. We use these routers (from their availability mostly RB750Gr3, before that some RB2011 and RB750 versions) as routers in our radio network as well, each running a couple of links to neighbors and using BGP as an autorouting protocol. In some areas it is also possible to setup a VPN to some nearby gateway that is on the mesh and/or is directly routed on Internet. Rob

2 1

Re: [44net] MikroTik Routers
by Rob Janssen 14 Jul '17

14 Jul '17

> I think the RB750GR3 is the best bang for your buck if you don't need > POE or SFP.https://routerboard.com/RB750Gr3 It sure is! Make sure you get the r3 version, not the earlier ones. It is much more powerful than the RB750 (no G) and RB2011. (of course it has only 5 ports and no WiFi) Rob

2 1

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 13 Jul '17

13 Jul '17

> Try turning off RPF (return path filtering at the kernel level) if it goes out on one interface and comes in the other, then RPF is almost always at fault as it will by default drop the connection I expect it is something invisible and nasty like that, but rp_filter is not active on that system. (I never enable this because it is so difficult to monitor what it does... on gw-44-137 I use packet marking using the "rpfilter" matcher in mangle and drop of the marked packets with logging in the filter) Rob

1 0

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 13 Jul '17

13 Jul '17

> The strange thing is that ping works ok when TCP doesn't connect. > My first suspicion would be a stateful firewall, but I'm sure you > checked that. Could it be a TTL problem? I'm just guessing here. The TTL of the inside IP packet is 63. I first traced on the external interface and saw the encapsulated packet, then I traced on the tunl0 interface and saw the decapsulated packet (same without the outer IP header), and it all looks OK. I see the SYN going out,the SYN ACK coming in, but nothing more (ACK should go out). The firewall is stateful but I added an explicit accept for -s 44.0.0.1 at the top of all the rules to make sure it is not that. Also, I reset the firewall and watched the counters, did not see any packets being dropped. And indeed, ping works OK. It is strange. Maybe something is wrong due to the gateway external address change, although I would not know what could produce the above scenario. The system is up for about a year, maybe I should try rebooting it. (usually this brings nothing when I try it... it isn't Windows :-) Of course sometime it will become clear how this can be explained. Rob

2 1

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 13 Jul '17

13 Jul '17

> I'm curious as to how long you waited when trying port 25. There > is a five-second delay after the connection is established before > it issues the 220 greeting I noticed that. But on 44.137.40.2 the TCP connection does not even establish. I tried from home (44.137.41.97) and from the gw-44-137 (44.137.0.1) and both were able to connect: telnet 44.0.0.1 25 Trying 44.0.0.1... Connected to 44.0.0.1. Escape character is '^]'. 220 gw.ampr.org ESMTP Sendmail 8.15.2/8.15.2; Thu, 13 Jul 2017 09:20:58 -0700 (PDT) quit 221 2.0.0 gw.ampr.org closing connection Connection closed by foreign host. However, on 44.137.40.2: telnet 44.0.0.1 25 Trying 44.0.0.1... (and nothing more. probably an error when I wait a minute or so) When running tshark on tunl0 I see the SYN+ACK packets from 44.0.0.1 to 44.137.40.2 and when I do an insert of a rule matching source address 44.0.0.1 before all other firewall rules I see it matching, but still no ACK is going back. I have no idea what is going on there. Ping works OK. Rob

3 2

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 13 Jul '17

13 Jul '17

> Remember that the system routing table and the encap routing table are > separate on amprgw. The system routing table is in the kernel; the > encap table is in user space. Packets arriving at amprgw which are for > hosts listed in the encap hosts table are diverted to the encap router; > all other packets are left to the kernel to route. Ok that should work fine. > On the other hand, packets leaving (originating at) amprgw are first > looked up in the system routing table and if a route is found (as it > would be for your bgp-advertised subnet), they are sent out the system > Ethernet interface and not diverted into the encap router. Packets with a > destination not in the system routing table are tested to see if they're > in the encap list, and if they are, they're sent to the encap router > to be forwarded. The rest are dropped. The encap list currently has > 19000 host entries in it. Why do you have entries for the BGP-advertised subnets? Would those not be adequately handled by the default route? Or is this only to handle IPIP tunnels with a BGP-advertised net-44 tunnel endpoint address? Maybe route entries for only those addresses would be an option. (after all, they are known as they are listed in encap.txt) The algorithm could then be to lookup 44-net addresses in the IPIP table when there is no specific route for them in the routing table. When no match is found, they could still be sent out as BGP-routed when desired, this could be achieved with a "special" entry in the lookup array for BGP-routed addresses that are not mentioned in the encap list. > I have experimented with forcing 44.137.40.2 into the encap router with > an explicit route to the loopback interface. This seems to work; the > pings go out a tunnel to 89.18.172.156. I've left this route in place > for now so you can repeat your tests and see if you do indeed get replies > over the tunnel the way you expect. Please let me know. Interesting: I can now ping 44.0.0.1 from that system, but a "telnet 44.0.0.1 25" still yields nothing. I have not yet been able to find why that is, I see the SYN ACK coming back on the tunnel and I have allowed all traffic from 44.0.0.1 in the firewall but it simply fails to establish. No ACK is going back to you. I can connect to other IPIP endpoints just fine. Strange. It is not really required to fix it, I can easily route the mail via a different path, but I was interested in finding why this goes wrong and how it may affect others / other applications. > It could be argued that I should scrap FreeBSD on amprgw and start over > with a Linux host. I don't know enough about the intricacies of Linux > IP handling to be at all confident of being able to do that. I can understand that! It is certainly possible to get it running, and it would be a lot easier to get IPIP running, but it is always a big step to do such things. Rob

3 3

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 13 Jul '17

13 Jul '17

> Yes, BGP overrides encap on amprgw. Is there a rationale behind that or is it just because of some implementation detail? In our gateway, all routes are in the same table but at different distance (metric). Direct/BGP routes have higher precedence than IPIP routes, when for the same subnet. But, a more specific route (smaller subnet) always has precedence over a less specific one. Rob

2 1

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 12 Jul '17

12 Jul '17

> Rob, it looks like the problem might be nearer to you... > Interestingly, when I traceroute to 44.137.40.2 with 169.228.34.84 as > the source address, I get: > ... That is normal, it will be routed over internet to our BGP subnet 44.137.0.0/16 which is via that gw-44-137 which then forwards it to 44.137.40.2 over IPIP. However, 44.137.40.2 does not reply to pings from internet. > When I repeat that traceroute with 44.0.0.1 as the source address, > it gets nearly as far, but not quite: > ... That is strange. Don't you have a route to 44.137.40.2 in your encap table? I would expect you to send it into an IPIP tunnel direct to that system. Or is there some magic in amprgw that makes it ignore IPIP tunnels within BGP routed subnets? That would cause this to fail... > I can ping 213.222.29.194 from 169.228.34.84, but not from > 44.0.0.1. But you can ping 44.137.0.1 (the amprnet address of that same system) from 44.0.0.1 ? > It looks, at first glance, like there's a 44 path problem in > 213.222.29.194. When you route back to 44.137.40.2 via 213.222.29.194 it is explained, because that system has a stateful firewall that does not expect replies to traffic that has not gone out via that same system. Rob

2 1

Re: [44net] gw.ampr.org from tunnel system
by Rob Janssen 12 Jul '17

12 Jul '17

> I thought those problems were fixed as well, or I would not have changed > the submission address. I am not aware of any changes that would have > affected the connectivity of 44.0.0.1. It should be working. > More details might be helpful, such as the actual IP addresses involved, > or perhaps traceroutes showing where the routing stops working. Yes, I think it worked but likely that was on the previous gateway. The system is 44.137.40.2 (89.18.172.156) The route is: 44.0.0.1 via 169.228.34.84 dev tunl0 proto ampr-ripd onlink A traceroute immediately fails. (only stars) tshark dump of a "ping" (looks OK): Internet Protocol Version 4, Src: 89.18.172.156 (89.18.172.156), Dst: 169.228.34.84 (169.228.34.84) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 104 Identification: 0x949e (38046) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: IPIP (4) Header checksum: 0xd40c [validation disabled] [Good: False] [Bad: False] Source: 89.18.172.156 (89.18.172.156) Destination: 169.228.34.84 (169.228.34.84) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Protocol Version 4, Src: 44.137.40.2 (44.137.40.2), Dst: 44.0.0.1 (44.0.0.1) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 84 Identification: 0x8f7f (36735) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: ICMP (1) Header checksum: 0x2a9e [validation disabled] [Good: False] [Bad: False] Source: 44.137.40.2 (44.137.40.2) Destination: 44.0.0.1 (44.0.0.1) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0xbba6 [correct] Identifier (BE): 23938 (0x5d82) Identifier (LE): 33373 (0x825d) Sequence number (BE): 1 (0x0001) Sequence number (LE): 256 (0x0100) Timestamp from icmp data: Jul 12, 2017 20:30:58.200360000 CEST [Timestamp from icmp data (relative): 0.000371000 seconds] Data (48 bytes) 0000 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 ................ 0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ........ !"#$%&' 0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567 Data: 08090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f... [Length: 48] This system has our own gateway 213.222.29.194 as its default tunnel route but otherwise it is a standard ampr-ripd setup with 2 route tables. Rob

2 1

gw.ampr.org from tunnel system
by Rob Janssen 12 Jul '17

12 Jul '17

Recently I saw a header in the DNS robot reply mails that the mail address has changes and the update mails now have to be sent @gw.ampr.org. I changed that in my script, but then I noticed that my system on the IPIP tunnel network cannot send mail there. Of course gw.ampr.org is 44.0.0.1 and there have been issues with reaching that from the IPIP gateway systems, but I thought those were fixed. I have changed my mail config to send the mail via my ISP smarthost and that works, but what is the status on this? Is it supposed to be working, does it work for others? It only affects my gateway on the IPIP tunnel network. From the BGP routed gateway and the radio-connected systems here in the Netherlands there is no problem, and neither from normal internet addresses. Rob

3 2

misconfigured gateways
by Brian Kantor 07 Jul '17

07 Jul '17

In general, all encapsulated packets sent to the amprgw router for decapsulation and forwarding should have inner source addresses on the 44.0.0.0/8 network, since they are being originated by hosts on that network. The owners of the following gateways should contact me or consult the error listing in the /private/pkterrors.txt file regarding misconfiguration of their gateway routing rules which is leading to the sending of packets to amprgw which have a non-44 inner source address. These packets are being discarded by the gateway router, so they're not being delivered anywhere. This could be caused by an erroneous default route pointing at amprgw. Probably you shouldn't have one of those. This isn't causing any harm, but it's not doing any good either. - Brian VE3CGG 24.55.194.111 KE5MKM 98.6.215.34 EB1AJP 188.82.69.230 VE2HOM 206.80.251.222

1 0

Re: [44net] Traceroute storm
by Rob Janssen 03 Jul '17

03 Jul '17

> For several hours now, amprgw has been seeing a storm of traceroutes from > hundreds of different source addresses. It looks like a botnet has been > activated to probe net 44 using short-TTL packets like traceroute. > In reaction to this, I've temporarily set the gateway to discard any > packet with a TTL of less than 30. (The TTL is decremented by one when > the packet is forwarded; normally, of course, only packets with a TTL > value of zero are discarded.) Interesting... is it real traceroute traffic (to UDP port 33434 and higher) or is it different? I have had this rule (with TTL limit 16 and only for UDP 33434-33499) on our gateway for quite some time and I do not see many hits on it. Maybe the traffic is different. I do not observe increased input traffic. Rob

5 6

Re: [44net] Traceroute storm
by Rob Janssen 03 Jul '17

03 Jul '17

> However, there's quite a bit more insidious kind of traffic. The Nagra > people (Kudelski Switzerland) are probing our network with false > NTP packets from the subnet 185.35.62.0/23. The comment in the RIPE > database is > inetnum: 185.35.62.0 - 185.35.63.255 > descr: This IP network is used for Internet security research. Internet-scale port scanning activities are launched from this network. Don't hesitate to contactportscan at nagra.com <http://hamradio.ucsd.edu/mailman/listinfo/44net> would you have any question. > I've added that subnet to the "security research" blocking list here. > Seems it's a never-ending battle. It sure is. 185.35.60.0/22 was already in the blocklist here, I have seen "research" traffic from the bottom half of that network as well. Rob

1 0

Traceroute storm
by Brian Kantor 03 Jul '17

03 Jul '17

For several hours now, amprgw has been seeing a storm of traceroutes from hundreds of different source addresses. It looks like a botnet has been activated to probe net 44 using short-TTL packets like traceroute. In reaction to this, I've temporarily set the gateway to discard any packet with a TTL of less than 30. (The TTL is decremented by one when the packet is forwarded; normally, of course, only packets with a TTL value of zero are discarded.) This will not affect normal traffic, most of which has TTL values in the 40 to 64 range, but will throw away the short TTL packets used by traceroute. If you have problems with some site suddenly timing out instead of its normal reachability, let me know and I'll re-enable the normal TTL processing. In that case, we'll have to find some other way to cope with the storm of traceroutes. - Brian

2 1

Mikrotik script issues
by Mark Scrano 30 Jun '17

30 Jun '17

Hello,I am having an issue with the routes script for the Mikrotik routers. I got through all the steps to get RIP working and routes began populating based of the guides here: http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers . Then I got the latest script from http://www.yo2loj.ro/ version 3.1, while ssh'd into the box I copied and pasted the script http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.rsc into the terminal. I used my public IP address in the AmprPublicIp field and my AMPRnet IP assigned to the DMZ IP address 44.68.204.1 then ran the update_amprgw script. At first I thought it was working but not all of the routes appear to be populating. I am only seeing 55 interfaces, much less than the 400+ I would expect. Any advise on this issue?ThanksMark ScranoK2EXE

3 5

Re: [44net] SYN Flood, etc.
by Josh 28 Jun '17

28 Jun '17

Sorry, that would be mine. I'm building a new gateway and was having some issues, I'll disable that host asap. Josh - VK2HFF -------- Original message -------- From: lleachii--- via 44Net <44net(a)hamradio.ucsd.edu> Date: 28/06/2017 05:03 (GMT+10:00) To: 44net(a)hamradio.ucsd.edu Cc: lleachii(a)aol.com Subject: Re: [44net] SYN Flood, etc. Rob, It appears the SYN Flood are actually coming from AMPPRNet, not the Interent: 2017-06-27 13:16:16.705 3600.001 TCP 44.136.24.62:52055 -> 44.60.44.3:53 9 695 1 2017-06-27 13:16:16.705 3600.001 TCP 44.60.44.3:53 -> 44.136.24.62:52055 41 49452 1 2017-06-27 13:18:41.842 3600.004 TCP 44.136.24.62:51655 -> 44.60.44.3:53 4 306 1 2017-06-27 13:18:41.842 3600.004 TCP 44.60.44.3:53 -> 44.136.24.62:51655 28 37152 1 After closing tcp/53, this is the only host causing hits on my SYN Flood filter. - KB3VWG _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

3 5

Re: [44net] SYN Flood, etc.
by Rob Janssen 27 Jun '17

27 Jun '17

> Further inspecting the firewall, only 5 packets in over 20,000 were > dropped. Perhaps the SYN Flood setting is too sensitive for a series of > multiple DNS queries at the same time. I sometimes see mis-detections of floods on TCP port 53 too. The resolver has to open a separate connection for each request once it has to use TCP mode. Due to the increased use of DNSSEC this happens more often than in the past. Rob

1 0

Re: [44net] SYN Flood, etc.
by Rob Janssen 27 Jun '17

27 Jun '17

> I'll be closing TCP/53 to the Internet - NOW. You need to close UDP/53 as well! It is widely abused for DDoS amplification, you really should not offer DNS service on internet unless you have modern software to do rate limiting etc. Look at the poor souls who make a change to their MikroTik router (usually configuring it for PPPoE according to the directions they find on Youtube instead of according to the manual) and mistakenly open their DNS resolver on internet... they end up being abused as DDoS amplifier/reflector all the time. We run a slave DNS server for AMPRnet as well, but: only on the 44 network. Rob

2 2

Re: [44net] SYN Flood, etc.
by Rob Janssen 27 Jun '17

27 Jun '17

> - The only tcp/53 I have open is AMPR DNS (most connections are coming from 104.236.176.72) Those are on my list of scanners/blackhats. The name "stretchoid.com" is already indicative of what they do. However, as Brian Kantor also wrote, it is a really bad idea to run a DNS server on an internet-facing interface. Keep it accessible only from the amprnet side. Rob

2 1

SYN Flood, etc.
by lleachii＠aol.com 27 Jun '17

27 Jun '17

All, I looked at my router's system log and noticed two interesting messages: > [ 272.794578] conntrack: generic helper won't handle protocol 47. > Please consider loading the specific helper module. > [367924.542265] TCP: request_sock_TCP: Possible SYN flooding on port > 53. Sending cookies. Check SNMP counters. I realized I'm currently under a "small" attack. About 2 p.p.s. are causing my SYN_Flood rules to hit. What's interesting is: - I don't run any GRE tunnels (most of the Protocol 47 packets are coming from China) - The only tcp/53 I have open is AMPR DNS (most connections are coming from 104.236.176.72) Does anyone currently use tcp AXFR to copy 44.IN-ADDR.ARPA. or AMPR.ORG. from me? 73, - Lynwood KB3VWG

3 3

Money for Wireless Research
by Brian Kantor 27 Jun '17

27 Jun '17

The National Science Foundation and Mozilla are sponsoring an initiative to bypass the wired web to bring additional people online and to provide survivability in times of disaster. Sound familiar? Seems we're already doing some of that; perhaps some of us should apply for some of the grant money to spice things up. > https://blog.mozilla.org/blog/2017/06/21/2-million-prize-decentralize-web-a… - Brian

4 3

Re: [44net] Money for Wireless Research
by Rob Janssen 25 Jun '17

25 Jun '17

Decentralize the web is indeed what we have always been doing. Probably because we started in the times when the internet was still very decentralized and all communication was peer-to-peer. Lately, internet has been transformed into a client-server network much like the telephone BBS world was in those days: there are users, they connect to some server where all they want to have can be found and stored. This is also a reason why IPv6 has not really taken off. The design principle behind IPv6, to have enough addresses to assign one to every device and have all of those devices communicate peer-to-peer, has largely been abandoned on the internet. There is no reason anymore to have a different address for every device. In fact, now that we have the AMPRnet coming alive again here, many of the users are so accustomed to this way of working that they implement it on their ham network as well: everything NATted behind a single IP address. Even though they can just apply for a subnet large enough for their shack. Maybe we should invest in explaining the difference between our network and the internet as it is used today, and how this change on internet came about. It could help people think different. Rob

1 0

FYI Map progress
by Marius Petrescu 23 Jun '17

23 Jun '17

FYI: I added some click response stuff to your dots on the map... http://yo2tm.ampr.org/ampr-map/

6 10

Is Your wireless router (or access point) breakable ?
by R P 22 Jun '17

22 Jun '17

It might interest some of us ... https://qz.com/1008273/complete-list-of-wifi-routers-included-in-wikileaks-… [https://qzprod.files.wordpress.com/2017/06/screen-shot-2017-06-16-at-3-49-4…]<https://qz.com/1008273/complete-list-of-wifi-routers-included-in-wikileaks-…> If your home wifi router is on this list, it might be vulnerable to CIA hacking tools<https://qz.com/1008273/complete-list-of-wifi-routers-included-in-wikileaks-…> qz.com The collection of tools can be used to monitor internet activity

1 0

Re: [44net] www.ampr.org Not responding ?
by Rob Janssen 21 Jun '17

21 Jun '17

> I don't think this would be wise because then the DDoS'ers would > be targeting the 44-net address as well, thus impacting that router. > - Brian Is it now running on a machine at home on some private DSL line? (as the whois for the IP suggests) In that case it should be possible to make it a little more resistant against this kind of malevolents... (not that I volunteer to host it on our internet connection, we have DDoS experience as well...) Is there any indication who is behind this? Is there any activity on that system that could grief someone or some group? Any message telling what has to be stopped or done? Rob

2 1

Re: [44net] www.ampr.org Not responding ?
by Steve L 21 Jun '17

21 Jun '17

Probably more denial of service stuff going on. I know www.ampr.org and portal.ampr.org are not on 44net space, but I wonder if there would be a possible advantage to being accessible both from the normal internet and via a private 44 route. In DDoS cases maybe things could be as normal for connects within the network? That is the same thought I had to the login required for the gw.ampr.org stats. Maybe their could be no login required within the network to view? Just some thinking out loud.

3 2

www.ampr.org Not responding ?
by R P 21 Jun '17

21 Jun '17

Is www.ampr.org<http://www.ampr.org> working ? Is it accessible from NON 44 IP if answers are Yes to all I cant contact it Ronen - 4Z4ZQ Amateur Radio Digital Communications | Managing the ...<http://www.ampr.org/> www.ampr.org Looking for technical information or how to get a subnet allocation? Be sure to visit our WIKI, and interact with us on the Portal. You may join our discussion ...

4 3

Change of IP address - VK6HGR
by Gavin Rogers 21 Jun '17

21 Jun '17

Hi All. Apologies for sending this to the list, but I've discovered I haven't got valid email addresses for everyone that connects to my system. After switching from ADSL to the Australian national broadband network the IP address my system was allocated for the last 10 years had to change: For those who may have been connecting to FBB or AXIP/UDP directly to my commercial IP address, please change your configuration From: 203.59.134.49 To: 203.59.7.248 The IPIP gateway IP has already been changed and vk6hgr.ampr.org/44.136.204.77 should be reachable. 73, Gavin -- Gavin Rogers | Amateur radio station VK6HGR http://www.livingwaters.com/good | http://vk6hgr.ampr.org/ MSN/Skype/Email: grogers(a)vk6hgr.echidna.id.au

1 0

Re: [44net] Problems with iptables and ampr-ripd
by Steve L 20 Jun '17

20 Jun '17

As Marius said, there is no plug and play / universal setup, which I believe is good. Yes its frustrating at first, but when you do get it going at least you can say you learned something. Everyones setup will be different, as is their understanding of Linux and networking. I remember looking at the same wiki page quite some time back, and I was stumped at almost the very first step > ip link set dev ampr0 up I'd get no such device returned as an error. I discovered the ampr0 naming convention wasn't liked by my flavor of Linux, it pretty much had to be tunl0 for me. And from there many more things that took my mind quite a while to understand, specifically with the need for policy routing etc. This is what I wrote after I had it working. An explanation that made sense to me. And I have tried to keep it to date in a minimal fashion to help others. http://www.qsl.net/k/kb9mwr//wapr/tcpip/ampr-ripd.html I have since done things differently. Rather than adding a USB network eth1, I use VLAN tags and a switch. And I never did really document the firewall stuff, which I do now as well. Start small and work up from there is my suggestion. I always recommend starting by installing tcpdump and connecting directly to your modem (in a bridged mode if needed), and verifying the RIP traffic. From there you can see if your equipment can forward protocol 4 or DMZ correctly to whatever your gateway machine will be. Steve, KB9MWR

2 1

Info Please
by Peter Mallett 20 Jun '17

20 Jun '17

Hi All, Is the address _postmaster(a)portal.ampr.org_ a valid address, the last two I have sent there have bounced. Regards ..... Peter ZL2BAU

2 1

Problems with iptables and ampr-ripd
by Augustine Tabeling, W8AWT 20 Jun '17

20 Jun '17

Hi All, I am working on creating a gateway using the example at http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example however I am running into a few problems. !. When I try to input the iptables command|| |"sudo iptables -A OUTPUT -i lo -j ACCEPT"| ||under the protecting the gateway section, i get this error: "iptables v1.6.0: Can't use -i with OUTPUT Try `iptables -h' or 'iptables --help' for more information." 2. after seemingly successfully making and installing ampr-ripd 2.3, when I try to run "sudo ./find_pass.sh" It gives me the standard "sudo: ./find_pass.sh: command not found" and I cant figure out what to do. Further when I try to run the "./ampr-ripd -d -v -i ampr0" line from within the shell script, I get "-bash: ./ampr-ripd: No such file or directory" Help with either problem would be appreciated. 73, Augustine W8AWT || ||

3 4

Re: [44net] amprgw.ucsd.edu FTP
by Steve L 18 Jun '17

18 Jun '17

First off, thanks Brian for the encap on gw.ampr.org. I was always annoyed by the ancient non-standard CIDR format of the other one. Michael This is how I retrieve it curl -u <user>:<pw> https://gw.ampr.org/private/encap.txt > encap.txt wget works too. You don't need a 44 route, because gw.ampr.org is in the DNS and is reachable from the normal internet. Steve, KB9MWR

2 1

amprgw.ucsd.edu FTP
by Michael Fox - N6MEF 18 Jun '17

18 Jun '17

Trying to download ftp:// <ftp://<user>:<pw>@amprgw.ucsd.edu/private/encap.txt> <user>:<pw>@amprgw.ucsd.edu/private/encap.txt but amprgw is refusing connection. I could swear this worked before. Michael N6MEF

2 3

Re: [44net] alternate encap.txt download
by Michael Fox 18 Jun '17

18 Jun '17

Great. Thanks. Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 6/17/17 15:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] alternate encap.txt download Sure, why not? It's all automatic anyway. - Brian On Sat, Jun 17, 2017 at 02:59:38PM -0700, Michael Fox - N6MEF wrote: > Brian, > Do you intend to continue to generate the alternate encap.txt file on > amprgw.ucsd.edu? > If so, I'd like to update my scripts to try that location if the portal > fails. > Michael > N6MEF _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

alternate encap.txt download
by Michael Fox - N6MEF 17 Jun '17

17 Jun '17

Brian, Do you intend to continue to generate the alternate encap.txt file on amprgw.ucsd.edu? If so, I'd like to update my scripts to try that location if the portal fails. Michael N6MEF

2 1

Re: [44net] 44 net connectivity problems ?
by Josh 16 Jun '17

16 Jun '17

Thanks Tom.It's reassuring to see that your connection made it through too, and that you didn't get your ipip packets dropped just upstream of me like amprgw's. I think I'll try and convince my ISP's network engineers to take a look at Brian's ipip traceroute output, maybe they overlooked something last time. Cheers,Josh -------- Original message -------- From: Tomasz Stankiewicz <sp2l(a)wp.pl> Date: 16/06/2017 20:18 (GMT+10:00) To: josh(a)festy.org Cc: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] 44 net connectivity problems ? Josh. Just to confirm availability of your host: root@linux:/# ip route get 44.136.24.60 from 44.165.2.2 44.136.24.60 from 44.165.2.2 via 110.175.89.41 dev tunl0 cache window 840 root@linux:/# traceroute 44.136.24.60 traceroute to 44.136.24.60 (44.136.24.60), 30 hops max, 60 byte packets 1 net.vk2hff.ampr.org (44.136.24.60) 717.780 ms 740.340 ms 762.076 ms root@linux:/# Best regards. Tom - SP2L

3 5

Re: [44net] 44 net connectivity problems ?
by Charles 16 Jun '17

16 Jun '17

I got your screenshot fine.

1 0

Re: [44net] 44 net connectivity problems ?
by Tomasz Stankiewicz 16 Jun '17

16 Jun '17

I concur with Charles. Exactly the same I obswerve on my Windows 7/64b __NOT 44-net aware__ Cable ISP Vectra, Poland. Tracing route to net.vk2hff.ampr.org [44.136.24.60] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.0.1 2 5 ms 6 ms 7 ms 10.149.64.1 3 6 ms 7 ms 8 ms 172.20.253.1 4 12 ms 13 ms 13 ms 172.17.0.249 5 12 ms 11 ms 14 ms 172.17.0.250 6 14 ms 12 ms 18 ms 172.17.0.133 7 12 ms 14 ms 13 ms 172.17.28.238 8 13 ms 13 ms 13 ms 172.17.28.238 9 27 ms 14 ms 12 ms ae48-48.r7.poland-rs.thinx.atman.pl [212.91.0.10] 10 40 ms 42 ms 46 ms limelight.plix.pl [195.182.218.35] 11 148 ms 147 ms 149 ms lag23.fr4.ord.llnw.net [68.142.88.56] 12 166 ms 171 ms 167 ms 68.142.88.147 13 187 ms 187 ms 188 ms 68.142.88.155 14 187 ms 187 ms 188 ms lag7.fr4.aza1.llnw.net [68.142.64.50] 15 189 ms 188 ms 189 ms tge1-1.fr3.aza1.llnw.net [69.164.62.16] 16 198 ms 201 ms 198 ms lag16.fr3.lax.llnw.net [69.28.189.233] 17 201 ms 197 ms 197 ms 198.32.251.189 18 200 ms 198 ms 199 ms dc-tus-agg3--lax-agg6-100ge.cenic.net [137.164.11.7] 19 201 ms 201 ms 202 ms dc-sdg-agg4--tus-agg3-100ge.cenic.net [137.164.11.9] 20 226 ms 202 ms 203 ms dc-ucsd-1--sdg-agg4.cenic.net [137.164.23.54] 21 202 ms 202 ms 203 ms nodem-core-6807-vlan2767-gw.ucsd.edu [132.239.254.61] 22 203 ms 203 ms 203 ms rci-nodem-p2p.ucsd.edu [132.239.254.177] 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. Next test with IP address 44.139.11.30 assigned from AMPRNet VPN: Tracing route to net.vk2hff.ampr.org [44.136.24.60] over a maximum of 30 hops: 1 57 ms 57 ms 57 ms dyn1.oh-vpn.ampr.org [44.139.11.1] 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 474 ms 478 ms 470 ms net.vk2hff.ampr.org [44.136.24.60] Trace complete. Yet another test, with IP address 44.165.15.17 assigned from SP2L VPN: Tracing route to net.vk2hff.ampr.org [44.136.24.60] over a maximum of 30 hops: 1 74 ms 77 ms 71 ms avpn1.sp2l.ampr.org [44.165.15.1] 2 565 ms 549 ms 549 ms net.vk2hff.ampr.org [44.136.24.60] Trace complete. One more test, with IP address 44.137.40.185 assigned from Netherland's VPN: Tracing route to net.vk2hff.ampr.org [44.136.24.60] over a maximum of 30 hops: 1 42 ms 44 ms 43 ms gw-44-137.pi9noz.ampr.org [44.137.0.1] 2 467 ms 474 ms 475 ms vk2hff.ampr.org [44.136.24.60] Trace complete. Best regards. Tom - SP2L

2 1

DNS Cleanup
by Brian Kantor 16 Jun '17

16 Jun '17

Returning to the perennial subject of cleaning up the AMPR.Org DNS database, Neil Johnson has done a thorough job of investigating the entries in the current database. He has generated a file available from the gw.ampr.org anonymous FTP server "Hosts-TBD.txt" which lists 2,045 callsign-based entries in the DB where 0. They're in the current AMPR.Org DNS. 1. They're not found in active entries on QRZ.com. 2. They're not found in the online Callbook database. 3. They're not in the portal. 4. They're not in HamNet.de. 5. They were NOT entered into the AMPR.Org DNS after 2011. 6. Or they are listed as expired in QRZ. This is about 5% of the database. Not a large amount but a definite place to start. I propose to delete these entries from the AMPR.Org DNS around July 1st. - Brian

7 19

AMPR.Org DNS
by Brian Kantor 16 Jun '17

16 Jun '17

I've switched the AMPR.Org and 44.in-addr master nameserver over to using a new database and maintenance software. All seems to be working correctly. If you encounter any problems looking up a hostname or IP address in the relevant ranges, please let me know. - Brian

3 5

Re: [44net] 44 net connectivity problems ?
by Tomasz Stankiewicz 16 Jun '17

16 Jun '17

Josh. Just to confirm availability of your host: root@linux:/# ip route get 44.136.24.60 from 44.165.2.2 44.136.24.60 from 44.165.2.2 via 110.175.89.41 dev tunl0 cache window 840 root@linux:/# traceroute 44.136.24.60 traceroute to 44.136.24.60 (44.136.24.60), 30 hops max, 60 byte packets 1 net.vk2hff.ampr.org (44.136.24.60) 717.780 ms 740.340 ms 762.076 ms root@linux:/# Best regards. Tom - SP2L

1 0

Re: [44net] 44 net connectivity problems ?
by Josh 16 Jun '17

16 Jun '17

Hi Rob, Bob VE3TOK tested connectivity from his gateway and had no issues getting in to mine, which should rule out a conntrack issue. I've also ran traceroute and ping tests from other gateways via a different internet connection to asses this as well. Another test I tried along that line was sending ipip packets to amprgw for 15 minutes straight to see if any encapsulated rip packets might find their way in, but nothing. It seems like every gateway except the new amprgw can send and receive ipip packets to/from my gateway which is why I thought it might be a very specific host+protocol block implemented by my ISP. Everything was working fine for me up until a week or so ago. Josh - VK2HFF -------- Original message -------- From: Rob Janssen <pe1chl(a)amsat.org> Date: 16/06/2017 19:11 (GMT+10:00) To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] 44 net connectivity problems ? > My vdsl modem is a Huawei HG659b. The modem routes all DMZ traffic to an > interface on a Broadcom based AP running OpenWRT via a cisco WS-C3750g-24PS. > I can see all manner of connections hitting my DMZ interface from my > public IP (typical portscans etc) so the modem->DMZ forwarding seems ok. But do you ever see any unsolicited incoming traffic that is not ICMP, TCP or UDP? A "quite common" DMZ bug is that the router actually forwards only these protocols to the DMZ host, and not protocols like IPIP (4). However, it DOES return the replies on outgoing IPIP packets you send. So, when you try to ping someone on a tunnel it works, but when the NAT translation rule has disappeared (after a few seconds up to 3 minutes or so) an outgoing ping from the same host you just pinged does not work anymore. I have seen this several times on the IPIP mesh. People claiming their system works fine but still it is unreachable for unsolicited connections. Rob _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] 44 net connectivity problems ?
by Rob Janssen 16 Jun '17

16 Jun '17

> My vdsl modem is a Huawei HG659b. The modem routes all DMZ traffic to an > interface on a Broadcom based AP running OpenWRT via a cisco WS-C3750g-24PS. > I can see all manner of connections hitting my DMZ interface from my > public IP (typical portscans etc) so the modem->DMZ forwarding seems ok. But do you ever see any unsolicited incoming traffic that is not ICMP, TCP or UDP? A "quite common" DMZ bug is that the router actually forwards only these protocols to the DMZ host, and not protocols like IPIP (4). However, it DOES return the replies on outgoing IPIP packets you send. So, when you try to ping someone on a tunnel it works, but when the NAT translation rule has disappeared (after a few seconds up to 3 minutes or so) an outgoing ping from the same host you just pinged does not work anymore. I have seen this several times on the IPIP mesh. People claiming their system works fine but still it is unreachable for unsolicited connections. Rob

1 0

Re: [44net] AMPR.Org DNS
by Rob Janssen 16 Jun '17

16 Jun '17

> Unless Hotmail is still silently deleting automated messages - it used > to do that years ago, much to the annoyance of a place I previously > worked for. Clients would complain that their booking confirmations > would never arrive. Hotmail is not usable for production. It is as unreliable as most Microsoft stuff. Recently I sent a couple of messages about a network configuration problem to a user on the Dutch hamnet, and later he claimed he never got them. But my own outgoing mailserver has the logs of the delivery to the hotmail MX and accepted status. Rob

1 0

44 net connectivity problems ?
by R P 16 Jun '17

16 Jun '17

Has anyone else see connectivity problems of the 44 net ? My tunnel work but no connection to the internet Regards Ronen - 4Z4ZQ

10 24

Re: [44net] AMPR.Org DNS
by Rob Janssen 14 Jun '17

14 Jun '17

I get no reply on an update mail to the ampraddr robot, but the changes did get processed... Rob

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net