YCS268 servidor Fusion

Entrou em funcionamento à já uns meses em versão teste o novo servidor YCS para a rede Fusion. Este servidor permite o uso em exclusivo de equipamentos Fusion e dos repetidores DR2-X da Yaesu.

Portugal tem de momento um único repetidor deste modelo, situado na Serra de S.Mamede e que permite o acesso usando o DG-ID correspondente.

 

Abaixo publicamos a tabela e a configuração do servidor, no primeiro bloco estão as ligações internacionais (poderemos adicionar mais a pedido), no segundo bloco estão a ligaçoes com bridge a outros sistemas, DMR e DSTAR.

 

 

 

Os DG-ID 90, terminar o estático, e 99, Parrot, são comuns a todos os YCS’s

 

Qualquer falha notada ou questão agradeciamos nos informassem.

 


 

 

Registos DMR – melhor explicado

 

Tèm surgido dificuldades nos registos novos ou nas validações de utilizadores já com ID feito no antigo ham-digital.org e que agora dadas as possibilidades divulgadas numa primeira fase tem dificuldade em validar a sua entrada na RadioID.net.

 

Como uma imagem vale mais do que mil palavras deixo aqui as diferenças encontradas entre quem quer se registar pela primeira vez e quem já é detentor de ID.

 

Comecemos então por um novo registo na rede DMR (também válido para DSTAR). introduza no seu browser o seguinte endereço: https://www.radioid.net/ a partir dessa página sigam as imagens abaixo.

 

 

 

Passaram então à fase seguinte.

 

Para os novos registos

Esta página tem a escolha para os novos registos e para os que já o têm vindos do ham-digital.org, no caso de novo registo deve escolher a tecla Signup e preencher os dados solicitados. Após validar o “Captcha” e premir “Create Account” ser-lhe-á enviado um email para a conta que identificou na caixa. Se acaso não o receber num intervalo de 1H verifique a sua caixa de SPAM. Esse email serve para verificar se é o utilizador identificado e dará acesso a poder então fazer o seu registo, para isso precisa de cópia da sua licença em formato digital.

 

Para quem já tem um ID feito na ‘ham-digital.net’

 

Para quem usa screen reader, fica aqui o link para a validação de dados, deve usar o seu indicativo em maisculas e o mesmo email com que se registou pela primeira vez: RadioID – Login,
Se acaso o email que introduziu não corresponder terá que solicitar ao suporte a validação de um novo email, deve adicionar copia do CAN, o link para tal: RadioID – Support

Deve escolher ‘General Support’ e explicar o pedido de alteração, no fundo da página à esquerda está um “captcha” com uma caixa onde deverá marcar só com o rato, não é um gerador de letras ou simbolos é só mesmo uma caixa de validação.

**********************************************************

Para os detentores de um DMR ID, e conforme visualizado na imagem acima, a caixa é outra, devem utilizar o mesmo email que usaram aquando do vosso registo DMR. Se acaso for o correto irão receber uma password provisória que dará acesso  à vossa àrea, se for recusado, porque o email não condiz com o feito no vosso primeiro registo, poderão colocar um Ticket no suporte da RadioID ou mais rápido e sem tanta confusão fazer-nos chegar a conta de email que querem ver anexa  à conta RadioID, através do email team.dmr.pt@gmail.com. A imagem abaixo é em exclusivo para esses utlizadores já com registo feito no anterior sistema.

 

 

 

Esperemos que estas imagens sejam uma ajuda, relembramos que qualquer duvida poderá e deverá ser enviada para team.dmr.pt@gmail.com

 

 


Antigo artigo acerca das mudanças

 

 

Anúncio atual! (em 10/11/2020)

 

Após cerca de 10 anos, 2 mudanças de sistema de servidores, quase 80.000 registros e muito trabalho de uma ótima equipe de administração, o nosso sistema de registo irá ser encerrado, o sistema é antigo e precisaria de muitas mudanças e atualizações.

 

O front-end da Web é um HTML antiquado, o sistema operacional não recebe mais patches de segurança desde Novembro e não deve ser usado para armazenar dados pessoais.

Portá-lo para uma nova plataforma com uma versão real do Linux custaria muito tempo e esforço.

Com uma mudança para uma nova versão do sistema operacional, este traria versões atualizadas das linguagens de script e os primeiros testes confirmaram que muitas coisas mudaram, tornaram-no incompatível e quase todos os scripts precisariam de ser ajustados e testados.

Não quero investir esse tempo, em vez disso decidi misturar o sistema com o segundo sistema de registro DMR que temos no mundo, o RadioID.net no Canadá.
Esta é a solução mais fácil e quase pode ser feita fechando um sistema e abrindo o outro.
No passado, já provámos a compatibilidade quando um sistema falhou por um tempo.
Os dados são paralelos nos dois sistemas, os procedimentos de registro, as regras, tudo é parecido ou até igual.
Cooperamos e compartilhamos os dados básicos desde que os sistemas existem.

 

