44net

44net@mailman.ampr.org

3196 discussions

info (link Hub_EU): Catham_UK detected loop with Mitchell: DEST Attica_GR. DEST already via Attica_GR
by SP2L Tom 04 Oct '23

04 Oct '23

To whom it may concern. Greetings. In my server logs every single hour I see the following entries: Oct 4 05:21:31 linux conversd[1881152]: info (link Hub_EU): Catham_UK detected loop with Mitchell: DEST Attica_GR. DEST already via Attica_GR Oct 4 06:21:34 linux conversd[1881152]: info (link Hub_EU): Catham_UK detected loop with Mitchell: DEST Attica_GR. DEST already via Attica_GR Oct 4 07:21:38 linux conversd[1881152]: info (link Hub_EU): Catham_UK detected loop with Mitchell: DEST Attica_GR. DEST already via Attica_GR Oct 4 08:21:41 linux conversd[1881152]: info (link Hub_EU): Catham_UK detected loop with Mitchell: DEST Attica_GR. DEST already via Attica_GR This situation is going continuously more than a month. Something, somewhere seem to be definitely misconfigured. Possibly owner of offending convers server can take appropriate action to fix this, please? Best regards. -- Tom - SP2L https://www.sp2l.ampr.org ------------------------------------ It is nice to be important. But it is more important to be nice! Nobody is mistaken - so do I.

1 0

Mikrotik IPIP help/favour please
by Tom M0LTE 01 Oct '23

01 Oct '23

I've just powered on a Mikrotik hAP lite which I believe I had recently correctly configured, i.e. traffic between the internet and my 44net subnet was flowing on its ether2-4 ports, however appears to now be dropping incoming traffic to my subnet with Destination Unreachable ICMP frames. I have checked and re-checked my config steps from scratch with no success. Would someone with an IPIP-connected 44net allocation, a working Mikrotik setup, and 5 minutes of spare time mind please running "/export hide-sensitive" on their Mikrotik and sending me the output so I can diff it, to find my inevitably stupid error? Thanks.

1 0

Re: Clarification on Terms of Service
by pete M 30 Sep '23

30 Sep '23

I think we need to understand that the use of the IP space of ARDC 44net, have Nothing to do with the use of the RF space a ham can use in his/her country , and/or the rules that apply to your country/frequency/modulation scheme/3rd party data/Identification and the use of other bands that are not ham radio like the ISM band. What ARDC give you as rules of use of the IP space is just that, rules about the ip space, and the ip space can be use outside of the RF ham bands and even outside of the RF realms and just on fibers or UTP cable. Now. If you think you need to put some ssid or mac adress to be able to use the 44net ip allocated to you on RF links, that need to be check with your ruling body in your country. And it will depend witch rules Apply if you are using the ISM band , or the ham bands. Can a RF link travel from the ism band to the ham band to a fiber and then some cable and back to ham band and back into the ism band, totally. Can this happen on many different country, totally. Making it very hard to Apply all the rules from every country and multiple bands. So as I was saying, terms of service of ARDC. Not mixing the 2 will be of great help to understand all of this. Pierre VE2PF

1 0

Re: Clarification on Terms of Service
by lleachii＠aol.com 30 Sep '23

30 Sep '23

