Re: [FUG-BR] PC-BSD - mal-comportado ;)
Em Sun, 26 Apr 2009 23:06:29 -0300 josias gonçalves , conhecido consumidor de drogas (BigMac's com Coke) escreveu: > Kris Moore sugeriu passos para solução deste problema. opa, muito obrigado pelo link; vou analisa-lo para uma (eventual) proxima vez. Por enquanto, solucionei do meu (tradicional e meigo) modo: AMBOS os dvds foram pro lixo :). Devem estar bem longe, nesta hora (rss). -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free Deus, para a felicidade do homem, inventou a fé e o amor. O Diabo, invejoso, fez o homem confundir fé com religião e amor com casamento. (Machado de Assis) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW - Sequência de PIPE e QUEUE
Desculpem a ignorancia e a pergunta off-topic, mas o quem vem a ser um "proxy full" ? Trabalho com squid há uns 5 anos e confesso que nunca ouvi essa expressão fora dessa lista... -- "To err is human, to blame it on somebody else shows management potential." - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW - Sequência de PIPE e QUEUE
Marcello Barreto de Medeiros escreveu:
> Olá Nilton,
> Sem querer disvirtuar muito do tópico... mas quantas conexões
> simultâneas você costuma permitir por usuário (uso geral)?
>
> On Sun, 26 Apr 2009 21:17:07 -0200
> "Nilton Jose Rizzo" wrote:
>
>
>> On Sat, 25 Apr 2009 12:17:51 -0300, Welkson Renny de Medeiros wrote
>>
>>> Trober escreveu:
>>>
Olá a todos.
Observo que na maioria dos exemplos que rolam por aí referente à
utilização do IPFW para controle de banda utilizam "pipe 1",
"pipe 2", "pipe 3", sempre em sequência, começando em 1,
contíguos, sem intervalos (1,2,3,4,5,6,...).
Fiz um sistema de gestão de firewall, em que os rulesets de 6000
até 1 são destinados ao controle banda. Para um controle mais
fácil (adição, edição, exclusão) o número do pipe (pipe_nr) e do
queue são iguais ao do ruleset.
Por exemplo (parcial):
VARRULESTART tem valor inicial de 6000 e VARRULEGROWN é igual a 5,
incrementando a cada cliente (linha) que leio de um arquivo texto.
# Download Rules
VARRULESTART=$((VARRULESTART+$VARRULEGROWN))
$fz pipe $VARRULESTART config bw ${varBWDOWN}Kbit/s mask
dst-ip 0x
$fz queue $VARRULESTART config pipe $VARRULESTART
$fz add $VARRULESTART queue $VARRULESTART all from any to
$varBWIP
# Upload Rules
VARRULESTART=$((VARRULESTART+$VARRULEGROWN))
$fz pipe $VARRULESTART config bw ${varBWUP}Kbit/s mask
src-ip 0x $fz queue $VARRULESTART config pipe
$VARRULESTART $fz add $VARRULESTART queue $VARRULESTART all
from $varBWIP to any
Meu arquivo texto tem o seguinte formato:
STATE IPADDRESS MAC DOWN UP HOSTNAME
PROxYFULL on192.168.20.2 aa:bb:cc:dd:ee:f1 256 128
georgeyes on192.168.20.6 aa:bb:cc:dd:ee:f2 256 128
john no on192.168.20.10 aa:bb:cc:dd:ee:f3 256 128
paul yes on192.168.20.14 aa:bb:cc:dd:ee:f4 256 128
ringo yes
Se o valor de VARRULESTART for igual a 0, com incremento de 1, os
pipes e queues atuam perfeitamente em programas de P2P.
Concluí, que o problema reportado em minha mensagem[1] sobre a
anomalia do IPFW não estava relacionada à mascara[2], e sim aos
seguintes fatos:
1) O IPFW aceita para pipe e queue qualquer inteiro positivo
entre 1 e 65535, porém, desgraçadamente, em ordem, começando em
um, contíguo, sem intervalo.
2) Não há documentação sobre a ordem de inserção de pipes e
queues quanto à numeração (já li quase tudo que Luigi Rizzo
escreveu sobre IPFW e nada).
3) Esse comportamento está evidente, ao meu ver, em ipfw2.c, onde
o número do pipe é o mesmo número da posição na pilha, não
deixando o administrador escolher manualmente o número pipe (até
deixa, mas dá nessa bagunça toda).
Quem concorda? Quem descorda? De forma alguma quero criar flames,
e sim, obter a opinião de vocês, pois se for procedente, temos aí
um caso omisso na documentação do IPFW; e sistemas como WARTA e
SnowDog Firewall com regras tortas.
>>Olha tenhop dois server (4.11 e 7.1) ambos com ipfw2 e meus pipes
>> são numerados da seguinte forma:
>>10XXX Upload ( 10128, 10256, 10300, 10600, 10784, 11024, 12048)
>>20xxx Download ( 20128, 20256, 20300, 20600, 20784, 21024 e 22048)
>>
>> e funcionam perfeirtamente bem, nunca tive problemas.
>>
>> O maior problema que tenho, ainda é que os P2P geram um grande
>> numero de conexões simultanes, tendo que limitar na regra de pipe um
>> limite para conexões (limitei em 30)
>>
Saudações,
Trober
-
-
-
-
-
[1]
http://www.fug.com.br/historico/html/freebsd/2009-04/msg00488.html
[2]
http://www.fug.com.br/historico/html/freebsd/2009-04/msg00518.html
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>> Trober,
>>>
>>> Acho que esse nível de teste seria interessante reportar na lista
>>> freebsd-ipfw... o próprio Luigi Rizzo pode responder =)
>>>
>>> Se mestre Patrick tiver um tempo, pode comentar por aqui também.
>>>
>>> --
>>> Welkson Renny de Medeiros
>>> Focus Automação Comercial
>>> Desenvolvimento / Gerência de Redes
>>> welk...@focusautomacao.com.br
>>>
>>> Powered by
>>>
>>>(__)
>>> \\\'',)
>>> \/ \ ^
>>> .\._/_)
>>>
>>> www.FreeBSD.org
>>>
>>> -
>>> Histórico: http://www.fug.com.br/historico/html/
Re: [FUG-BR] IPFW - Sequência de PIPE e QUEUE
Olá! ASSUNTO 1: "ProxyFull" é um nome informal dado para a marcação ZPH (Zero Penalty Hit) dentro do Squid, permitindo que arquivos obtidos do cache sejam entregues em banda completa, e não limitada. Se um usuário da sua rede tem banda de 768kbps, ele obterá do cache o arquivo na máxima velocidade que o meio físico permitir (~100mbps, na maioria dos casos wired). Quando um arquivo é obtido do disco (TCP_HIT) ou da memória do Squid (TCP_MEM_HIT), um flag de TOS (Type of Service) é atribuído pelo ZPH. No seu controle de banda, você limitará banda para tudo, exceto para quem tiver a marcação TOS na porta 80, marcada pelo Squid/ZPH ;) Se for IPFW, use "not iptos mincost" na regra de controle de banda. Tenho vários cenários em produção com este recurso, um deles até comentado aqui na lista[1]. [1] http://www.fug.com.br/historico/html/freebsd/2009-01/msg00661.html ASSUNTO 2: Tem muita gente lá no underground ".sk", ".ru", ".pl" passando pelo mesmo problema com P2P/PIPE/QUEUE. Não compreendo os idiomas, mas vejo que depois de alguém escrever debug.mpsafenet=0, aparece várias respostas com smilles sorridentes, hehehe. Testarei isso no meu /boot/loader.conf (já que é read-only em tempo de execução), e assim que puder e reportarei à lista o resultado. Grande abraço, Trober - - - - > Desculpem a ignorancia e a pergunta off-topic, mas o quem vem a ser um > "proxy full" ? > > Trabalho com squid há uns 5 anos e confesso que nunca ouvi essa > expressão fora dessa lista... > > -- > > "To err is human, to blame it on somebody else shows management > potential." > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW - Sequência de PIPE e QUEUE
2009/4/27 Trober : > Olá! > > ASSUNTO 1: > > "ProxyFull" é um nome informal dado para a marcação ZPH (Zero Penalty Hit) > dentro do Squid, permitindo que arquivos obtidos do cache sejam entregues > em banda completa, e não limitada. Se um usuário da sua rede tem banda de > 768kbps, ele obterá do cache o arquivo na máxima velocidade que o meio > físico permitir (~100mbps, na maioria dos casos wired). > > Quando um arquivo é obtido do disco (TCP_HIT) ou da memória do Squid > (TCP_MEM_HIT), um flag de TOS (Type of Service) é atribuído pelo ZPH. > > No seu controle de banda, você limitará banda para tudo, exceto para quem > tiver a marcação TOS na porta 80, marcada pelo Squid/ZPH ;) > > Se for IPFW, use "not iptos mincost" na regra de controle de banda. Tenho > vários cenários em produção com este recurso, um deles até comentado aqui > na lista[1]. > > [1] http://www.fug.com.br/historico/html/freebsd/2009-01/msg00661.html Ahhh tá... pensei que fosse alguma coisa nova milaborante, ultra-mega-killer-blaster...eheheh Valeu pela resposta. []'s -- "To err is human, to blame it on somebody else shows management potential." - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW - Sequência de PIPE e QUEUE
Ola Nilton, Como vc faz o seu controle de banda junto com o limite de conexoes?? Alex Nilton Jose Rizzo escreveu: > On Sun, 26 Apr 2009 22:49:31 -0300, Vinicius Abrahao wrote > >> Olá Nilton, >> >> Fiquei curioso, como se limita o número de conexões? >> > >com a opção limit X > >ipfw add allow ip from IP to any out via placadesaida limit 30 > > >> Abs, >> Vinícius >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Quero que você entre no Facebook
Tive este problema nos servidores de listas com mailman que administro.
Isso é um "problema" na configuração do mailman. Por default, quando uma lista
é configurada para aceitar posts somente de emails inscritos, ele
analisa além do "from" o campo "reply-to" .
Por isso esse "invite+2o06z...@facebookmail.com" consegue postar em qualquer
lista que estiver hospedada
em um servidor com mailman rodando com configuração default. Apesar do from ser
de um não-membro, no reply-to
e email é de um membro da lista. Isso deve ser alguma ferramenta do facebook em
que a pessoa coloca seu email e senha
e manda convidar todos da sua lista de contatos para entrar no facebook.
Para evitar isso, sugiro a todos que tem servidores com mailman alterar no
mm_cfg.py
de
SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
para
SENDER_HEADERS = ('from')
e reiniciar o mailman.
> Date: Sat, 25 Apr 2009 01:11:11 -0300
> From: danielbris...@gmail.com
> To: freebsd@fug.com.br
> Subject: Re: [FUG-BR] Quero que você entre no Facebook
>
> depois do debian freebsd...
> --
> Daniel Bristot de Oliveira
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
_
Faça já uma busa e ganhe um wink do Messenger. Está esperando o que? É grátis!
http://www.ibud.com.br/
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Quero que você entre no Facebook
Viu?! Até que foi útil hauahuaha
Renata Dias
2009/4/27 TIsOrA TAIUVA
>
> Tive este problema nos servidores de listas com mailman que administro.
>
> Isso é um "problema" na configuração do mailman. Por default, quando uma
> lista é configurada para aceitar posts somente de emails inscritos, ele
> analisa além do "from" o campo "reply-to" .
>
> Por isso esse
> "invite+2o06z...@facebookmail.com"
> consegue postar em qualquer lista que estiver hospedada
> em um servidor com mailman rodando com configuração default. Apesar do from
> ser de um não-membro, no reply-to
> e email é de um membro da lista. Isso deve ser alguma ferramenta do
> facebook em que a pessoa coloca seu email e senha
> e manda convidar todos da sua lista de contatos para entrar no facebook.
>
> Para evitar isso, sugiro a todos que tem servidores com mailman alterar no
> mm_cfg.py
>
> de
>
> SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
>
> para
>
> SENDER_HEADERS = ('from')
>
>
> e reiniciar o mailman.
>
>
> > Date: Sat, 25 Apr 2009 01:11:11 -0300
> > From: danielbris...@gmail.com
> > To: freebsd@fug.com.br
> > Subject: Re: [FUG-BR] Quero que você entre no Facebook
> >
> > depois do debian freebsd...
> > --
> > Daniel Bristot de Oliveira
> > -
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> _
> Faça já uma busa e ganhe um wink do Messenger. Está esperando o que? É
> grátis!
> http://www.ibud.com.br/
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Quero que você entre no Facebook
2009/4/27 Renata Dias > Viu?! Até que foi útil hauahuaha > > Renata Dias > Toda lista tem disso! Muito chato mesmo! Paciencia.. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Configuar modem 3G ericsson md300
Srs boa tarde: Estou tentando configurar um modem 3g md300. Andei lendo uma thread aqui na fug[1] sobre ele, mais não tem solução postada. Olhando em alguns forums de Linux uma das soluções apresentadas é fazer com que o dispositivo seja reconhecido com modem e não com unidade de disco (drivers e setup para windows), a unica solução para isso seria desabilitar o device UMASS_STORAGE do kernel?? Ou consigo fazer através do udev?? Alguem ja usou com sucesso este modem?? [1] http://www.fug.com.br/historico/html/freebsd/2009-02/msg00045.html [2] http://laudecioliveira.org/blog/?p=70 -- Giancarlo Rubio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] LOAD BALANCE HARDWARE
man lagg The driver currently supports the aggregation protocols failover (the default), fec, lacp, loadbalance, roundrobin, and none. The protocols determine which ports are used for outgoing traffic and whether a spe- cific port accepts incoming traffic. The interface link state is used to validate if the port is active or not. loadbalance Balances outgoing traffic across the active ports based on hashed protocol header information and accepts incoming traffic from any active port. This is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. The hash includes the Ethernet source and destination address, and, if available, the VLAN tag, and the IP source and destination address. The following example uses an active failover interface to set up roaming between wired and wireless networks using two network devices. Whenever the wired master interface is unplugged, the wireless failover device will be used: # ifconfig em0 up # ifconfig ath0 nwid my_net up # ifconfig lagg0 laggproto failover laggport em0 laggport ath0 \ 192.168.1.1 netmask 255.255.255.0 Bom modifique e efetue testes para ver se isto resolve seu problema. 2009/4/25 : > > > > Pessoal, tem como unir a saída de dois rádios em um servidor FreeBSD e saír > apenas um link. Lembrando que > é um link de rede local. > > > _ > Emoticons e Winks super diferentes para o Messenger. Baixe agora, é grátis! > http://specials.br.msn.com/ilovemessenger/pacotes.aspx > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- - = - = - = - = - = - = - = - = - = - <. Of course it runsWilliam David Armstrong <|== Bio Systems Security Networking <' FreeBSD MSN / GT biosystems gmail . com http://biosystems.ath.cx:8080/ http://biosystems.broker.freenet6.net/ -- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] LOAD BALANCE HARDWARE
levitl...@hotmail.com escreveu: > > Pessoal, tem como unir a saída de dois rádios em um servidor FreeBSD e saír > apenas um link. Lembrando que > é um link de rede local. > > > _ > Emoticons e Winks super diferentes para o Messenger. Baixe agora, é grátis! > http://specials.br.msn.com/ilovemessenger/pacotes.aspx > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > Levi, Uso para 400 clientes um appliance da d-link modelo DI-LB604. Funciona redondo. abraços - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Configuar modem 3G ericsson md300
Fala Giancarlo, Tente desabilitar o umass, tive um problema (com outro modelo) e só funcionou carregando o umass como módulo após a conexão. Pelo que me lembro usava o ubsa. Sds, Vinícius - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Configuar modem 3G ericsson md300
2009/4/27 Vinicius Abrahao : > Fala Giancarlo, > > Tente desabilitar o umass, tive um problema (com outro modelo) e só > funcionou > carregando o umass como módulo após a conexão. Pelo que me lembro usava > o ubsa. > Boa noite Vinicius Vc ja usou esse modem com sucesso no FreeBSD? Ja fiz isso, recompilei o kernel, mais ainda nao funciona na hora da conexao, meu problema agora é na conexao Dmesg (sem umass) ucom0: on uhub2 ucom0: iclass 2/2 ucom0: data interface 4, has CM over data, has break ucom0: status change notification available cdce0: on uhub2 cdce0: could not find data bulk in device_attach: cdce0 attach returned 6 Pelo que eu li, nessa ultima linha " cdce0 attach returned 6" removendo e colocando ele de novo resolveria mais no meu caso não resolveu e acho que é ai meu problema. meu ppp.conf default: set log Phase Chat LCP IPCP CCP tun command set device /dev/cuaU0 set speed 236800 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" tim: set authname tim set authkey tima set phone *99***\# set timeout 1 add default HISADDR enable dns meu problema é que a conexao se perde apos eu conectar , a linha que importa é essa Apr 27 18:30:05 frw ppp[1747]: tun0: Phase: bundle: Terminate Apr 27 18:30:06 frw ppp[1747]: tun0: Phase: deflink: Carrier lost Apr 27 18:30:06 frw ppp[1747]: tun0: LCP: deflink: State change Stopping --> Starting Apr 27 18:30:06 frw ppp[1747]: tun0: LCP: deflink: LayerFinish Meu ppp.log Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: deflink: Redial timer expired. Apr 27 18:30:26 frw ppp[1747]: tun0: Phase: deflink: Connected! Apr 27 18:30:26 frw ppp[1747]: tun0: Phase: deflink: opening -> dial Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Phone: *99***# Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Send: AT^M Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Expect(5): OK Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: AT^M^M Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: OK^M Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Send: ATE1Q0^M Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Expect(5): OK Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: ATE1Q0^M^M Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: OK^M Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Send: ATDT*99***#^M Apr 27 18:30:28 frw ppp[1747]: tun0: Chat: Expect(40): CONNECT Apr 27 18:30:28 frw ppp[1747]: tun0: Chat: Received: ATDT*99***#^M~}#!}!}!} }9}#}%#}%}(}"}'}"}"}&} } } } }%}&M-^H}&~^M Apr 27 18:30:28 frw ppp[1747]: tun0: Chat: Received: CONNECT^M Apr 27 18:30:28 frw ppp[1747]: tun0: Phase: deflink: dial -> carrier Apr 27 18:30:29 frw ppp[1747]: tun0: Phase: deflink: /dev/cuaU0: CD detected Apr 27 18:30:29 frw ppp[1747]: tun0: Phase: deflink: carrier -> login Apr 27 18:30:29 frw ppp[1747]: tun0: Phase: deflink: login -> lcp Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: FSM: Using "deflink" as a transport Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: State change Initial --> Closed Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: State change Closed --> Stopped Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: RecvConfigReq(2) state = Stopped Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0xbed58806 Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: SendConfigReq(9) state = Stopped Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MRU[4] 1500 Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0x78516bd6 Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: SendConfigAck(2) state = Stopped Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0xbed58806 Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: LayerStart Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: State change Stopped --> Ack-Sent Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: RecvConfigReq(3) state = Ack-Sent Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0xbed58806 Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: SendConfigAck(3) state = Ack-Sent Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Apr 27 18:30:29 frw
Re: [FUG-BR] firebird2 superserver no FreeBSD 7.1
No meu caso o número de usuário é baixo. Em torno de 20. Tem se comportado bem desde a versão 1.5 do Firebird no FreeBSD 6.4. Agora migrei para o FreeBSD 7.1 e Firebird 2.0.3. --- Em seg, 20/4/09, Welkson Renny de Medeiros escreveu: > De: Welkson Renny de Medeiros > Assunto: Re: [FUG-BR] firebird2 superserver no FreeBSD 7.1 > Para: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" > > Data: Segunda-feira, 20 de Abril de 2009, 10:52 > Rafal Mentz Aquino escreveu: > > Nos casos de ser imprescindível a versão superserver > > pode-se rodar a versão para Linux. Tenho rodando > > em um FreeBSD e funciona bem. > > > > Atenciosamente, > > > > -- > > Rafael Mentz Aquino > > LK6 Soluções em TI > > raf...@lk6.com.br > > 51 - 4063 - 6269 > > 51 - - 7030 > > > > > > -- Original Message --- > > From: Renato Botelho > > To: Lista Brasileira de Discussão sobre FreeBSD > (FUG-BR) > > Sent: Mon, 20 Apr 2009 08:44:41 -0300 > > Subject: Re: [FUG-BR] firebird2 superserver no FreeBSD > 7.1 > > > > > >> 2009/4/19 Dilson Moreira > : > >> > >>> Ola', > >>> > >>> Instalei o o firebird2 no FreeBSD 7.1. > Esta' rodando bem. O pkg_info mostra: > >>> > >>> firebird-server-2.0.3_2 Firebird-2 relational > database (server) > >>> > >>> Nao tenho como saber se esta' rodando no > modo classic ou superserver. > >>> > >>> No Makefile do ports nao vi mencao alguma > sobre classic ou superserver. > >>> > >>> Alguem poderia informar se ja e' possivel > instalar no modo superserver no > >>> > > FreeBSB 7.1? > > > >> Até onde eu sei não existe versão Superserver > pra Free > >> > >> -- > >> Renato Botelho > >> - > >> Histórico: > http://www.fug.com.br/historico/html/freebsd/ > >> Sair da lista: > https://www.fug.com.br/mailman/listinfo/freebsd > >> > > --- End of Original Message --- > > > > - > > Histórico: > http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: > https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > > Não sei vocês, mas eu tive vários problemas com Firebird > no FreeBSD. No > meu sistema não uso só SYSDBA, crio usuários para > facilitar o sistema de > log... dava uns PAU maluco... migrei para Windows > funcionou, depois > migrei para Linux, também sem problemas (o Linux é só > para o banco, sem > flames =) > > Como falei... só SYSDBA funcionava bem... mas com vários > usuários no > banco dava uns erros maluco (que não lembro mais). > > Sem falar que o PORTS está bem desatualizado... o fb já > tá na versão > 2.1.2 e teve bastante mudança significativa (mesmo na > release 2.0, já > que no ports está 2.0.3 e no site tem o 2.0.5). > > -- > Welkson Renny de Medeiros > Focus Automação Comercial > Desenvolvimento / Gerência de Redes > welk...@focusautomacao.com.br > > > > Powered by > >(__) > > \\\'',) > \/ \ ^ > .\._/_) > > www.FreeBSD.org > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: > https://www.fug.com.br/mailman/listinfo/freebsd Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW - Sequência de PIPE e QUEUE
On Mon, 27 Apr 2009 12:12:11 -0300, Alex Almeida wrote
> Ola Nilton,
>
> Como vc faz o seu controle de banda junto com o limite de conexoes??
Na mesma regra que faz o pipe como segue abaixo. Note que neste caso
não uso NAT, são IPs válidos
Com NAT acho que não dá para limitar, pois é necessario que o
pacote seja reinjetado nas regras para que seja "divestado" para
o NAT ( ainda não utilizei a nova opção do ipfw nat)
Pode sar que esteja falando besteira mas com NAT não consegui limitar
ainda estudo uma solução para isto
>
> Alex
>
> Nilton Jose Rizzo escreveu:
> > On Sun, 26 Apr 2009 22:49:31 -0300, Vinicius Abrahao wrote
> >
> >> Olá Nilton,
> >>
> >> Fiquei curioso, como se limita o número de conexões?
> >>
> >
> >com a opção limit X
> >
> >ipfw add allow ip from IP to any out via placadesaida limit 30
Em CSH
ifpw add $regra pipe $pipe_down ip from $IP to any limit dst-addr 30
@ regra ++
ifpw add $regra pipe $pipe_up ip from any to $IP limit src-addr 30
Nesse caso limito as conexões de entrada e saida em 30 simultaneamente
man ipfw
<<-- Cutted -->>
RULE OPTIONS (MATCH PATTERNS)
Additional match patterns can be used within rules. Zero or more of
these so-called options can be present in a rule, optionally prefixed by
the not operand, and possibly grouped into or-blocks.
<<-- cutted -->>
limit {src-addr | src-port | dst-addr | dst-port} N
The firewall will only allow N connections with the same set of
parameters as specified in the rule. One or more of source and
destination addresses and ports can be specified. Currently,
only IPv4 flows are supported.
<<-- cutted -->>
> >
> >
> >> Abs,
> >> Vinícius
> >> -
> >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>
> >
> >
> >
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
--
Nilton José Rizzo
805 Informatica
Disseminando tecnologias
021 2413 9786
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Configuar modem 3G ericsson md300
On Mon, April 27, 2009 19:44, Giancarlo Rubio wrote: > 2009/4/27 Vinicius Abrahao : >> Fala Giancarlo, >> >> Tente desabilitar o umass, tive um problema (com outro modelo) e só >> funcionou >> carregando o umass como módulo após a conexão. Pelo que me lembro usava >> o ubsa. >> > > Boa noite Vinicius > > Vc ja usou esse modem com sucesso no FreeBSD? > > Ja fiz isso, recompilei o kernel, mais ainda nao funciona na hora da > conexao, meu problema agora é na conexao > > Dmesg (sem umass) > > ucom0: addr 2> on uhub2 > ucom0: iclass 2/2 > ucom0: data interface 4, has CM over data, has break > ucom0: status change notification available > cdce0: addr 2> on uhub2 > cdce0: could not find data bulk in > device_attach: cdce0 attach returned 6 tais usando ubsa, certo ? sempre que dava esse erro de attach, não funcionava. mas nem discava, dizia que não achava o disp ucom. tenta retirar e recolocar até não mais dá isso. com ubsa só funcionava assim. mas é tirar e colocar logo. recomendo usar o u3g do current, tem patch para stable mas não sei como anda. nick hibma (acho que é isso, ou perto) quem fez ele :) matheus > Pelo que eu li, nessa ultima linha " cdce0 attach returned 6" > removendo e colocando ele de novo resolveria mais no meu caso não > resolveu e acho que é ai meu problema. > > meu ppp.conf > > default: > set log Phase Chat LCP IPCP CCP tun command > set device /dev/cuaU0 > set speed 236800 > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ >OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > tim: > > set authname tim > set authkey tima > set phone *99***\# > set timeout 1 > add default HISADDR > enable dns > > meu problema é que a conexao se perde apos eu conectar , a linha que > importa é essa > > Apr 27 18:30:05 frw ppp[1747]: tun0: Phase: bundle: Terminate > Apr 27 18:30:06 frw ppp[1747]: tun0: Phase: deflink: Carrier lost > Apr 27 18:30:06 frw ppp[1747]: tun0: LCP: deflink: State change > Stopping --> Starting > Apr 27 18:30:06 frw ppp[1747]: tun0: LCP: deflink: LayerFinish > > > > Meu ppp.log > > > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: deflink: Redial timer expired. > Apr 27 18:30:26 frw ppp[1747]: tun0: Phase: deflink: Connected! > Apr 27 18:30:26 frw ppp[1747]: tun0: Phase: deflink: opening -> dial > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Phone: *99***# > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Send: AT^M > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Expect(5): OK > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: AT^M^M > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: OK^M > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Send: ATE1Q0^M > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Expect(5): OK > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: ATE1Q0^M^M > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Received: OK^M > Apr 27 18:30:26 frw ppp[1747]: tun0: Chat: Send: ATDT*99***#^M > Apr 27 18:30:28 frw ppp[1747]: tun0: Chat: Expect(40): CONNECT > Apr 27 18:30:28 frw ppp[1747]: tun0: Chat: Received: > ATDT*99***#^M~}#!}!}!} }9}#}%#}%}(}"}'}"}"}&} } } } > }%}&M-^H}&~^M > Apr 27 18:30:28 frw ppp[1747]: tun0: Chat: Received: CONNECT^M > Apr 27 18:30:28 frw ppp[1747]: tun0: Phase: deflink: dial -> carrier > Apr 27 18:30:29 frw ppp[1747]: tun0: Phase: deflink: /dev/cuaU0: CD > detected > Apr 27 18:30:29 frw ppp[1747]: tun0: Phase: deflink: carrier -> login > Apr 27 18:30:29 frw ppp[1747]: tun0: Phase: deflink: login -> lcp > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: FSM: Using "deflink" as a > transport > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: State change > Initial --> Closed > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: State change Closed > --> Stopped > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: RecvConfigReq(2) > state = Stopped > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0xbed58806 > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: SendConfigReq(9) > state = Stopped > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MRU[4] 1500 > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0x78516bd6 > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: SendConfigAck(2) > state = Stopped > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACFCOMP[2] > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: PROTOCOMP[2] > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: ACCMAP[6] 0x > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: MAGICNUM[6] 0xbed58806 > Apr 27 18:30:29 frw ppp[1747]: tun0: LCP: deflink: LayerStart > Apr 27 18:
[FUG-BR] duvida rsync copia remota
to tentando fazer uma copia remota com rsync porem ta dando erro . rsync -av -e ssh --recursive --delete diario/ r...@189.y.x.197:/mnt/backup/backup/ gostaria de saber onde pode estar o erro ?? este servidor já consegue dar ssh para o oturo sem senha att diogo - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
