PPPOE em AP's conecta mas depois de um tempo para de navegar

Utiliza hotspot na minha rede, mas decidi mudar tudo para PPPOE, 99% dos meus clientes utilizam AP em modo Cliente ISP com o radio discando a conexão PPPOE, a grande maioria dos clientes funciona normalmente, mas alguns deles depois de um tempo não navega mais, preciso entrar no MK derrubar a conexão do cliente, e ai sim, depois disso ele colta a navegar normalmente, já segui várias dicas aqui do fórum, como desabilitar a encriptação, mudar o tipo de autenticação apenas para CHAP, ou CHAP e PAP, mas não resolveu, meus clientes se conectam a uma RB433AH em BRIDGE.

Verificou o MTU destas conexoes

Estou utilizando 1480 em todos os clientes. Tanto MTU como MRU. Mas já tentei outros valores e o q funcionou melhor foi esse.

Qual rádio colocou no cliente?
Deixe o cliente com MTU default e altere apenas o MTU do servidor para 1492.

Dica, tire a RB do modo bridge e autentique o cliente direto na RB, descentralize a rede, mantendo cada cliente em seu POP.

Peguei vários clientes de um provedor que faliu aqui na cidade, tem AP Router, Zinwell, e Global Tronic mas todos com chipset rtl8186 se não estou enganado. Essas dicas que você passou podem resolver meu problema?

So uma coisa, se o MTU na torre é 1500, lembra quem o cabeçalho de 28b, exigindo MTU de 1472, é pra rede sem PPPoE, com PPPoE vai mais coisa no cabeçalho, seria cabeçalho com 36b, então o MTU teria que ser 1464 nos clientes.

Tem radio chato que mtu dá problema com PPPoE, noutros não, nunca estudei direito porque não uso PPPoE.
(Alias, google pra conferir se com PPPoE o cabeçalho ocupa 36b mesmo, talvez sejam 32b...)

Pra resolver isso acredito que precise ativar a opção= keepalive timeout. Deixa em 10.

Provavelmente seja clientes com problemas de CCQ ou sinal baixo.

Citação:

---

Postado originalmente por rubem

So uma coisa, se o MTU na torre é 1500, lembra quem o cabeçalho de 28b, exigindo MTU de 1472, é pra rede sem PPPoE, com PPPoE vai mais coisa no cabeçalho, seria cabeçalho com 36b, então o MTU teria que ser 1464 nos clientes.

Tem radio chato que mtu dá problema com PPPoE, noutros não, nunca estudei direito porque não uso PPPoE.
(Alias, google pra conferir se com PPPoE o cabeçalho ocupa 36b mesmo, talvez sejam 32b...)

---

pra ser mais certinho o valor do mtu seria 1454.

segue um link para uma melhor visão..

http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

Citação:

---

Postado originalmente por xXNeoXx

pra ser mais certinho o valor do mtu seria 1454.

segue um link para uma melhor visão..

http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

---

Quando passei para pppoe tive um problema com o msn e mais alguns sites em clientes com aps de marca específica, era o bendito MTU, foi só ajustar para um valor abaixo de 1500 nesses clientes, tinha um menu no rádio com várias opções e uma delas acho que era esse valor citado acima.
Interessante notar que se colocar o rádio em bridge e colocar o discador no windows o cliente funciona normalmente.


http://cdn03.under-linux.org/images/icons/icon1.png Re: PPPOE em AP's conecta mas depois de um tempo para de navegar

http://cdn01.under-linux.org/images/misc/quote_icon.png Postado originalmente por rubem http://cdn02.under-linux.org/images/...post-right.png
Tem radio chato que mtu dá problema com PPPoE, noutros não, nunca estudei direito porque não uso PPPoE.
(Alias, google pra conferir se com PPPoE o cabeçalho ocupa 36b mesmo, talvez sejam 32b...)



Tem rádio que "negocia" o MTU e se ajusta automaticamente para o cenário, (como os roteadores de borda fazem, eles enviam pacotes com diferentes tamanhos de MTU e esperam o retorno de qual tamanho é melhor), outros esperam você fazer isso manualmente, mas não sem antes te deixar com raiva. Coincidência ou não li sobre isso essa semana.