A mudança para esse sistema está prevista para 18/19 de Dezembro.

  • register.ham-digital.org deixará de aceitar solicitações de registro as 23:59H 18 de Dezembro

Depois disso, trabalharemos nas últimas solicitações abertas e limparemos tudo.

  • RadioID.net começará a aceitar novos registros as 00:01H de 19 de Dezembro da Europa e de África, faixa MCC 2xx e 6xx.

 

Isto não vai influenciar as redes, todos podem usar como antes.
Novos utilizadores encontrarão um novo sistema de registro, mas como a maioria deles não usava o antigo antes não se aperceberão da mudança.

 

Há uma mudança importante para os utilizadores existentes no nosso sistema:

 

 

O RadioID.net permite que utilizadores registados mantenham os seus próprios dados numa área de autoatendimento.
 – Pode alterar quase todas as informações, exceto DMR-ID, país e indicativo.

Quem quiser usar estes recursos precisa de uma conta neste sistema.

Normalmente para obter uma conta é o mesmo procedimento que no anterior sistema, fornecendo uma cópia do documento de licença etc.

Para facilitar o trabalho dos utilizadores que já se registaram no nosso sistema implementámos uma forma que simplifica o processo.

Quando faz o login no RadioID.net com exatamente o mesmo endereço de e-mail que usou no registo inicial no nosso sistema, o sistema vai perceber isso e enviar um e-mail de verificação para confirmar a sua conta. Com o e-mail confirmado pode fazer o login, definir uma senha e alterar as suas configurações pessoais, como o seja o endereço de e-mail, nome visual ou nome pessoal.

 

Tudo feito!

 

Os processos informáticos podem às vezes pregar partidas, esta data prevista pode sofrer alteração imprevistas. Pelos meios possíveis de informação informaremos se algo tiver decorrido menos bem neste processo.

A coordenação dos ID’s 268xxx continuarão a ser geridos por nós.

 

DMR UK e G4KLX Jonathan Naylor – Fact Check

Tendo como objectivo retirar rumores do que muito se tem falado nestes últimos dias.

A 25 Nov 2020 13:59:57 GMT Jonathan publicou este documento, isto após o Team mundial ter removido a licença ao BM UK

 

«…

DMR, after D-Star, is the most political of the digtial voice modes. Unlike the other modes, most DMR systems connect to a centralised server, known as a “master” and that is responsible for all of the talk group routine, personal calls, and position data interpretation and forwarding. There are three main centralised systems: BrandMeister, DMR+ (known as Phoenix in the UK), and TGIF.What these systems have in common is that they are closed source. This is not good for the amateur community. There were mutterings about them having signed NDAs with Hytera and Motorola to get details of their internet connection protocols, which may or may not be true. Even if true, why not make the non-NDA parts of the source code open?In the commercial world, digital voice repeaters, be they for DMR, P25, NXDN, or dPMR have limited abilities within themselves for call routing. They do include CPUs of course, but for anything other than simple point-to-point links, they are useless. This limitation is fine for what they were originally designed for, small centrally controlled networks, with or without a dispatching console function. The YCS system for System Fusion is looking to do the same for YSF and that is why I oppose it.This model of a centralised control structure carried through to the amateur DMR networks. In its simplest form, a repeater would simply have a point-to-point network connection to the master and things would be fine. Even with a semi-distributed system, with one or more master per country, there is still some central control of the system with the power to overrule the decisions made at the local level. Such central control is also not conducive to supporting each countries requirements, and leads to much used functionality being arbitrarily removed. In the extereme case the countries master may also be removed. When such things happen you have to ask from where did they derive their authority? Who voted for them? Who made the decision and how do they know that it is correct? In the amateur world we have gone beyond having dumb repeaters. Most MMDVM systems for example have a Raspberry Pi or similar running the system, and have the potential to provide a lot of local processing power which can be used for more complex tasks than simply routing traffic over a point-to-point link. Many sysops expressed the wish to be able to have access to multiple masters, simultaneously, and hence the DMR Gateway was born in 2017. It does complex call routing, and almost everything else, bar the position data interpretation. In some quarters this development was opposed. I believe that the sysop should have the choice on how to route their traffic and so development went ahead and it has been enhanced since. It has been a huge success. I think that the time has come to look at having an open source, non-centralised, DMR network. A network where no one person or group has control. We already have the beginnings of this with the HBLink and with XLX projects. If more people get involved with these projects then they will grow and offer more features as time goes on. Some may say, what about integration of commercial repeaters like Hyteras and Motorolas? There is already a program available that converts the Hytera repeater protocol to the protocol used by the MMDVM, and integration of Motorola repeaters is possible all be it with a number of programs in series. Maybe someone will rationalise this into something simpler. Things are already moving on this, and I hope that in the future we will see such systems appear and then DMR will be free of the tyranny of what we have now. Sysops and their users are sovereign and should not be dictated to by anybody (the same goes for software developers 🙂 ).