A few things mentioned about WiFI thus far in FCC land were not entirely accurate or could be easily avoided. I wanted to just note some things or offer as suggestions - as not to direct to any person in the chain or discourage healthy, civil (as I've read) and intelligent discussion:* One could change the BSSID (i.e. MAC address) of the Access Point, Ad-Hoc, etc. to a hexadecimal value representing the Callsign - problem solved* If one were using alloted channels and e.g. using an amplifier, such an example would otherwise require it to be licensed. * Another example might be altering the antenna of a [modern] Part 15 device, or experimental devices in WiFi Sensing radarBut with the latter examples, I digress.73,LynwoodKB3VWG

1 0

Clarification on Terms of Service
by Matthew H (2E0SIP) 30 Sep '23

30 Sep '23

Hi all, The Terms of Service <https://www.ardc.net/about/legal/terms-of-service/> states: *"**Your license permits You to use certain addresses exclusively for the purpose of Amateur Radio communications and experimentation, or other special uses as may be agreed to by ARDC"* I was wondering if this was clarified anywhere with examples of acceptable use cases? A few examples that I'm curious if they're permitted or not: - Hosting a radio club website that's accessible from the public internet, including from non radio amateurs. - Providing general outbound internet access for radio amateurs connecting via RF, whether its AX.25 or WiFi operating on the allocated amateur radio frequencies - Hosting not strictly amateur radio services such as an IRC server for discussing cars, but it's *only *reachable from other 44net addresses and RF users - Providing general outbound internet access to servers and services that might need to pull software updates from non-radio amateur servers. - Providing connectivity to a radio amateur related server such as a DMR Master, to other radio amateur related servers *outside* of 44net Any guidance would be appreciated. Matthew 2E0SIP

17 26

Re: Clarification on Terms of Service
by lleachii＠aol.com 27 Sep '23

27 Sep '23

This is a good and healthy discussion. I'm also glad the mailing list is available for this method of information exchange. ---73,Lynwood KB3VWG

1 0

Update DNS
by Stephen Atkins 27 Sep '23

27 Sep '23

Just did a dig on ve6cic.ampr.org and it's returning with an IP that is no where near what I thought it should be. Could someone update my DNS record to point to 44.135.148.131? Stephen Atkins VE6CIC/VE6CPU/VE6STA/VE6SU Sent with [Proton Mail](https://proton.me/) secure email.

2 1

DNS A record - just gateway, or all hosts?
by Tom M0LTE 26 Sep '23

26 Sep '23

Hi > If there is no DNS A record for a tunneled amprnet destination host, the traffic is not forwarded in either direction. Does this mean a single A record for my gateway (44.61.31.1/27), or multiple A records, one for each IP of my subnet? Thanks Tom M0LTE

5 8

Routing
by Stephen Atkins 25 Sep '23

25 Sep '23

Hello everyone. I've been playing with my 44 net addresses for a while now. I've got an Edgerouter X setup and I've attached a picture of the main config page for it. The edgerouter has an address of 44.135.148.129 and my computer has 44.135.148.130/27. Default gateway is 44.135.148.29. I've also had my DNS setup so it points ve6cic.ampr.org to 44.135.148.130 and my gateway on the portal points to my internet IP. I run a CC Cluster and BBS on this machine. Is there a way to route from the internet (not on the 44 Net) to this machine? [44Net.PNG] Stephen Atkins VE6CIC Sent with [Proton Mail](https://proton.me/) secure email.

2 1

Re: Problems accessing guthub
by Henrique Brancher Gravina 22 Sep '23

22 Sep '23

Thanks, TCP MSS was the answer! On my router ( Mikrotik ): /ip firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn On Sun, Sep 17, 2023 at 4:02 PM Jonathan Lassoff <jof(a)thejof.com> wrote: > That DNS resolution seems ok, 20.201.28.151 is one of the web frontend > IPs. (Confirmed with their API's /meta endpoint: > https://api.github.com/meta) > > However, an operation timing out implies that something along the path > is filtering your TCP connection. > > Maybe use `tcptraceroute` to try and tell how far your initial TCP SYN > packet is making it (to try and tell whom is filtering). > > The other thought that comes in mind in the context of TCP breaking > while traversing VPNs (where small packets like ICMP pings are > working) is that maybe something along the path is not clamping TCP > MSS? Maybe try adding a `mssfix` option into the OpenVPN config (maybe > sized 1420 bytes). > > --j > > On Sat, 16 Sept 2023 at 11:19, Henrique Brancher Gravina > <henrique(a)gravina.com.br> wrote: > > > > gnutls-cli cannot connect to the host, it give me a timeout: > > > > $gnutls-cli github.com:443 > > Processed 137 CA certificate(s). > > Resolving 'github.com:443'... > > Connecting to '20.201.28.151:443'... > > *** Fatal error: The operation timed out > > > > > > But I cant ping the host: > > > > $ping www.github.com > > PING github.com (20.201.28.151) 56(84) bytes of data. > > 64 bytes from 20.201.28.151 (20.201.28.151): icmp_seq=1 ttl=111 > time=22.3 ms > > 64 bytes from 20.201.28.151 (20.201.28.151): icmp_seq=2 ttl=111 > time=19.5 ms > > 64 bytes from 20.201.28.151 (20.201.28.151): icmp_seq=3 ttl=111 > time=22.3 ms > > 64 bytes from 20.201.28.151 (20.201.28.151): icmp_seq=4 ttl=111 > time=19.8 ms > > 64 bytes from 20.201.28.151 (20.201.28.151): icmp_seq=5 ttl=111 > time=19.7 ms > > > > > > > > > > On Sat, Sep 16, 2023 at 3:33 AM Jonathan Lassoff <jof(a)thejof.com> wrote: > >> > >> For what it's worth, I am able to successfully do git clones from IPv4 > >> Github from 44net BGP island space, and even that repo you list. > >> > >> That error suggests that something happened with GNUTLS while > >> establishing a TLS connection. Maybe test just that with GNUTLS and > >> run "gnutls-cli github.com:443"? > >> > >> On Fri, 15 Sept 2023 at 23:08, Henrique Brancher Gravina via 44net > >> <44net(a)mailman.ampr.org> wrote: > >> > > >> > Hello, > >> > > >> > I am running a 44 network with bgp announces on Vultr ( mikrotik ) > and a VPN to my home ( mikrotik ) . Everything is working fine inbound and > outbound traffic are being routed ok. > >> > > >> > The problem is that I can use github on the server on my 44 hosts. > >> > > >> > For example: > >> > > >> > # git clone https://github.com/Henriquegravina/DxccResolver > >> > Cloning into 'DxccResolver'... > >> > fatal: unable to access ' > https://github.com/Henriquegravina/DxccResolver/': gnutls_handshake() > failed: Error in the pull function. > >> > # root@odc1:/home/henrique/tmp# git clone > https://github.com/Henriquegravina/DxccResolver > >> > Cloning into 'DxccResolver'... > >> > fatal: unable to access ' > https://github.com/Henriquegravina/DxccResolver/': gnutls_handshake() > failed: Error in the pull function. > >> > > >> > Thanks for any help. > >> > PU3IKE > >> > > >> > > >> > _______________________________________________ > >> > 44net mailing list -- 44net(a)mailman.ampr.org > >> > To unsubscribe send an email to 44net-leave(a)mailman.ampr.org >

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net