[GTER] Suporte Delegated-IPv6-Prefix - RouterOS

[Marcelo Gondim]

Buenas,

É corrigiram o bug introduzido na 6.43 que parava o IPv6 de funcionar em 
clientes com roteadores diferentes de RouterOS.

Agora sim.  :)  só falta liberarem uma versão que funcione o 
Delegated-IPv6-Prefix via radius pra PPPoE. :)

Em 18/10/2018 11:29, Eduardo Rigler escreveu:
> 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