[FUG-BR] FreeBSD 10-RELEASE + IPFW + MAC Address

Segunda Novembro 10 16:26:50 BRST 2014

Boa tarde.

Desculpem reabrir este tópico, mais alguém tem alguma novidade neste
assunto?

Hoje perdi algumas horas novamente tentando atualizar o FreeBSD 9 para o
10-RELEASE e caí no mesmo problema, tanto que nem lembrava mais disso e ai
cai aqui nesta thread aberta por mim mesmo com o mesmo problema.

Enfim, agora estou migrando de NATD para in-Kernel NAT, mais o problema do
controle de MAC para Pipes configurados como Upload está o mesmo.

Será que o pessoal do desenvolvimento ficou a par deste bug?

-- 
Att.
__________________________________
Márcio Elias Hahn do Nascimento

Bacharel em Tecnologias da Informação e Comunicação - TIC
Cel:   (55) 48-8469-1819
Emails: marcioelias em bsd.com.br / marcioelias em gmail.com
Skype: marcioeliashahn em hotmail.com
FreeBSD - The Power To Serve

2014-02-14 9:47 GMT-02:00 Márcio Elias <marcioelias em gmail.com>:

> 2014-02-14 2:08 GMT-02:00 Marcelo Gondim <gondim em bsdinfo.com.br>:
>
> Em 14/02/14 00:09, Márcio Elias escreveu:
>> > 2014-02-13 15:24 GMT-02:00 Marcelo Gondim <gondim em bsdinfo.com.br>:
>> >
>> >> Em 13/02/14 11:31, Márcio Elias escreveu:
>> >>> 2014-02-12 23:59 GMT-02:00 Márcio Elias <marcioelias em gmail.com>:
>> >>>
>> >>>> 2014-02-12 23:42 GMT-02:00 Renato Frederick <renato em frederick.eti.br
>> >:
>> >>>>
>> >>>>> Em 12/02/14 23:31, Márcio Elias escreveu:
>> >>>>>> Se funcionar, antes de relatar como BUG ainda vou fazer mais um
>> teste,
>> >>>>>> excluindo e recriando a máquina virtual da versão 10, pra realmente
>> >>>>>> descartar qualquer possibilidade de erro de  configuração.
>> >>>>> Se puder virtualizar em vmware e mandar o feedback prá nós, fico
>> >>>>> agradecido!
>> >>>>> -------------------------
>> >>>>>
>> >>>> Não tenho VMWare aqui fera, soh que eu instale a versão Desktop na
>> minha
>> >>>> máquina e faça os testes, o difícil vai ser tempo pra isso.
>> >>>>
>> >>>> Se alguém tiver um ambiente que possa testar, mando o conjunto de
>> >>>> configurações/regras mínimas que estou usando pra ver se funciona.
>> >>>>
>> >>>>
>> >>> Infelizmente tenho os resultados dos testes realizados em uma máquina
>> >> real
>> >>> com FreeBSD 10-release.
>> >>>
>> >>> O resultado foi o mesmo da máquina virtualizada, não sei por que mais
>> ao
>> >>> jogar o tráfego de upload para o pipe, o cliente não navega mais...
>> >>>
>> >>> *00100  2786 1389706 divert 8668 ip from any to me in recv re0*
>> >>> *00200  1796  444771 divert 8668 ip from 192.168.0.0/16
>> >>> <http://192.168.0.0/16> to any out xmit re0*
>> >>> *00300  1621 1013920 pipe 150 ip from any to 192.168.5.18
>> >>> MAC XX:XX:XX:XX:XX:XX any*
>> >>> *--->>> 00400   534   74471 pipe 155 ip from 192.168.5.18 to any
>>  ##aqui
>> >>> tinha controle de MAC, mais testei sem e mesmo assim não foi*
>> >>> *65535 19188 6448077 allow ip from any to any*
>> >>>
>> >>> Não acredito que seja um BUG, deve ter mudado alguma coisa com o
>> FreeBSD
>> >>> 10, alguém ai tem a oportunidade de reproduzir esse teste?
>> >>>
>> >> Marcio fiz um teste aqui e deu o mesmo erro também. Mandei até um
>> e-mail
>> >> pros caras explicando. Aí fui fazer o mesmo teste entrando com as
>> regras
>> >> manualmente e acho que descobri o problema.
>> >>
>> >> Quando rodo as regras através do script não aparece o erro que dá na
>> >> hora do pipe. Minhas regras de teste:
>> >>
>> >> ipfw add pipe 1 ip from 67.xxx.89.78 to any 80 out via xn0
>> >> ipfw add pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0
>> >> ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M
>> >> ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M
>> >>
>> >> Rodando as 2 do pipe manualmente deu a mensagem abaixo que a queue size
>> >> tinha que ser maior igual à 2 e menor igual à 100. Refiz a regra usando
>> >> queue com 100 e funcionou normalmente. Existe uma sysctl que permite
>> >> aumentar o valor da queue: net.inet.ip.dummynet.pipe_slot_limit onde
>> >> posso aumentar para 128 e aí minhas regras também funcionariam. Por um
>> >> acaso não é isso que está acontecendo contigo?
>> >>
>> >> # ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M
>> >> ipfw: 2 <= queue size <= 100
>> >>
>> >> # ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M
>> >> ipfw: 2 <= queue size <= 100
>> >>
>> >> []'s
>> >> Gondim
>> >> -------------------------
>> >>
>> >>
>> > Humm, mais eu não estou configurando o pipe desta forma, estou
>> > especificando somente a largura de banda, veja como estou fazendo:
>> >
>> > ipfw pipe 1 config bw 10Mbits        #exemplo para um pipe de 10M
>> >
>> > Outra coisa é que para o meu caso não especifico portas, todo o tráfego
>> > passa por esse pipe, isso é o que uso para limitar a velocidade
>> contratada
>> > pelos clientes, por isso tenho um pipe de up e um de down pra cada
>> cliente.
>> >
>> > Será que é o mesmo caso?
>> >
>> Eu coloquei a porta específica apenas para fazer um teste, porque senão
>> poderia travar meu acesso remoto naquela VM, aí para não correr o risco,
>> fiz somente com a porta 80.  :)
>> Pro controle ficar legal é bom setar a queue que seria a velocidade / 8
>> que no seu caso daria uma queue de 1280 mas aí você precisa setar o
>> net.inet.ip.dummynet.pipe_slot_limit para 1280.
>>
>> Quando você seta o seu pipe... o que aparece quando você faz: ipfw pipe
>> show  ?
>>
>> No meu caso deu o problema porque os pipes não carregavam, não apareciam
>> no comando acima.
>>
>> []'s
>> Gondim
>> ------------------------
>>
>
> Fica assim por exemplo:
>
> [root em teste /home/sulonline]# ipfw pipe show 150
> 00150:   4.000 Mbit/s    0 ms burst 0
> q131222  50 sl. 0 flows (1 buckets) sched 65686 weight 0 lmax 0 pri 0
> droptail
>  sched 65686 type FIFO flags 0x0 0 buckets 0 active
>
> Não tenho problemas em carregar os pipes, soh em jogar o tráfego de up
> para eles.
>
> --
> Att.
> __________________________________
> Márcio Elias Hahn do Nascimento
>
> Araranguá - SC
> Cel:   (55) 48-9661-0233
> msn: marcioeliashahn em hotmail.com
>