44net March 2017

44net@mailman.ampr.org

27 participants
25 discussions

Re: [44net] AXUDP spec
by Rob Janssen 03 Mar '17

03 Mar '17

> >/The list of UDP ports at Wikipedia(1) doesn't show port 93 or 10093, /> >/so I suggest we correct Wikipedia's list, since port 93 is shown as /> >/assigned to "Device Control Protocol" by the IANA(3). / > Yes, our usage of port 93/UDP for AXUDP is completely unrecognized by > IANA. There is no official document describing AXUDP so there is no > way for us to claim a port - although there's no prohibition on > using any port number we want, since port numbers are not absolutes. > Still, it's not wise to double-up on port numbers. In the "old days" it was quite easy to register port numbers, and in fact I have registered a few myself that I still use for similar but not the same purposes (459, 1535, 1536). However, it appears to be not as simple anymore and looking at protocols that are in much more widespread use than AXUDP it appears to be not common anymore to register ports used only by some proprietary protocol at IANA (there are way, way more protocols in use than those with IANA-registered port numbers). Note that at the time I registered the above 3, IANA would not take suggestions for the numbers to register. I claimed different numbers that were unregistered, but they gave me those instead. Asking for port 93 to be registered is unlikely to succeed, 10093 may be possible. Registered port numbers are useful mainly for open protocols that are widely implemented and that accept unsolicited incoming connections. So everyone knows what port you have your wellknown services listening on. There is not much that can go wrong when using a port number without registering it, especially when the receiving application accepts data only from a pre-configured peer. The port numbers used essentially don't matter in that case, the only thing you need to make sure is that you don't have another session with that same peer that would want to use the same port number. (e.g. it would not be wise to use port 5198/5199 as these are used by Echolink, another port usage that is not registered at IANA and is in much more widespread use than AXUDP) Rob

2 1

Re: [44net] Hello
by Rob Janssen 03 Mar '17

03 Mar '17

> I'm a bit confused by your post: since 172.29.x.x addresses are > reserved for "Detached" networks, please clarify the source of the > 172.29.60.0 IP range you mentioned. Is it provided by your ISP, or are > you going through a corporate network to get to the Internet? TIA. This range is from RFC1918 where the 192.168 addresses also come from. He probably has those addresses on his LAN and uses NAT to connect to internet. Of course it is possible to use NAT between such a range and the AMPRnet, but I don't recommend it. It is better to assign net-44 addresses to AMPRnet devices, maybe have 2 addresses on one device. Understanding a mixed-network NAT configuration (NAT to internet and NAT to AMPRnet in the same network router) is hard for most people, and often mistakes are made, resulting it lots of RFC1918 traffic ingress in the AMPRnet. I get lots of log entries like this in our gateway: Mar 3 09:56:13 Packet DROP: IN=gre8 OUT=tun0 SRC=192.168.1.101 DST=44.137.25.148 LEN=590 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=5060 DPT=5060 LEN=570 (you see, the timestamp is "current") Apparently someone experimenting with SIP. My own SIP phone is at 44.137.41.104 so I don't have such issues, I can connect to that 44.137.25.148 SIP server without NAT. Rob

1 0

AXUDP spec
by Michael Fox - N6MEF 02 Mar '17

02 Mar '17

I'm looking for the specific definition of AXUDP. Is there an official protocol specification for AXUDP somewhere? Thanks, Michael N6MEF

6 12

Hello
by Tom C 02 Mar '17

02 Mar '17

I've bitten the bullet and started to make some progress getting on 44net. I'm certain my current issues are firewall and I'll get it sorted out. My non-ham network is in the 172.29.60.0/22 range. I don't think I'm leaking internal stuff to my partially built tunnel but If anyone sees packets from that block please let me know. Status: Attempted to ping 44.0.0.1 on a system on the ampr enclave on my network, With tcpdump listening on the gateway ampr0 interface I can see packets going out on the interface but that doesn't mean the packets are getting out of the box. I'm not seeing a response but like I said, I think it's a firewall issue. I just wanted to say Hi to to everyone and say I'm looking forward to exchanging packets with everyone 73 de n2xu Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+ ce -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

4 4

Re: [44net] AXUDP spec
by Rob Janssen 02 Mar '17

02 Mar '17

> Unfortunately, there are problems with AXIP and AXUDP ever since the > revisions of AX.25 were published - the AX.25 frames may get too big > to encapsulate in unfragmented IP and UDP frames. Any new document > would have to discuss the fragmentation issues, and I'll bet they're > not defined. (As far as I know, the same issue applies to ROSE, KISS, > and Net/Rom encapsulation too.) Is this an issue? The AXUDP protocol simply is "put AX.25 frames in UDP datagrams" and an UDP datagram can be nearly 64KB in size so I would not think there are any issues. UDP and IP handle the fragmentation and reassembly and the receiver gets the original datagram to insert it into the AX.25 stack. Of course, AXUDP senders should not set the DF flag, and if they do, they should not expect more than about 512 bytes maximum frame size. Which still is enough for classic AX.25 packet radio. > Do any of the various implementations of AX.25 encompass v2.0 et seq as > published by TAPR? Ie, is anyone actually implementing jumbo frames, > expanded frame sequence numbers, etc? Or should we just treat it as a > bad idea that should be buried and go on with the old protocol? The actual AX.25 version and extensions like jumbo frames and extended sequence numbers should not affect AXUDP at all. The UDP layer only replaces the HDLC layer normally used to transfer data over radio, and all things happening in AX.25 should be compatible between the endpoints, as always. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2017