[GTER] Suporte Delegated-IPv6-Prefix - RouterOS

Thu Oct 18 11:29:41 -03 2018

Passando pra avisar que entre ontem e hoje soltaram uma nova versão.

What's new in 6.43.4 (2018-Oct-17 06:37):

Changes in this release:

*) bridge - do not learn untagged frames when filtering only tagged packets;
*) bridge - fixed possible memory leak when VLAN filtering is used;
*) bridge - improved packet handling when hardware offloading is being
disabled;
*) bridge - properly forward unicast DHCP messages when using DHCP Snooping
with hardware offloading;
*) crs328 - improved link status update on disabled SFP+ interface when
using DAC;
*) crs3xx - fixed possible memory leak when disabling bridge interface;
*) crs3xx - properly read "eeprom" data after different module inserted in
disabled interface;
*) dhcpv4-server - use client MAC address for dual stack queue when
"client-id" is not received;
*) dhcpv6-server - fixed dynamic binding addition on solicit when IA_PD
does not contain prefix (introduced in v6.43);
*) dhcpv6-server - recreate DHCPv6 server binding if it is no longer within
prefix pool when rebinding/renewing;
*) ipsec - allow multiple peers to the same address with different
local-address (introduced in v6.43);
*) led - added "dark-mode" functionality for LHG and LDF series devices;
*) led - added "dark-mode" functionality for wsAP ac lite, RB951Ui-2nD, hAP
and hAP ac lite devices;
*) led - fixed default LED configuration for SXT LTE kit devices;
*) led - fixed power LED turning on after reboot when "dark-mode" is used;
*) ntp - fixed possible NTP server stuck in "started" state;
*) romon - improved packet processing when MTU in path is lower than 1500;
*) routerboard - show "boot-os" option only on devices that have such
feature;
*) traffic-flow - fixed post NAT port reporting;
*) w60g - added "frequency-list" setting;
*) w60g - added interface stats;
*) w60g - fixed interface LED status update on connection;
*) w60g - general stability and performance improvements;
*) w60g - improved stability for short distance links;
*) w60g - renamed "mcs" to "tx-mcs" and "phy-rate" to "tx-phy-rate";

[]´s

Em qua, 10 de out de 2018 às 16:51, Marcelo Gondim <gondim at bsdinfo.com.br>
escreveu:

> Tudo porque no lab deles só tem equipamento da Mikrotik pelo que
> entendi. Entre Mikrotiks parece que funcionava mas essa não é a
> realidade do mundo. Eles deveriam ter no lab deles routers de outros
> fabricantes para avaliar como TP-Link, D-Link, Cisco e por aí vai. Isso
> para poder ver o comportamento do produto deles com produto de terceiros.
>
> Tudo que fiz foi dizer: Martins você quer acesso ao meu lab para fazer
> os testes? Você pode fazer o que quiser com a routerboard, pode socar
> outra versão, reiniciar, qualquer coisa que não vai afetar nenhum
> cliente meu.
> Ele acessou e ao tentar desconectar o cliente PPPoE de teste, o mesmo
> demorou à reconectar e aí eu disse pra ele que era um router TP-Link.
> Acho que foi aí que ele percebeu que o problema só acontecia com outros
> fabricantes de routers.
>
>
> Em 10/10/2018 12:22, Fernando Frediani escreveu:
> > Olá Gondim
> >
> > Ótima notícia. Agora conta pra gente que foi a combinação correta de
> > palavras para fazer esse Martins entender que o problema existia e era
> > real ! :)
> >
> > Acredito que apesar de ainda não contemplar a entreva dos prefixos via
> > Radius para PPP ao menos corrige este problema que não existia
> > anteriormente e não força mais ter que ficar na versão 6.42.7 ou 6.42.9
> >
> > Fernando Frediani
> >
> >
> > On 10/10/2018 08:10, Marcelo Gondim wrote:
> >> Bom dia pessoal,
> >>
> >> Consegui finalmente o objetivo. Deus é pai. kkkkkk Dei acesso ao meu
> >> lab pra eles e eles identificaram o problema. Martins atualizou a
> >> minha routerboard de lab pra 6.44beta21 e agora está funcionado.
> >> Abaixo a resposta dele pra mim:
> >>
> >> Hello,
> >>
> >> Seems that we found an issue which caused this problem between our
> >> server and specific DHCPv6 clients. Due to the fact that client had
> >> to be specific, we could not reproduce this problem right away by
> >> using, for example, only RouterOS devices.
> >>
> >> I have installed beta version with potential fix on your router and
> >> seems that everything is working properly now. Please let us know if
> >> you notice any other problems. If fix is working well, then we will
> >> include in next v6.43.x release.
> >>
> >> Best regards,
> >> Martins S.
> >>
> >>
> >>
> >> Em 05/10/2018 11:58, Marcelo Gondim escreveu:
> >>> Em 04/10/2018 19:25, Lucas Willian Bocchi escreveu:
> >>>> Gondim, eu cansei de gastar saliva com esses cara do Mikrotik. A
> >>>> qualidade
> >>>> do suporte decaiu vergonhosamente.
> >>>> Simplesmente deixa a versão funcionando lá e vai atualizando uma
> >>>> numa rb de
> >>>> teste de bancada. Hora que funcionar vc coloca em produção.
> >>>> Pra vc ter uma idéia eu tenho um script aqui que fica verificando
> >>>> atualização a cada meia hora e botei o ip do equipamento mais
> >>>> interno (que
> >>>> tem que pegar o ip da cpe) pra monitorar. A hora que ele acender
> >>>> resolveu o
> >>>> problema.
> >>> Dia Lucas,
> >>>
> >>> Fiz o seguinte aqui. Como estamos pra migrar nosso sistema pra
> >>> MKSolutions, criei um lab com uma routerboard de testes para essa
> >>> finalidade, pra testar autenticação pelo sistemas deles e tudo. Mas
> >>> enquanto o sistema não entra, estou aproveitando pra testar outras
> >>> versões do RouterOS. Quando saiu a notícia que seria possível, à
> >>> partir da versão 6.43, enviar via radius o Delegated-IPv6-Prefix
> >>> resolvi testar e foi aí que percebi 2 coisas: uma que não funcionava
> >>> o tal recurso e outra que havia parado o recurso que funcionava tão
> >>> bem. Recentemente eles falaram que esse novo recurso não funciona
> >>> com PPPoE ainda, somente via DHCP mas mesmo assim quebraram uma
> >>> coisa que já funcionava, que era o DHCPv6 PD Pool no profile / ppp
> >>> do routeros.
> >>>
> >>> Mas estou na luta aqui com eles. Uma hora eles resolvem, espero.
> >>>
> >>>>
> >>>> Em qui, 4 de out de 2018 às 19:09, suporte salvador <
> >>>> suporteinfossa at gmail.com> escreveu:
> >>>>
> >>>>> Já tentou desligar, desconectar tudo e reconectar senhor?
> >>>>>
> >>>>> Gondim ou você não conseguiu chegar na pessoa certa, ou eles estão
> >>>>> deixando
> >>>>> o problema de lado mesmo...
> >>>>>
> >>>>> Att
> >>>>>
> >>>>> Em qui, 4 de out de 2018 às 16:47, Marcelo Gondim
> >>>>> <gondim at bsdinfo.com.br>
> >>>>> escreveu:
> >>>>>
> >>>>>> Rapaz eu já perdi a paciência com o suporte da Mikrotik.
> >>>>>> O que venho há dias explicando pra eles que o que parou de
> >>>>>> funcionar é
> >>>>>> algo que já funcionava bem. Que eles quebraram com a versão 6.43
> >>>>>> que é
> >>>>>> passar o DHCPv6 PD Pool pelo profile do ppp. Isso sempre funcionou.
> >>>>>> Pra mim ainda está quebrado nessa beta que é a 6.44beta14. Não
> >>>>>> sei se a
> >>>>>> tal 6.44beta17, que ainda não aparece pra mim, eles resolveram. Eu
> >>>>>> entendi perfeitamente que o delegated-ipv6-prefix não está
> >>>>>> funcionando
> >>>>>> pra PPP via radius. Eles poderiam também ter esclarecido isso
> >>>>>> desde o
> >>>>>> início avisando que a função nova é apenas pra DHCP e não PPPoE.
> >>>>>> Mas o fato é que independente de função nova, eles quebraram algo
> >>>>>> que
> >>>>>> funcionava e nem falando pros caras, mostrando, mandei supout,
> >>>>>> configuração. Nada adiantou pra mostrar e provar pra eles que tem
> >>>>>> problema. Pelo amor de Deus.
> >>>>>>
> >>>>>> Em 04/10/2018 10:37, Fernando Frediani escreveu:
> >>>>>>> Para compartilhar com todos que estão acompanhando este tópico
> >>>>>>> segue
> >>>>>>> abaixo a última resposta que tive deles a respeito.
> >>>>>>>
> >>>>>>> Basicamente ele diz que funciona na 6.44beta17 (que
> >>>>>>> aparentemente não
> >>>>>>> está utilizando Radius no teste que ele conduziu) e que o
> >>>>>>> suporte que
> >>>>>>> foi adicionado na 6.43 é apenas para DHCPv6 server não para PPP,
> >>>>>>> porém
> >>>>>>> sem explicar bem porque quebrou a entrega de prefixos após a 6.43.
> >>>>>>> Baseado nessa premissa acredito que resta aguardar adicionarem essa
> >>>>>>> feature ao PPP.
> >>>>>>>
> >>>>>>> "I make configuration between v6.44beta17 PPPoE server and client.
> >>>>>>> Server has the same configuration as your - PPPoE client should
> >>>>>>> receive prefix from pool "POOLIPv6RESIDENCIAL".
> >>>>>>> On the right side you can see DHCPv6 client on PPPoE client
> >>>>>>> interface
> >>>>>>> which do get a proper prefix.
> >>>>>>> Forum topic that you are referring to is written to ask for
> >>>>>>> delegated-ipv6-prefix support for PPPoE. We added support for
> >>>>>>> delegated-ipv6-prefix in v6.43 but for DHCP service - not for PPP
> >>>>>>> service. Your RADIUS server authenticates PPP users not DHCP so
> >>>>>>> this
> >>>>>>> parameter will not work."
> >>>>>>>
> >>>>>>> Fernando
> >>>>>>>
> >>>>>>>
> >>>>>>> On 03/10/2018 11:01, Fernando Frediani wrote:
> >>>>>>>> Bom dia a todos.
> >>>>>>>>
> >>>>>>>> Só pra dar um feedback sobre este assunto depois de trocar alguns
> >>>>>>>> emails com eles tentando reportar o problema o rapaz que atendeu
> >>>>>>>> negou totalmente o problema, disse que "deveria ser algo local"
> >>>>>>>> e que
> >>>>>>>> "se houvesse algum problema ele seria confirmado na primeira
> >>>>>>>> mensagem" (uuhhlll !).
> >>>>>>>>
> >>>>>>>> Mesmo explicando que isso aconteceu não apenas no meu caso, mas
> >>>>>>>> com
> >>>>>>>> outras pessoas como já relatado aqui na lista, na thread no Forum
> >>>>>>>> enviada abaixo pelo Gondim como também explicando que quando
> >>>>>>>> feito o
> >>>>>>>> Downgrade para 6.42.7 sem alterar nada nas configurações volta a
> >>>>>>>> funcionar como esperado eles negam o problema.
> >>>>>>>>
> >>>>>>>> Por ora só resta permanecer na versão 6.42.7 para não quebrar o
> >>>>>>>> IPv6
> >>>>>>>> até se darem conta que o problema existe.
> >>>>>>>>
> >>>>>>>> A boa notícia é que alguém postou nessa mesma thread que na versão
> >>>>>>>> 6.44 beta 'parece' que foi corrigido
> >>>>>>>> (
> >>>>>>
> https://forum.mikrotik.com/viewtopic.php?f=21&t=139057&start=50#p689985
> >>>>>>
> >>>>> ).
> >>>>>>>> Aguardemos as confirmações.
> >>>>>>>>
> >>>>>>>> Fernando
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 20/09/2018 17:02, Marcelo Gondim wrote:
> >>>>>>>>> Finalmente o bug foi confirmado. Olha a resposta deles no fórum:
> >>>>>>>>>
> >>>>>>>>> Confirmed, I did a bit of debugging and I see what is happening -
> >>>>>>>>> the client requests a prefix from the DHCPv6 server, the
> >>>>>>>>> server says
> >>>>>>>>> "binding not found" and gives a zero second lease of prefix
> >>>>>>>>> ::/0 to
> >>>>>>>>> the client, so the MikroTik client successfully gets a "lease" of
> >>>>>>>>> ::/0, which expires after one second, and so the client
> >>>>>>>>> follows up
> >>>>>>>>> one second later to renew the lease, and every second thereafter
> >>>>>>>>> continuously.
> >>>>>>>>>
> >>>>>>>>> If I manually create the DHCPv6 binding and associate the prefix,
> >>>>>>>>> client DUID and IAID, it gets the prefix.
> >>>>>>>>>
> >>>>>>>>> Certainly a major bug - I wonder how this got through testing?
> >>>>>>>>>
> >>>>>>>>> Em 18/09/2018 14:54, Marcelo Gondim escreveu:
> >>>>>>>>>> Em 18/09/2018 12:50, Thiago Correa de Lima escreveu:
> >>>>>>>>>>> Estou postando no forum deles também
> >>>>>>>>>>>
> >>>>>>>>>>> Segue o tópico.:
> >>>>>>>>>>>
> >>>>>>
> https://forum.mikrotik.com/viewtopic.php?f=1&t=89443&p=687161#p687161
> >>>>>>
> >>>>>>>>>> Show fui lá e mandei também o problema. Não é possível que eles
> >>>>>>>>>> ainda estejam hesitando kkkkk
> >>>>>>>>>> Estou impressionado. É simples:
> >>>>>>>>>>
> >>>>>>>>>> Nas versões 6.40.9 e 6.42.7 funciona o DHCPv6 PD Pool. Basta
> >>>>>>>>>> atualizar pra 6.43 ou 6.43.1 que o problema ocorre. Volta pras
> >>>>>>>>>> versões anteriores e normaliza. Como que alguém com um mínimo de
> >>>>>>>>>> lógica não consegue perceber a sutileza do problema?
> >>>>>>>>>>
> >>>>>>>>>>> Vou fazer como o Marcelo disse e gerar o arquivo .rif e
> >>>>>>>>>>> entrar em
> >>>>>>>>>>> contato com o suporte para ver se eles dão uma atenção maior ao
> >>>>>>>>>>> assunto.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Em 18-09-2018 11:47, Lucas Willian Bocchi escreveu:
> >>>>>>>>>>>> Marcelo.
> >>>>>>>>>>>> Sobre esse teu problema mandei dois supout.rif de ambas as
> >>>>>>>>>>>> versões. Da RC
> >>>>>>>>>>>> Candidate também. Mas é como você diz, os caras são teimosos
> >>>>> demais.
> >>>>>>>>>>>> Em ter, 18 de set de 2018 às 11:38, Marcelo Gondim
> >>>>>>>>>>>> <gondim at bsdinfo.com.br>
> >>>>>>>>>>>> escreveu:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Pessoal me ajudem à reportar esse problema junto à eles.
> >>>>>>>>>>>>> Quanto
> >>>>>>>>>>>>> mais
> >>>>>>>>>>>>> gente reclamando mais eles vão se tocar que existe um
> >>>>>>>>>>>>> problema.
> >>>>>>>>>>>>> Só mandar para: support at mikrotik.com explicando o problema e
> >>>>>>>>>>>>> mandando um
> >>>>>>>>>>>>> supout.rif pra eles.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Em 18/09/2018 01:46, Fernando Frediani escreveu:
> >>>>>>>>>>>>>> Olá Thiago
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Confirmo aqui também o mesmo comportamento que você
> >>>>>>>>>>>>>> relatou com
> >>>>> a
> >>>>>>>>>>>>>> versão 6.43. Retornando para a anterior, 6.42.7 o DHCPv6
> >>>>>>>>>>>>>> volta a
> >>>>>>>>>>>>>> funcionar e as CPEs voltam a receber prefixos por Prefix
> >>>>>>>>>>>>>> Delegation.
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>