Jonathan G4KLX

…»

 

O que ele não disse.

 

 

Diversas informações rolam pelos grupos sociais, umas são reais a maioria é falsa ou tendenciosa. A publicação do Jonathan Naylor é real mas partindo de quem parte só pode ser uma alucinação, fala de democratização quando ele próprio removeu da aplicação MMDVMHost a ligação a rede BrandMeister que muitos usam à anos, em alternativa e tendenciosa, obriga os utilizadores a usarem a aplicação DMRGateway, tem como vantagem o poder usar múltiplas redes, alias este aplicativo já existe à 3 anos, mas devido a dificuldade de utilização nunca teve “muita saída”. Usa para seleção das múltiplas redes uma função chamada TGRewrite, ou seja e dando como exemplo:

 

9268 – uso do tg 268 na rede Brandmeister
8268 – uso do tg 268 na rede DMR+
7268 – uso do modulo D do XLX268, e outras

 

Também e sobre esta aplicação, no “sample” de configuração esqueceu-se que o aplicativo ao ser usado na rede BM os utilizadores tem que deter a liberdade de usar o TG que quiserem, por esquecimento ou tendência deixou esse sample como enviando para todos os TG’s e recebendo sempre no 9, isto é viável para uso pessoal num hotspot, impraticável para uso em repetidor.

 

Agora sou eu que pergunto! Foi um esquecimento??.
Coloquei um post request alterando o ficheiro de configuração e após uma semana ele aceitou-o, talvez contrafeito, mas o Github é publico e mesmo que não o aceitasse muitos iriam ver o motivo da alteração que estava explicado no PR.

 

Esta dificuldade de uso e de configuração da aplicação, levou a uma fraca utilização da mesma, existem colegas ligados em DMRGateway que nem o sabem, nunca usaram e desconhecem para o que serve.  Como a aplicação não é usada a rede DMR+ perde também esses utilizadores, solução! em parceria com o sysop UK e que o levou à demissão pelo team mundial, fazer bridge dos tg’s que achassem mais interessantes para ligação na rede DMR+ UK mais conhecida por Phoenix. Acontece que a rede tem regras, mesmo sendo sysop não tem o direito de usar TG’s de outros países que não o dele sem autorização prévia dos respetivos sysops, quando confrontado pelo Team apelidou-os de “ditadores” e “fascistas” quando afinal o único errado era ele.

 

Se a rede DMR+ fosse interessante não precisava de publicidade!? Se a mesma rede fosse completamente livre, como o é a rede BrandMeister, poderia ter o mesmo número de tg’s não necessitando para nada dos da outra rede. Como essa não é a realidade do universo DMR+ faz-se bridge de grupos de conversação de outros países e introduz-se na dita esses grupos aliciando assim utilizadores. É uma questão política e publicitária.
Portugal tem desde o início da rede DMR em 2015 um DMR+, atualmente chama-se IPSC2, sendo ele livre e estando disponível para todos, inclusive os que dizem desconhecer, se analisarem a lista de IPSC2 no pi-star encontram Portugal, mas nunca lá vi ninguém.  A rede em si já evoluiu, mas pouco ou nada, a política de quem a criou era ter em DMR o que já existia em DSTAR, um repetidor + uma ligação + um reflector, ou seja uma rede feita para se usar os reflectores existentes ou atribuídos ao pais, concordo que é a forma mais fácil de usar o DMR, evita o TG (grupos de conversação) não precisa de slots, os reflectores só operam em slot2, e não era preciso construir um codeplug, ou em português, ficheiro de configuração do rádio. Isto significaria que afinal o DMR era um DSTAR e que o facto de ter 2 slots não serviria para nada. A liberdade que os utilizadores têm na rede BM de usarem o TG que lhes apetece, e estando livre, ou seja não ouvindo por lá ninguém, dá uma possibilidade que mais nenhuma rede DMR dá. A interligação, a tal centralização que o Jonathan fala dizendo que deve acabar, se acabar não há interligação! Então falo com quem??, fico limitado aos do meu país?? Esta ideia só pode ter surgido de alguém que vive numa ilha e que aprovou o Brexit, deve ser essa a ideia. Para quem fala em democratização das redes parece não perceber que uma rede é uma reunião de vários ‘nós’ interligados por alguma forma, que não é o que acontece na rede DMR+ em que as interligações possíveis são as do núcleo central a que junta a possibilidade de 2 masters chamados de ‘vizinhos’. Portugal tem como “vizinhos” os masters 724 – Brasil e 214 – Espanha, no entanto não temos nenhuma ligação com Espanha, ficando só disponível o TG 214 distribuído pelo “núcleo central” que o Jonathan parece odiar.

