Date   

Re: resolv.conf

Charlie Wa2gug
 

Fred,
Still get same error:

root@stn4827:~# chattr +i /etc/resolv.conf
root@stn4827:~# ping www.microsoft.com
ping: unknown host www.microsoft.com
root@stn4827:~# ping www.irlp.net
ping: unknown host www.irlp.net
root@stn4827:~#

I'm out of my league with this stuff.


Re: resolving site names

David Cameron - IRLP
 

I prefer them to Google DNS because of tracking reasons, and I also can always recall both the primary and secondary of the OpenDNS servers.

I used to use the ones at the local university, but I was asked to stop sending premade systems out around the world that used them for host resolution :)

Dave Cameron
VE7LTD

On 15/01/2020 11:28 a.m., Michael Champion Sr wrote:
Those are OpenDNS servers.

-Michael

-----Original Message-----
From: IRLP@irlp.groups.io <IRLP@irlp.groups.io> On Behalf Of David Cameron - IRLP
Sent: Wednesday, January 15, 2020 1:26 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] resolving site names

Well something is not right with those servers. I would make the file the following:

nameserver 1.1.1.1
nameserver 1.0.0.1

Remove all other entries.

Dave Cameron

On 15/01/2020 11:11 a.m., Charlie Wa2gug wrote:
Just corrected all tests via the script. I can ping 8.8.8.8 from the
machine but it will not resolve irlp.net. I do have my isp's name
server in the resolv.conf file nameserver 24.148.96.18 nameserver
208.67.222.222 nameserver 208.67.220.220

Any help will be appreciated.





Re: resolving site names

Michael Champion Sr
 

Those are OpenDNS servers.

-Michael

-----Original Message-----
From: IRLP@irlp.groups.io <IRLP@irlp.groups.io> On Behalf Of David Cameron - IRLP
Sent: Wednesday, January 15, 2020 1:26 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] resolving site names

Well something is not right with those servers. I would make the file the following:

nameserver 1.1.1.1
nameserver 1.0.0.1

Remove all other entries.

Dave Cameron

On 15/01/2020 11:11 a.m., Charlie Wa2gug wrote:
Just corrected all tests via the script. I can ping 8.8.8.8 from the
machine but it will not resolve irlp.net. I do have my isp's name
server in the resolv.conf file nameserver 24.148.96.18 nameserver
208.67.222.222 nameserver 208.67.220.220

Any help will be appreciated.


Re: resolving site names

David Cameron - IRLP
 

Well something is not right with those servers. I would make the file the following:

nameserver 1.1.1.1
nameserver 1.0.0.1

Remove all other entries.

Dave Cameron

On 15/01/2020 11:11 a.m., Charlie Wa2gug wrote:
Just corrected all tests via the script. I can ping 8.8.8.8 from the machine but it will not resolve irlp.net. I do have my isp's name server in the resolv.conf file
nameserver 24.148.96.18
nameserver 208.67.222.222
nameserver 208.67.220.220

Any help will be appreciated.


resolving site names

Charlie Wa2gug
 

Just corrected all tests via the script. I can ping 8.8.8.8 from the machine but it will not resolve irlp.net. I do have my isp's name server in the resolv.conf file
nameserver 24.148.96.18
nameserver 208.67.222.222
nameserver 208.67.220.220

Any help will be appreciated.


Re: resolv.conf

Fred
 

Charlie in resolv.conf  set the nameserver to 8.8.8.8

 

Then to lock that in use this command    chattr +i /etc/resolv.conf

 

 

The chattr command will lock your namesever to 8.8.8.8     that should fix DNS issues

 

From: Charlie Wa2gug
Sent: Wednesday, January 15, 2020 11:16 AM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] resolv.conf

 

Ok... will keep digging. 

Thanks

 

 

Charlie wa2gug

ARRL FIELD INSTRUCTOR, VE




-------- Original message --------
From k9dc <Dave@...>
Date: 01/15/2020 09:14 (GMT-05:00)
To IRLP@irlp.groups.io
Subject Re: [IRLP] resolv.conf




I don’t know what *magic* you are referring to. There is nothing *I* can deform my location. You simply need to make sure all the tests in troubleshoot-irlp pass. If that happens, then try the Echo reflector (9990).  Right now it looks like your node is on-line, but is administratively disabled.

-k9dc

> On Jan 15, 2020, at 08:55, Charlie Wa2gug <wa2gug@...> wrote:
>
> Dave,
>
>
>
> Just cleared the error. Typo. If you can do your magic I would appreciate it.
>
> Thanks again…
>






 