cooloverdrive o cliente com o sinal mais baixo está com -68, acho que o problema não é de sinal baixo ou CCQ, já havia atentado para isso como uma possível causa mais constatei que não era. Já vi usuários com com os mais variados valores de MTU e que dizem que o sistema funciona perfeitamente, acho que o valor do MTU deve variar de rede para rede e também em relação ao equipamento também, já pensei em deixar os AP's em bridge mais minha rede ficaria uma zona ai desisti.

Atualmente utilizo a opção Continuo no AP do cliente para o tipo de conexão PPPOE, alguém que já utiliza a opção Por Demanda acha que é melhor dessa forma ou deixo Continuo mesmo?

cara continua com "Continuo" mesmo, eu já tive problemas não com equipamentos wireless, mas com rede cabeada utp, tenho um provedor que dou suporte, e tivemos muitos problemas desse tipo com equipamentos com firmware tplink. Das marcas (multilaser, tp-link, e outras), a conexão caía e não conseguia reconectar, aí a gente desligava o roteador e ligava novamente a conseguia-se conectar, aí paramos de trabalhar com esses firmwares tp-link e passamos a usar d-link e acabou o problema.

xXNeoXx aqui a conexão não cai, continua conectado mas não navega, ai eu derrubo a conexão quando está dessa forma e o AP volta a se conectar e a navegar normalmente. Isso não acontece com todos os AP's os Zinwell não tem problema a maior parte dos problemas é com APRouter e GlobalTronic.

Mudei os clientes que estavam com problema para conectar por demanda e até o momento o problema parece ter sido resolvido, vou testar por mais alguns dias e depois reporto aqui.

Pessoal estamos implantando o PPPoe com ip´s válidos junto com ipxmac de ip´s invalidos.
Esta funcionando normal até o momento, ainda temos muitos clientes para migrar p/ pppoe. Andei lendo sobre possíveis problemas e encontrei essa regra que talvez possa ajudar com o MTU e afins, vale a pena testar.

TEM Q SER A PRIMEIRA REGRA DE "CHain" do MANGLE


/ip firewall mangle
add chain=postrouting action=change-mss new-mss=1440 tcp-flags=syn protocol=tcp tcp-mss=1441-1500

Tenho algumas dúvidas aqui sobre o que está acontecendo.
Percebi que quando um cliente autentica e pega um ip válido um outro ip válido acima dele responde a ping e aparece no IP>ADRESS LIST no adress onde teria quer ser um ip do range invalido, será que é minha versão de mk que é 2.9.51, pq em algumas rb´s com versões mais recentes fizemos a configuração igual e está funcionando certinho, em IP>ADRESS LIST o adress é ip invalido e o network é válido.

Essa versão do MK esta muito defasada, atualize todos os seus MK's para a versão mais recente. Você usa ai AP em modo ISP nos clientes ou sua rede é cabeada?
Se for AP você usa o modo de conexão PPPOE Continuo ou Por Demanda?

Olá amigo, esta noite vou atualizar meu servidor mk 2.9.51, nossa rede é Wireless.
Temos o servidor concentrador e nas torres temos RB´s em bridge.
O wireless é criptografado por WPA2 e controle por acess list, isso em 2,4Ghz, em 5,8Ghz são Rocket´s como ap´s tbm com wap2 em bridge usando nos clientes airgrid e nanoloco m5 discando o pppoe.
Hoje meu servidor começou a travar a ether local (saida p/ clientes), pra voltar a navegação tenho que desativar e ativar a placa.
Antes quando era somente controle por IP X MAC rodava liso, isso durante uns 4 anos, agora com PPPoe ta travando essa ether.
Bom vamos ver como fica depois da atualização, tenho a 3.20 p/ x86 aqui, vou coloca-la.

Opa, voltei...atualizei meu servidor para versão 3.20 e depois pra 4.17, estava tudo rodando blzinha, mas hoje tive 2 clientes (que me ligaram) que não conseguiam conectar.
Vi que eles estavam no "station" do Rkt mas não estavam logados no PPP>active conections...
Do nosso AS empurrei 2 /24 para esse servidor e no momento do problema estava com 154 clientes no "active conections".
Será que criei minha POOL corretamente, vejam:
Pool ip´s válidos: 1xx.xx.186.2-1xx.xx.187.254
Pool ip´s invalidos: 15.15.16.2-15.15.17.254.
Em PPPoe Server Max Sessions está default, devo setar algum limite ?
Desde já agradeço.