> >/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
> 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
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
> 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
Earlier I wrote:
> Well I did not get a mail from you, probably it has been lost somewhere due to spamfiltering.
I now found how that happened...
I use my @amsat.org address on this list, and I found that the forward address has been reset about 2 weeks
ago, back to a value that it was a few months ago. I had changed it since.
I still receive most of my mail because that other path still sort of works, but it tends to block a lot of mail that
from the amsat.org forwarder as spam.
So I now found a couple of mails in a spamfolder where I normally don't look anymore.
I'm not sure what happened, there appears to be no announcement on the amsat.org page, but it could be
that they had to restore a backup of the alias database. So when you use amsat.org and changed your
forwarding address, it might be worthwhile to check if it is still OK.
Rob
I have received repeated requests from a non licensed user. When I reject,
he resubmits. It is obvious that this person may have an alterior motive
as it is a hosting company.
What to do in such cases? I have just let the request sit. None of the
hams or it people in my area have ever heard of the hoster.
Any way to ban a submission?
Best,
Elias
Kd5jfe
On Feb 20, 2017 3:00 AM, "Rob Janssen" <pe1chl(a)amsat.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
> I was thinking what would be helpful is if there was specific information
> required, it would be good to prompt for it ahead of time. In reading
> through these threads, it appears there can be some variance in what may be
> required by each coordinator. Perhaps instead of free form text block
> there could be a means to prompt for some of the information that would be
> considered qualifying fields.
>
That is a good point!
There should be an optional text record for each network, to be entered by
its coordinator, about the local requirements for allocation and that will
be displayed on the request form above the input section.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
> I was thinking what would be helpful is if there was specific information required, it would be good to prompt for it ahead of time. In reading through these threads, it appears there can be some variance in what may be required by each coordinator. Perhaps instead of free form text block there could be a means to prompt for some of the information that would be considered qualifying fields.
That is a good point!
There should be an optional text record for each network, to be entered by its coordinator, about the local requirements for allocation and that will be displayed on the request form above the input section.
Rob
> Thanks Tom. The portal already automatically sends reminder notices
> to coordinators with outstanding allocation requests, twice a month.
> If all the coordinators agree, we could change that to weekly.
I don't think that will help. In the cases where I did not get a response from
others it usually turned out they were moving, busy at work, etc.
Overwhelming them with more notices is not going to solve that.
> I find that the coordinations which take more than a few minutes to handle
> are those where the requester is confused and asking for something that
> is not sensible, so an email exchange is necessary to get the request
> straightened out.
That is correct. There should be an option for the coordinator to abandon
the request and take the thing to e-mail. Now the only option is to reject
the request, which often upsets the requester and also (because of language barriers)
the requester often clicks all links in the message, causing it to be re-submitted.
I would like to see a button on that screen that just deletes the request without
further mail towards the requester, so I can then send mail and explain the situation.
Rob
> Hello Rob,
> I have receive your email this morning and reply to it before your send
> on the group, I also close my amprnet for the moment. I'm new with the
> mikrotik router and don't know all, I get information on the internet to
> get it work. Sorry for the bad packet this is not intentionnal.
> 73 de Pascal
> ve2hom
Hi Pascal,
Well I did not get a mail from you, probably it has been lost somewhere due to spamfiltering.
Good to hear you use a MikroTik router! It is possible to fix it on this kind of router.
When you go to the IP->Firewall page and open the NAT tab, you will find an existing NAT
rule that you use for your internet connection. It will probably show something like
"masquerade", chain srcnat, out.interface ether1.
You can just add another item like that, with the settings:
chain srcnat
src.address 192.168.0.0/16
out interface ! ether1 (click in the empty box for the ! to appear and select your internet interface)
action src-nat
to address 44.135.50.x (select an address you want to use for this)
That should fix your problem, assuming you use this router only for internet and hamnet and
have no other interfaces to other networks.
This rule will make any traffic from the 192.168 range to be translated to a fixed address in hamnet
(but only when it is not sent to the internet interface, that is where the other rule applies)
Rob