Re: resolv.conf

Charlie Wa2gug
 

Ok... will keep digging. 
Thanks


Charlie wa2gug
ARRL FIELD INSTRUCTOR, VE



-------- Original message --------
From k9dc <Dave@...>
Date: 01/15/2020 09:14 (GMT-05:00)
To IRLP@irlp.groups.io
Subject Re: [IRLP] resolv.conf




I don’t know what *magic* you are referring to. There is nothing *I* can deform my location. You simply need to make sure all the tests in troubleshoot-irlp pass. If that happens, then try the Echo reflector (9990).  Right now it looks like your node is on-line, but is administratively disabled.

-k9dc

> On Jan 15, 2020, at 08:55, Charlie Wa2gug <wa2gug@...> wrote:
>
> Dave,
>
>
>
> Just cleared the error. Typo. If you can do your magic I would appreciate it.
>
> Thanks again…
>








Re: backup_for_reinstall

Nosey Nick VA3NNW
 

Brian Alexander via Groups.Io wrote:
[...] I am wondering whether it continues to be interactive in most
recent releases and whether it will likely always be so.
Mine (up-to-date, latest release), when run AS ROOT, seems to (take quite some time to) generate a tar file without interaction, then ask...

Do you have a USB stick inserted for the backup file? : (Y/n)

You can make it non-interactive by simply:

echo n | sudo ~repeater/scripts/backup_for_reinstall

... which is presumably exactly what you mean by "feed it the input it expects".

--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; sig@...
The light at the end of the tunnel may be an oncoming train.


Re: resolv.conf

k9dc
 

I don’t know what *magic* you are referring to. There is nothing *I* can deform my location. You simply need to make sure all the tests in troubleshoot-irlp pass. If that happens, then try the Echo reflector (9990). Right now it looks like your node is on-line, but is administratively disabled.

-k9dc

On Jan 15, 2020, at 08:55, Charlie Wa2gug <wa2gug@...> wrote:

Dave,



Just cleared the error. Typo. If you can do your magic I would appreciate it.

Thanks again…


Re: resolv.conf

Charlie Wa2gug
 

Dave,


Just cleared the error. Typo. If you can do your magic I would appreciate it.

Thanks again...

On 1/12/2020 13:42, k9dc wrote:
Well, it won’t work until you fix TCP 15425. So something is amiss in your router. Are all ports outgoing allowed?  Did DNS pass okay?  DNS is required to update the status page, but your node has been gone for a long time.

http://status.irlp.net/?nodeid=4827

-k9dc



On Jan 12, 2020, at 13:34, Charlie Wa2gug <wa2gug@...> wrote:

Dave,

This is the only error I get :

Performing INBOUND UDP and TCP Port Forwarding Test
Detecting Incoming IP = 24.148.124.200
Testing TCP and UDP ports .. done.

-----------------------------------------------------------------------------
TEST No. 2a REPORT - TCP ERROR - TCP port 15425 is NOT forwarded
                                           correctly.
Waiting 4 seconds .... done.
TEST No. 2b REPORT - UDP PASS - UDP ports 2074-2093 are forwarded correctly.
TEST No. 2c REPORT - EchoLink UDP ERROR - The following UDP port(s):
 5198  5199  is/are not forwarded correctly.

Can't find any thing wrong in Fortigate router.

My node is 4827

On 1/12/2020 13:25, k9dc wrote:
On Jan 12, 2020, at 06:13, Charlie Wa2gug <wa2gug@...>
 wrote:

Guy's finally cleaning up the node. I noticed the node was not on the active list. I checked the resolv,conf. I do have 2 name servers in it. I'm using google 8.8.8.8,8.8.4.4
Any ideas?

What is troubleshoot-irlp telling you?  Also what is your node number?

-k9dc



-- 
Charles L. Alfano
WA2GUG
ARRL VE, Instructor


<wa2gug.vcf>



-- 
Charles L. Alfano
WA2GUG
ARRL VE, Instructor


Re: backup_for_reinstall

Brian Alexander
 

Dave;

Thanks for the offer. The supplied backup is fine. I’m just worried I’ll eventually use it when the expected inputs have changed — the perils of set it and forget it. Unfortunately, I’m quite good at the “forgetting” part.

Brian VA3AZA 


On Jan 12, 2020, at 9:54 PM, Dave Parks - WB8ODF via Groups.Io <wb8odf@...> wrote:


Brian,

If you have trouble with the backup script at all, I can write you one that is totally autonomous and all ya have to do is call it from your cron job.