A rede BrandMeister é, até ao momento, a única rede DMR que permite ao utilizador a liberdade de através dessa mesma rede usar o grupo de conversação que entender bem como usar as diversas funcionalidades que a rede oferece sem ter que solicitar autorização seja para o que for e estando em que parte do mundo estiver, ressalvo neste comentário o facto de alguns proprietários de repetidores poderem aceitar ou não o uso de alguns grupos de conversação no seu material.

  • Como já foi por diversas vezes informado a responsabilidade da gestão dos repetidores é dos proprietários, cabendo a eles o melhor interesse ao grupo de utilizadores que o usem. Também neste sentido, num repetidor de uso comum o acesso é publico no entanto e por falha de legislação o que passa da RF para meio informático não está legislado nem cá nem em nenhuma parte do mundo, à autoridade reguladora compete o controle do espectro radioelétrico.

  • Ainda que o facto de haver esta liberdade ela não simboliza que tudo seja permitido, como as tais bridge’s não autorizadas e não conhecidas pelos responsáveis dos países, esta “autorização” não será o termo correto mas sim o “dar a conhecer” isto para evitar que quem o faz erre e que esse erro venha a prejudicar meio mundo e leve à perda de tempo para se localizar a origem. Desde a entrada da aplicação HBLink usada por quem pensa que aquilo é uma alternativa seja ao que for que o número de “loops” na rede mundial tem levado em certas alturas a que a atividade WW – 91 seja interrompida por esses dispositivos mal configurados, estes problemas tem também levado ao uso de ferramentas para “bloquear” esses dispositivos de entrarem nas redes primárias dando assim informação ao sysop responsável da tentativa e se da parte interessada houver um real desejo de aprendizagem e de teste entrar em contato com esses sysop’s solicitando o que for necessário. Daí nascer então a tão difundida informação de “ditadores”, que os testes de asneiras de um não prejudiquem 100.000, é esse o objetivo.

Para todos os detratores seja do que for, há quem ande por aí só para ser do contra não interessa o que desde que se oiça a ele próprio, as redes digitais são o emprego de um rádio por um radioamador em que ele escolhe com quem deseja manter comunicação, não sendo imposta nenhuma regra para que o possa executar, o facto de se usar a internet como “propagação” é o meio usado, há quem espere pela queda de meteoritos para poder fazer um contacto, há quem use a Lua como meio de comunicação e salto planetário, todos tem algo em comum, um radio uma antena e uma licença de amador. Todos os outros dispositivos possíveis de usar são addon’s e evoluções que são os objetivos que muitos pretendem alcançar quando vieram para o mundo do radioamadorismo. Ouvi recentemente um comentário acerca de, o uso do telemóvel em DMR não é radioamadorismo, mas se usar o mesmo telemóvel para uma ligação IRLP nos 80 mts já é radioamadorismo? ainda não se sonhava com redes digitais e o IRLP era rei!

 

Em conclusão. Estas “guerras” de redes a nós não nos dizem respeito, devemos usar aquilo que mais prazer nos dá e que melhor proveito tenha seja na comunicação seja no desenvolvimento de novos conhecimentos, quando ele fala de opensource esqueceu que o DMR+ é closed, elas só são fechadas pelo facto de sendo uma rede universal alguma grande empresa poder servir-se do trabalho desenvolvido pelos amadores para amadores, relembro que nem a Motorola que se afigura como os maiores tem a possibilidade imediata de tal realização. Veja-se o caso do protocolo DSTAR fonte aberta (opensource) e o aproveitamento pela parte da ICOM na realização e implementação de equipamentos com um protocolo publico. Yaesu e o System Fusion, protocolo fechado e só disponível para eles. Futuro M17, a criação de equipamentos para a grande maioria é impossível, a minitaturização dos componentes é obstaculo para muitos,  a ser alcançado esse objetivo será alguma empresa/fábrica a fazer o desenvolvimento, isto porque as fontes são publicas e muito embora a licença GPL a protega do uso comercial há sempre forma de contornar o sistema.

 


 

 

 

 

 

 

Ataque informático ou ignorância….

Update desta situação:
O colega em questão contactou-nos na tentativa de compreender as razões do BAN. Foi-lhe explicado os motivos que levaram a tal ação da qual o colega diz não ter tido consciência de tal acto.
Após uma longa conversa ficou decidido o levantamento da sanção ficando o colega com a informação de que para qualquer duvida futura ou problema surgido deve contactar-nos e não transformar as suas dúvidas em análises publicas.
Havia um diferendo à 12 anos entre este colega e um dos gestores da rede que se espera ter sido desta sanado e que venha a nascer uma amizade após este conflito.

 

 

Obrigado João Vasco – CT1GNR por finalmente ter seguido o caminho correcto e assim ter solucionado o seu e nosso problema, não é objectivo da gestão diminuir o número de utilizadores, antes pelo contrário, o objectivo é o crescimento da rede mas saudável.

 