>< Dave Parks ><
WB8ODF@...
http://wb8odf.com



On Sunday, January 12, 2020, 9:34:38 PM EST, Brian Alexander via Groups.Io <va3aza@...> wrote:


I would like to run backup_for_reinstall as a cron job every month or so and then gather the tgz with scp from another host. However, backup_for_reinstall is an interactive script on my release of the software. This is not really a problem, as I can feed it the input it expects. I am wondering whether it continues to be interactive in most recent releases and whether it will likely always be so.

Brian VA3AZA



Re: PGP Key ring key problem

k9dc
 

On Jan 12, 2020, at 17:12, David McGough <kb4fxc@...> wrote:

While I realize legacy policies may exist, I'm a bit baffled as to why cross-linking between networks is of any significance at the individual node level?
This is the only paragraph that warrants a response.

The policy is what it is. It doesn’t matter why or that you do not understand or are baffled. Crosslinks to other networks are simply not permitted. It simply means you cannot do that within IRLP. Any software hacks that allow cross linking products will be rejected from the network. Hamvoip is one such product.

Crosslinks ARE allowed on Reflectors because they are always and only destinations for calls. To further that type of operation, EXPerimental nodes were created. They allow literally anything to be connected. But the ability to use them is completely optional to each node owner. There is no security (PGP) provided by IRLP, but you can devise anything you want.

-k9dc


Re: backup_for_reinstall

 

Brian,

If you have trouble with the backup script at all, I can write you one that is totally autonomous and all ya have to do is call it from your cron job.


>< Dave Parks ><
WB8ODF@...
http://wb8odf.com



On Sunday, January 12, 2020, 9:34:38 PM EST, Brian Alexander via Groups.Io <va3aza@...> wrote:


I would like to run backup_for_reinstall as a cron job every month or so and then gather the tgz with scp from another host. However, backup_for_reinstall is an interactive script on my release of the software. This is not really a problem, as I can feed it the input it expects. I am wondering whether it continues to be interactive in most recent releases and whether it will likely always be so.

Brian VA3AZA



Re: PGP Key ring key problem

K1IMD
 

All Audio issues/Audio Level Standards/Technical Requirements/Quality Side/EchoLink aside:

IRLP = Internet RADIO Linking Project
To give you an idea about IRLP, as those early adopters of IRLP may recall, IRLP was built around the days before broadband Internet was widely available.  Many early contacts I had in England were on dial-up phone lines at 8K GSM because the cost of data was so pricey.  Broadband did not exist in most homes let alone radio sites and why IRLP supports a handshake for codec (8kGSM or wider) as well as PGP authentication.

An other thing that needs to be understood is that IRLP is a global network and other countries outside the US do not have the same "rules" as the US FCC Part 97.  I clearly remember a discussion back in 2000-2002 about the headaches that another country (it may have been Australia I don't remember) had to go through to allow IRLP to be used at all.  One very large selling point to their government agency was that there was a radio on the other end and there was a licensed amateur operating the radio.  It would be pretty hard for some non amateur to just hop on the network with the PGP authentication unlike another amateur network I know of.  I believe there was a huge concern about 3rd party traffic... FYI some countries don't support 3rd party traffic at all or have very very strict rules concerning 3rd party traffic.  For the above reasons, it is why IRLP became a globally accepted network.

And finally, those that govern/create a network create guidelines, those that join the network must abide by the guidelines if they chose not to; they are free to leave and go build their own network that is more agreeable to them.

Just because we can cross band, cross mode, cross network, transcode, translate, bridge, conference does not mean that we should.

73
Jon
K1IMD
Nodes: 448, 449, 487, 4474, 4689, 4677
Node Built: 448, 449,487, 436, 406, 4474, 4680, 4819, 4677, 4689, 4878, 4411, 4309

On 1/12/2020 19:47, Phil Zocco wrote:
That is part of the reasoning I had with rebuilding my node to the latest version of Debian: beautiful audio and no Echolink. In all my years of IRLP (almost 18 years), audio is just great.

I thought about EchoIRLP but I had enough of listening to shitty audio. RF in. RF out. Radio by radio.

These are the IRLP rules. Love 'em of leave 'em.

And thanks to VE7LTD and ALL involved to keep IRLP as it should be.

73,

Phil N1BOW
Node 5960
AMT MP 113.6
Niantic, CT USA Earth


-----Original Message-----
From: IRLP@irlp.groups.io [mailto:IRLP@irlp.groups.io] On Behalf Of AG0N-3055
Sent: Sunday, January 12, 2020 6:37 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] PGP Key ring key problem



On Jan 12, 2020, at 15:12, David McGough <kb4fxc@...> wrote:

Intentionally pulling keys from any network with no notice WILL NOT fly in today's world.
It certainly will fly.  Those who built the network, and those who over the years have joined the network did so, knowing that ONLY IRLP nodes will be attached to our IRLP network with the quality that IRLP promises.  Having listened for hours many times to an experimental reflector where IRLP, Echolink, and Allstar VoIP networks are interconnected, I can only say that the audio quality that comes from that system is precisely the reason that other systems are not allowed on normal reflectors.  It�s also why experimental reflectors came to be.  When you connect to one, you know that other nodes may not subscribe to the higher qualities and control found with IRLP.

Gary - AG0N







backup_for_reinstall

Brian Alexander
 

I would like to run backup_for_reinstall as a cron job every month or so and then gather the tgz with scp from another host. However, backup_for_reinstall is an interactive script on my release of the software. This is not really a problem, as I can feed it the input it expects. I am wondering whether it continues to be interactive in most recent releases and whether it will likely always be so.

Brian VA3AZA


Re: PGP Key ring key problem

Phil Zocco
 

That is part of the reasoning I had with rebuilding my node to the latest version of Debian: beautiful audio and no Echolink. In all my years of IRLP (almost 18 years), audio is just great.

I thought about EchoIRLP but I had enough of listening to shitty audio. RF in. RF out. Radio by radio.

These are the IRLP rules. Love 'em of leave 'em.

And thanks to VE7LTD and ALL involved to keep IRLP as it should be.

73,

Phil N1BOW
Node 5960
AMT MP 113.6
Niantic, CT USA Earth

-----Original Message-----
From: IRLP@irlp.groups.io [mailto:IRLP@irlp.groups.io] On Behalf Of AG0N-3055
Sent: Sunday, January 12, 2020 6:37 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] PGP Key ring key problem



On Jan 12, 2020, at 15:12, David McGough <kb4fxc@...> wrote:

Intentionally pulling keys from any network with no notice WILL NOT fly in today's world.
It certainly will fly. Those who built the network, and those who over the years have joined the network did so, knowing that ONLY IRLP nodes will be attached to our IRLP network with the quality that IRLP promises. Having listened for hours many times to an experimental reflector where IRLP, Echolink, and Allstar VoIP networks are interconnected, I can only say that the audio quality that comes from that system is precisely the reason that other systems are not allowed on normal reflectors. It�s also why experimental reflectors came to be. When you connect to one, you know that other nodes may not subscribe to the higher qualities and control found with IRLP.

Gary - AG0N


Re: PGP Key ring key problem

Gary - AG0N
 

On Jan 12, 2020, at 15:12, David McGough <kb4fxc@...> wrote:

Intentionally pulling keys from any network with no notice WILL NOT fly in today's world.
It certainly will fly. Those who built the network, and those who over the years have joined the network did so, knowing that ONLY IRLP nodes will be attached to our IRLP network with the quality that IRLP promises. Having listened for hours many times to an experimental reflector where IRLP, Echolink, and Allstar VoIP networks are interconnected, I can only say that the audio quality that comes from that system is precisely the reason that other systems are not allowed on normal reflectors. It’s also why experimental reflectors came to be. When you connect to one, you know that other nodes may not subscribe to the higher qualities and control found with IRLP.

Gary - AG0N


Re: PGP Key ring key problem

David McGough
 

Dear Dave, K9DC,

I don't think I've previously talked with you. However, I have some comments. My e-mail box is full of messages from angry, innocent HamVoIP / IRLP users.

Intentionally pulling keys from any network with no notice WILL NOT fly in today's world. There is already established legal precedent in that regard, specifically in the ham radio world.
Think about the ramifications if your unannounced action had crippled IRLP nodes or networks during an emergency?

HamVoIP does not condone nor support any groups attempting to "harvest" IRLP nodes or keys. If some unscrupulous persons attempt to obtain keys, claiming they purchased hardware where they did not, we have no knowledge of nor condone those activities.  However, if this is all about purchasing something, there is a really simple solution: IRLP should just charge an acceptably large fee to obtain or transfer a key to a different call sign! This is a simple problem to solve!

I am hopeful that IRLP REFLECTOR owners who had ANY problems with known HamVoIP users will contact me directly (kb4fxc .at. gmail.com). I'd like to hear more details about who was causing problems and what kind of problems??  Was it not possible to simply block those individual IRLP nodes??