Vários repetidores “hackeados” no dia 12

 

Foi-nos solicitado por uma Associação a verificação do repetidor deles que tinha deixado de estar ligado na rede. Após análise verificámos que um utilizador inibido de usar a rede nacional DMR pela sua postura e comportamento usou indevidamente ID de repetidores e de diversos utilizadores na tentativa de conseguir falar na rede.

Esta ação levou a que vários repetidores ficassem bloqueados, por total desconhecimento das implicações e conhecimentos de informática, dando como resultado a publicaçao e um pedido da nossa parte. 

Sendo que o radioamadorismo é feito de experienciação e que a mesma deve ser apoiada solicitamos a quem não esteja muito confortável neste novo mundo, que é a informática, a que primeiro questionem e apresentem os vossos projectos, assim poderão ser evitados erros como o acontecido ontem.

O utilizador em causa, descoberto pelo IP de ligação, provocou a paragem de 6 repetidores e usou indevidamente 23 ID’s de terceiros sem o seu consentimento, é pois esta a postura de tal cidadão.

 

 

 

 

Solicitamos uma vez mais a que alterem a password default, mesmo não tendo um hotspot pelo menos inibem que algém externo use o vosso ID num hotspot. Este pedido aplica-se pois a todos os utilizadores, o facto de não terem um Hotspot, como podem ver abaixo na listagem os ID’s usados, permite que outro qualquer o possa usar usando a password default do sistema.

 

 extrato do log do Master.

 

May 12 03:30:13 hamdmr Master 2682[72735]: Connection of MMDVM Host system 268401402 (83.132.80.155) 

 

O utilizador 2684014 é o CT1GNR – João Vasco

 

Neste mesmo dia usou os seguintes ID sempre do mesmo IP:

 

May 12 10:45:34 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268301 (83.132.80.155) 
May 12 10:46:50 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268300 (83.132.80.155)
May 12 10:49:43 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268206 (83.132.80.155)
May 12 10:51:16 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268209 (83.132.80.155)
May 12 10:57:50 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683003 (83.132.80.155)
May 12 10:59:44 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683004 (83.132.80.155)
May 12 11:01:28 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683005 (83.132.80.155)
May 12 11:02:44 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686003 (83.132.80.155)
May 12 11:05:28 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686000 (83.132.80.155)
May 12 11:08:30 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686001 (83.132.80.155)
May 12 11:09:52 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686002 (83.132.80.155)
May 12 11:11:48 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686003 (83.132.80.155)
May 12 11:12:52 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686004 (83.132.80.155)
May 12 11:14:58 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686006 (83.132.80.155)
May 12 11:19:13 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686007 (83.132.80.155)
May 12 11:20:44 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686008 (83.132.80.155)
May 12 11:23:50 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686012 (83.132.80.155)
May 12 11:36:02 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686013 (83.132.80.155)

May 12 11:37:00 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686014 (83.132.80.155)
May 12 11:38:48 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686015 (83.132.80.155)
May 12 11:40:50 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686016 (83.132.80.155)
May 12 11:43:19 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686017 (83.132.80.155)
May 12 11:44:29 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686018 (83.132.80.155)
May 12 11:45:54 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686019 (83.132.80.155)
May 12 11:48:26 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686020 (83.132.80.155)
May 12 11:49:34 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2686021 (83.132.80.155)
May 12 20:15:09 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683133 (83.132.80.155)
May 12 21:43:38 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268205 (83.132.80.155)
May 12 21:44:45 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268201 (83.132.80.155)
May 12 21:58:22 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 268303 (83.132.80.155)
May 12 22:04:41 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2682086 (83.132.80.155)
May 12 22:04:41 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2682086 (83.132.80.155)
May 12 22:39:08 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683206 (83.132.80.155)
May 12 22:41:01 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683206 (83.132.80.155)
May 12 22:46:37 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2682086 (83.132.80.155)
May 12 22:53:30 hamdmr Master 2682[72735]: Connection of Homebrew Repeater system 2683206 (83.132.80.155)

 

Além do prejuízo de levar repetidores a ficarem parados, o ultimo só foi detetado hoje de manhã por informação de um colega, conta ainda com o nosso trabalho de pesquisa e depois de bloqueio, coisa que não seria desejável se isto fosse uma sociedade perfeita.

 

 

Qualquer dúvida sobre este assunto encontramo-nos ao dispor.


 

Os refletores no BrandMeister deixam de ser suportados até ao final de 2020

 

O recurso a refletores foi implementado nos primeiros anos do BrandMeister para fornecer compatibilidade com outras redes DMR, incluido nessa funcionalidade o permitir que Hotspots baseados em refletores se ligassem ao BrandMeister.

 

Com cada vez mais países aparecendo no DMR, o formato de numeração restritiva dos refletores (4XXX) está a causar conflitos de numeração nos grupos de conversação para um número crescente de países com os quais o código MCC começa com 4.

 

As nossas estatísticas mostram que cada vez menos operadores estão a usar refletores no BrandMeister, e a demanda por novos refletores é praticamente inexistente.

 

Por todas as razões acima, a funcionalidade dos refletores será desativada até 30 de Dezembro de 2020. Após essa data, o Talkgroup 4000 continuará a fornecer a mesma função de desconexão auto-estática e o Talkgroup 9 Timeslot 2 se comportará como qualquer outro. grupo de discussão de dígitos.

 

Se estiver a usar um Hotspot DV4mini no modo refletor, consulte este post para usar o suporte como MMDVM. https://xreflector.net/Download/DV4mini/inhalt.html

 

Resolução após 12ª edição NET CT 3ªsérie

 

Pelo que foi exposto ontem e para que fique bem clara a posição de toda a equipa do DMR PT, resolvemos clarificar o que foi ontem dito.

 

 

– Foi-nos apontada a falta por banirmos uma aplicação.

 

  • Enquanto responsáveis pela rede nacional é nosso dever protege-la contra qualquer especie de mau uso, interferencias ou ataques intencionais ou não, em toda a sua estrutura, protegendo assim os interesses daqueles que ao escolherem mais este modo de comunicação o possam fazer com garantia de sucesso.

 

– Estas novas soluções, técnicamente uteis, requerem do utilizador um grau elevado de conhecimento, não só da aplicação em si bem como a sua estrutura e ainda o conhecimento de redes informáticas.

Não é de todo uma barreira, para quem queira aprender existe muito apoio, bom, e para quem o queira fazer e ache necessitar desse apoio estamos inteiramente disponiveis para ajudar, apoiar e justificar certas tomadas de decisão, que sendo erradas, possam vir a causar danos. A comunhão do conhecimento leva a um maior desenvolvimento. Ter atuações de “agente secreto” não falando nem perguntando nada a ninguém sob justificação de que “vivo num país livre” não é aceite no nosso seio e se não houve divulgação informando que iria fazer algo também não há informação da nossa parte, bloqueando sempre que necessário sem informação prévia.

 