While I realize legacy policies may exist, I'm a bit baffled as to why cross-linking between networks is of any significance at the individual node level? The HamVoIP software DOES NOT by default provide an automatic gateway mechanism. Bridges between networks can only be established or allowed by the node owner / control-op.  Easily enough, this similarly could be done with stock IRLP hardware.

Having been a ham for almost 40 years, I firmly believe in keeping the RADIO in ham radio. However, we ALL need to realize that this year is 2020. It is not the world of 2000. Nor the world of 1980.  Laws regarding ham radio have changed and been relaxed globally. We all must focus on the future, evolving as changes happen, otherwise we'll end up simply as pages of history.


73, David KB4FXC


Re: resolv.conf

Charlie Wa2gug
 

I'll get n2wro to log in and check the error. He does it for a living. I learned along time ago when to resort to a pro. I'll also have him check the name servers.


Charlie wa2gug
ARRL FIELD INSTRUCTOR, VE



-------- Original message --------
From k9dc <Dave@...>
Date: 01/12/2020 13:42 (GMT-05:00)
To IRLP@irlp.groups.io
Subject Re: [IRLP] resolv.conf



Well, it won’t work until you fix TCP 15425. So something is amiss in your router. Are all ports outgoing allowed?  Did DNS pass okay?  DNS is required to update the status page, but your node has been gone for a long time.

http://status.irlp.net/?nodeid=4827

-k9dc



> On Jan 12, 2020, at 13:34, Charlie Wa2gug <wa2gug@...> wrote:
>
> Dave,
>
> This is the only error I get :
>
> Performing INBOUND UDP and TCP Port Forwarding Test
> Detecting Incoming IP = 24.148.124.200
> Testing TCP and UDP ports .. done.
>
> -----------------------------------------------------------------------------
> TEST No. 2a REPORT - TCP ERROR - TCP port 15425 is NOT forwarded
>                                            correctly.
> Waiting 4 seconds .... done.
> TEST No. 2b REPORT - UDP PASS - UDP ports 2074-2093 are forwarded correctly.
> TEST No. 2c REPORT - EchoLink UDP ERROR - The following UDP port(s):
>  5198  5199  is/are not forwarded correctly.
>
> Can't find any thing wrong in Fortigate router.
>
> My node is 4827
>
> On 1/12/2020 13:25, k9dc wrote:
>>> On Jan 12, 2020, at 06:13, Charlie Wa2gug <wa2gug@...>
>>>  wrote:
>>>
>>> Guy's finally cleaning up the node. I noticed the node was not on the active list. I checked the resolv,conf. I do have 2 name servers in it. I'm using google 8.8.8.8,8.8.4.4
>>> Any ideas?
>>>
>> What is troubleshoot-irlp telling you?  Also what is your node number?
>>
>> -k9dc
>>
>>
>>
> --
> Charles L. Alfano
> WA2GUG
> ARRL VE, Instructor
>
>
> <wa2gug.vcf>





Re: resolv.conf

k9dc
 

Well, it won’t work until you fix TCP 15425. So something is amiss in your router. Are all ports outgoing allowed? Did DNS pass okay? DNS is required to update the status page, but your node has been gone for a long time.

http://status.irlp.net/?nodeid=4827

-k9dc

On Jan 12, 2020, at 13:34, Charlie Wa2gug <wa2gug@...> wrote:

Dave,

This is the only error I get :

Performing INBOUND UDP and TCP Port Forwarding Test
Detecting Incoming IP = 24.148.124.200
Testing TCP and UDP ports .. done.

-----------------------------------------------------------------------------
TEST No. 2a REPORT - TCP ERROR - TCP port 15425 is NOT forwarded
correctly.
Waiting 4 seconds .... done.
TEST No. 2b REPORT - UDP PASS - UDP ports 2074-2093 are forwarded correctly.
TEST No. 2c REPORT - EchoLink UDP ERROR - The following UDP port(s):
5198 5199 is/are not forwarded correctly.

Can't find any thing wrong in Fortigate router.

My node is 4827

On 1/12/2020 13:25, k9dc wrote:
On Jan 12, 2020, at 06:13, Charlie Wa2gug <wa2gug@...>
wrote:

Guy's finally cleaning up the node. I noticed the node was not on the active list. I checked the resolv,conf. I do have 2 name servers in it. I'm using google 8.8.8.8,8.8.4.4
Any ideas?
What is troubleshoot-irlp telling you? Also what is your node number?

-k9dc


--
Charles L. Alfano
WA2GUG
ARRL VE, Instructor


<wa2gug.vcf>