– A aplicação DVSwitch na sua origem (https://github.com/N4IRS/MMDVM-Install/tree/master/DVSwitch-System-Builder) é uma boa solução, permite o uso do emulador para DMR, o audio em DSTAR é péssimo mas pode ser usado em conjunto com o AmbeServer.
– A aplicação Hblink na sua origem (https://github.com/n0mjs710/hblink3) é um produto que permite a criação de rotas e bridges. No BrandMeister a nível mundial só é aceite em modo OpenBridge, isto leva a que muitos “agentes secretos” a pretendam usar sem passar cavaco a ninguém usando a ligação peer como se fosse um hotspot. É possível de ser aceite cá e nos restantes masters com o pedido feito a equipa de gestão desse mesmo master. Qualquer HBLink ligado cá sem o nosso conhecimento é banido por script.

 

  • No domingo quando executámos este BAN automático, para além dos DVLink ligados também HBLink foram removidos, entre eles 4 ou 5 estrangeiros, muito provavelmente a fazer rotas de outros países para o intuito dele.
  • Ficaram ativos 10 DVSwitch, com uso do DVLink, 2 com a instalação do desenvolvedor e um HBLink que faz as rotas regionais para o IPSC2_Portugal, sem necessidade de acertos ou exclusões, só porque cumpriam as regras e não foram apanhados pelo script automatico.
  • Quem queira ligar essas aplicações já foi explicado como o fazer e estamos ao dispor para explicar/ajudar a sua utilização.

 

– A aplicação DVLink reune as aplicações acima publicadas, com a (des)vantagem do USRP permitir multiplos utilizadores, foi ontem referido que não vejo nisso um grande problema embora a nível mundial, sysop’s de outros países não o permitem.

 

 

O DVLink tem os mesmos aplicativos que o Pi-Star tem e se não fosse o facto de estar pré-configurado para uso em Espanha seria uma aplicação que apoiariamos, não o fazemos porque o facilistismo e a ignorancia dão origem a erros e como temos mais que fazer que andar a fiscalizar a rede de 5 em 5 minutos daí a razão do BAN automático que levou “agentes secretos” e utilizadores que merecem o nosso respeito a serem banidos.

 

As redes digitais existem para um bem comum usem-nas à vontade “mas não a vontadinha”.

 

Aproveito para informar a todos aqueles, que por alguma razão, não gostam do DMR BrandMeister e das regras existentes que podem sempre ir para o IPSC2, ai até tem a liberdade de por escolha de um reflector não terem o trabalho de escolha de TG’s, para os que acham que estas regras são o retorno à  ditadura, dou como conselho o abandono de redes digitais, no analógico podem sempre fazer o que quiserem sem serem identificados prejudicando somente os utilizadores desse repetidor..

 


 

DVLink, DVSwicth e HBLink regras de utilização e acesso

** VOLTE FACE SOBRE ESTA DECISÃO **

 

Numa análise mais a “frio” e porque alguns dos utilizadores da rede não podem ser responsabilizados, de forma directa, por erros produzidos quer por desconhecimento quer pela facilitismo da aplicação DVLink, resolvemos o seguinte:

 

As aplicações irão continuar a ser aceites na rede nacional, muito embora o HBLink não o seja em directo, podendo ser aceite sob condição de acesso OpenBridge e com solicitação de quais os TG’s pretendidos.

 

Em caso de utilização da aplicação DVLink e em exclusivo do DVSwicth devem, configurar a frequencia de emissão/recepção, pode ser a mesma que usam nos vossos hotspots, devem tambem desactivar o HBLink e o HBMonitor (pacotes da aplicação HBLink).

 

Só assim o DVLink será aceite e o DVSwitch funcionará como seria o objectivo do Steve – N4IRS quando o criou.

 

O não cumprimento de algumas destas permissas fará com que tanto a aplicação DVLink como qualquer hotspot com o mesmo ID do utilizador não seja aceite na rede.

 

Este problema foi despoletado por uma utilização mal configurada entre sábado e domingo com queixas do master 2141, sendo que a aplicação é espanhola e que o problema criado foi só lá deixamos para eles a resolução de um problema que é exclusivo deles e abrimos a utilização à aplicação em Portugal.

 

Com as desculpas a todos por esta situação que levou muitos a que hoje não pudessem usar a aplicação, recomendamos contudo cuidado no seu uso para ver se não vai cair noutro local que não o nosso espaço.

Na eventualidade de após as correções continuarem sem acesso será talvez sinal que tem mais dispositivos ligados com o ID, reinciem todos os dispositivos.

 

 

Qualquer duvida ou pedido, seja de ajuda seja de autorização, deverá ser enderaçado para: team.dmr.pt@gmail.com

 

BRANDMEISTER NACIONAL

 

** BRANDMEISTER NACIONAL 8 de Fevereiro **

 

Finalmente temos a rede estável e com as ultimas alterações feitas.

Desde o Natal de 2019 que a rede (leia-se software do Master) tem tido sucessivos upgrades em que cada um trazia um problema diferente. Muito se falou, muitos colegas tentaram mudança de master, que às vezes poderia resultar porque nem todos acompanham as evoluçoes havendo ainda masters com versões de Novembro de 2019. Neste momento o nosso e mais uns quantos que atualizaram esta noite, tem uma versão com novidades perfeitamente estável e espera-se que até a hora do WW (91) todos tenham a nova versão de software para que se confirme as alterações tanto a nível de transmissão intercontinental como qualidade de audio que temos notado suberba, principalmente entre modos e protocolos distintos, no caso Wires <> DMR e DSTAR <> DMR, ainda não foi confirmado entre YSF <> DMR.

 

** O QUE TRÁS A NOVA VERSÃO **

 

BrandMeister Core 20200208-0745xx

  • added dynamic jitter buffer latency to FastForward
  • added OVCM bit enrichment
  • fixed performnace / lost packets issue
  • improved session ID logging
  • improved jitter buffer behavior on missed frames

 

Adicionado um buffer que permite o controle de latência entre masters, chamado fastforward.
Adicionado o OVCM e a sua deteção
Fixada a melhoria tentada em versões anteriores e que eram uma das causas da perda de comunicação, principalmente entre hotspots
Melhorado o registo na rede
Fixado o buffer que suportava os pacotes perdidos

 

** OVCM o que é isso **

 

Open Voice Channel Mode

An Open Voice Channel Mode (OVCM) is a type of call defined by the ETSI DMR standard. In OVCM, radios not configured to work in a particular system can both receive and transmit during a group or individual call.

OVCM group call also supports broadcast calls.

Contact Type (OVCM TX) supports initiating OVCM calls, while Channel Configuration OVCM (OVCM RX) supports participating in an OVCM call. All group and individual contacts can be configured with OVCM TX and OVCM RX enabled or disabled, with disable being the default option.

When OVCM TX is enabled for a group or an individual contact, the radio indicates the call is in OVCM. Radios can be configured to allow OVCM RX. In that case, the radio can participate in calls which would otherwise require special preconfiguration. OVCM RX is configurable at the personality (channel) level.

Availability

These features are available in all MOTOTRBO conventional systems (i.e. Simplex; Single Site and IP Site Connect). They are also supported by dispatch applications which use the NAI Voice/Control interface. All that is required is an upgrade to R2.10.0. They are also well defined in the standard so should work with other vendors radios (if they support these too).

 

Numa “tradução rápida” será um pretenso modo promiscous ou digital monitor para Motorolas. Necessita de firmware que sendo Motorola é pago. Para quem o use através de hotspot MMDVM tem no modo “expert” -> mmdvmhost, de configurar no campo OVCM o seguinte:

0 = Off
1 = RX
2 = TX
3 = ambos, tx e rx

A informação que dispomos acerca desta funcionalidade ainda não é grande, assim que soubermos dentro do país ou fora de algo que ajude a entender o funcionamento sera por aqui difundido.

 

** Agradecimentos **

 

Como todos devem ter conhecimento, pelo lado dos utilizadores, os sucessivos cortes e problemas surgidos e sentidos desde o inicio deste ano tem sido devidos a implementações que não tem corrido bem, por tal facto as nossas desculpas, muito embora tal só aconteça pelo trabalho e tempo dispendido pelo suporte e pela programação.

Os meus agradecimentos e parabéns ao CT2JAY – Paulo Oliveira pela perseverança e teimosia que o levou a ter algumas discussões com o responsável por todo o código de programação do BrandMeister – Artem Prilutskiy, e obviamente a este último pelo extraordinário trabalho desenvolvido que nos permite ter esta peça de software.

 

Obrigado a todos.

 


 

XLX com suporte YSF Server

 

Entrou ontem em funcionamento  em todos os reflectores XLX nacionais, isto após testes no XLX040, o novo protocolo YSFS que permite aos utilizadores Fusion o acesso aos 26 modulos do sistema XLX permitindo assim um maior acesso a esses utilizadores. Este acesso é feito tendo configurado no pi-star qual o reflector XLX a usando o Search selecionar o modulo pretendido.

 

Descrição dos Sistemas:

 

XLX040 – Todos os módulos possíveis de utilização. Módulo “A” internacional.

 

Este XLX não comuta nenhuma ligação aquando o seu acesso.

 

XLX268 – Todos os módulos possíveis de utilização, incluídos os com ligação “bridge” a outros sistemas. Módulo “A” internacional.

Módulo A – Internacional
Módulo C – DSTAR, Fusion YSFReflector, DMR 268913
Módulo D – DSTAR, Fusion YSFReflector, DMR 268
Módulo E – DSTAR, Fusion YSFReflector, DMR 268912
Módulo F – DSTAR, Fusion YSFReflector, DMR 915
Módulo H – DSTAR, Fusion YSFReflector, DMR 268903
Módulo T – DSTAR, DMR 26863

 

Este XLX comuta ao módulo E aquando o seu acesso.

 

Todos os restantes podem ser usados em modo YSFS como no XLX040.

 

 

Agradece-se informação se algo for notado.

 


 

HotSpot Security

 

O que é o Hotspot Security no seu hotspot ?

 

Já devidamente difundido e comentado em vários locais, os Hotspots que se conectam a um servidor BrandMeister usando o protocolo homebrew ou MMDVM requerem uma senha para se ligarem.
Atualmente, a maioria usa a “senha default do servidor”, que está publicada na página wiki do BrandMeister do país correspondente. Alguns pacotes de software incluem essas senhas padrão, dispensando os utilizadores de pesquisar e inserir essa password.

É possível, e agora é altamente recomendável, que cada utilizador configure a sua própria senha personalizada no “BrandMeister Selfcare”.

 

Porque devo personalizar a password do meu hotspot ?

 

O Primeiro motivo será: – Se não personalizar uma password para o seu hotspot qualquer um pode usar o seu ID (268xxxx) para configurar num hotspot dele usando a password que existe por defeito para tal. Infelizmente isto acontece cada vez mais, daí a nossa recomendação para que todos configurassem a password a usar. A password criada é para o indicativo, ou seja é criada uma única para todos os Hotspots que o Indicativo utilize, seja um ou até 99.

O Segundo motivo: – Desde 01-01-2020 alguns masters, brevemente todos, acabaram com a password default do Brandmeister para acesso dos Hotspots, isso cria um problema a quem use outros masters para se ligar na rede, no presente caso o Master que já executa este novo processo é o 2141 – Espanha, em breve outros se seguirão. O processo de criação da sua própria password é descrito abaixo com imagens, qualquer dúvida deve ser endereçada para o team.dmr.pt@gmail.com

 

Como proceder ?

 

Primeiro, criamos uma password no seu espaço Selfcare do BrandMeister.

  1. Faça o Login em BrandMeister Selfcare
  2. No topo direito clique no seu indicativo

 

 

  1. Clique na opção “SelfCare”

 

 

  1. No fim da página ligue o botão “Hotspot Security”

 

 

  1. Uma Caixa para introdução da password irá aparecer. Entre nela o desejado e depois pressione o botão “Save”.

 

 

Aplicação pi-star

Para ver depois onde colocar a password que acabou de criar veja as imagens abaixo, são referentes ao pi-star. Abra a página do pistar, clique na “Configuração”, introduza o utilizador (pi-star) e a password (costuma ser raspberry) e depois role até ao fundo, siga as imagens.