[RESOLVIDO] Problemas acessar FTP



  • Pessoal eu pesquisei antes no forum e as soluções passadas anteriormente não me ajudaram.
    Após migrar para o PF tem um ftp que não consigo acessar via linha de comando.
    Ele conecta eu consigo fazer o logon mas não consigo listar os diretorios nem executar nenhum comando

    Segue os print

    O priemiro é a configuração que pediram pra fazer em um dos post que eu li.
    O segundo é o meu log mostrando a conexão realizada.
    E o terceiro é o que aparece quando tento listar dentro do ftp deles.








  • O FTP ta reclamado de falta de comando.

    "use pasv or port first"

    Digite pasv antes do ls



  • Dá comando inválido.
    Eu fiz em uma outra rede que eu tenho aqui que não passa por nenhum fw, e por ela a conexão foi normal consegui listar os diretórios perfeitamente.
    E agora estou tendo problema com o meu ftp também. Se tentar conectar de fora no meu ftp em modo passivo da esse erro: Erro ao abrir pasta no servidor de FTP. Certifique-se de que voce tem permissão para acessar a pasta.
    Eu já limitei o range de portas no iis e liberei as mesmas no fw e mesmo assim não vai =(.

    Não tem mais nada que eu possa fazer?



  • :(



  • Você tentou digitar passive no lugar de pasv?



  • Sim tentei, e nada não vai nem com bomba.



  • leandruco,

    Você chegou a verificar este outro tópico: http://forum.pfsense.org/index.php/topic,39778.0.html

    Veja que ele tem várias dicas importantes sobre o funcionamento de uma conexão FTP e como trabalhar "melhor" com elas no pfSense!

    Abraços!
    Jack



  • Olá Jack já li tudo que vc imagina kkk.
    Até no forum Holandês eu já entrei. A maioria das dicas á para o pf mais antigo.
    Já restringi o range de portas no IIS já fiz de tudo.

    E quem ta de fora não acessa o meu FTP no modo passivo

    No iptables tinha uma regra que era a -m state –state RELATED,ESTABBLISHED -j ACCEPT

    Que apó feita a conexão todas as outras derivadas desta eram liberadas.

    No pf não tem nada parecido com isso?



  • leandruco,

    o pfSense é baseado num netfilter statefull (assim como o iptables). Isso significa que ele funciona exatamente como você está relatando (conexões estabelecidas, são mantidas até terminarem ou expirarem por qualquer motivo).

    Você chegou a mexer em System->Advanced->Miscellaneous (deixou esta diretiva com valor "1")?

    O seu firewall (Firewall->Rules->Lan) está configurado do Tipo Prudente, ou seja, por default todas as conexões são bloqueadas?

    Abraços!
    Jack



  • Ola Jack obrigado pela informação
    Em relação ao Miscellaneous eu fiz sim inclusive tem os print no meu primeiro post se quiser dar uma olhada.
    Agora em relção a segunda pergunta eu creio que sim pois se eu não coloco a regra de liberação não funciona nada.



  • @leandruco:

    Ola Jack obrigado pela informação
    Em relação ao Miscellaneous eu fiz sim inclusive tem os print no meu primeiro post se quiser dar uma olhada.
    Agora em relção a segunda pergunta eu creio que sim pois se eu não coloco a regra de liberação não funciona nada.

    Certo leandruco,

    Neste caso, crie uma regra em "Firewall->Rules->Lan" liberando as conexões com destino aos FTPs (portas) passivos.

    Basicamente conforme segue em anexo (Veja que no exemplo configurei um "alias" com todos os IPs públicos dos FTPs que a rede local pode/deve acessar).

    Abraços!
    Jack




  • Opa eu já tinha feito uma parecida só que n coloquei as portas deixei tudo para fazer o teste




  • Notei que vc está fazendo loadbalance de link de dados, correto?

    Você já marcou a opção "System->Advanced->(Aba Miscellaneous)->Use sticky connections"?

    Outra coisa importante, tente "encabeçar esta sua regra". Veja que o fw é sempre interpretado sequencialmente… Se houver uma regra mais acima que esteja negando este acesso, esta sua regra jamais será executada!

    Nota: Jamais libere tudo conforme a imagem que você encaminhou. Imagino que você só o fez por teste, correto? ;)

    Abraços!
    Jack



  • Sim foi só para teste.
    Não tinha marcado a opção que vc mencionou marquei agora pra que ela serve?

    O acesso ao meu ftp eu consegui arrumar gora ele aceita tanto no modo passivo quanto no modo ativo.
    Uma coisa que eu percebi é que as vezes os alias dão pau. A regra tava feita com o alias e n tava funcionando troquei para o ip cadastrado no VIRTAL IP ai funcinou, depois voltei para o alias novamente dai continuou funcionando.

    A unica coisa que falta agora é eu conseguir acessar este bendito ftp em modo passivo.



  • Jack a navegação parou após ativar está opção
    "System->Advanced->(Aba Miscellaneous)->Use sticky connections"?



  • @leandruco:

    Jack a navegação parou após ativar está opção
    "System->Advanced->(Aba Miscellaneous)->Use sticky connections"?

    Esta opção faz com que o pfSense mantenha uma conexão (enquanto ela durar - portanto, até que uma das pontas termine-a) pelo link de dados em que ele iniciou. Ela é importantíssima quando se faz loabalance no pfSense e trabalha-se com conexões baseadas em seções (caso de HTTPS e afins, por exemplo).

    Ela não deveria interromper a sua navegação… Muito pelo contrário, se você não a tinha marcado e estava tendo problemas com acesso a sites de banco, por exemplo, ela resolveria boa parte da sua vida!

    Minha dica é que você reveja todas as tuas regras em "Firewall->Rules->Lan" e deixe esta regra de FTP passivo o mais próximo do início possível!

    Abraços!
    Jack



  • Vlw Jack vou dar uma revisada.
    Em questão de sites de banco estava tendo problemas sim dai configurei pra só sair por um link.

    Amanha posto os resultados depois de tudo organizado.

    Obrigado pela atenção e bom descanso.



  • @leandruco:

    Em questão de sites de banco estava tendo problemas sim dai configurei pra só sair por um link.

    Agora com o Use sticky connections você não precisa mais fixar rota de saída pra este tipo de conexão. Pelo link que a conexão for iniciada, ela será encerrada! ;)

    Abraços!
    Jack



  • leandruco,

    @marcelloc:

    Faz uns testes via tcpdump para saber em que passo a comunicação interrompe.

    Veja tanto a porta de comandos quanto a de dados. Abra duas consoles e Escute na wan e na lan ao mesmo tempo.

    Desabilite tambem os helpers de FTP e refaça os mesmos testes.

    Você consegue ver via tcpdump o que esta acontecendo? pacote saindo sem nat, pacote morrendo no firewall, pacote alternando entre dois links,etc?

    Como já disse em alguns outros posts, o tcpdump é seu amigo. A interface gráfica ajuda muito, mas debug de verdade é feito na console.



  • Opa Marcello eu sempre trabalhava só no console com o iptables, mas como ainda não sou muito intimo do BSD ainda fico meio acanhando de mecher no console dele com medo de estragar kkkkk. Mas vou instalar o TCPDUMP e ver quais informações consigo tirar.

    Obrigado.



  • @leandruco:

    Mas vou instalar o TCPDUMP e ver quais informações consigo tirar.

    leandruco,

    O tcpdump é nativo no pfSense. Basta usar!

    Para saber como iniciar os trabalhos com o tcpdump: http://www.pedropereira.net/como-usar-o-tcpdump/

    Abraços!
    Jack



  • Obrigado pelo material muito bom,
    Porem estou tendo um pequeno problema para extrair os logs dele para um arquivo

    estou executando o seguinte comando:
    tcpdump -nn -ni (interface) host (ip do host) -w /tmp/dump/arquivo.pcap

    Porem este comando está dando um erro de syntax.

    Onde será que eu estou errando?



  • costumo usar desta forma:

    console 1

    tcpdump -ni (interface_wan) host (ftp_remoto)

    console 2

    tcpdump -ni (interface_lan) host (ftp_remoto)

    deste sintaxe simples, voce consegue saber o que não esta dando certo.

    são raros os casos em que você precisa salvar o log para analisar no wireshark.

    no ftp ativo, fique de olho nas requisições com origem porta 20



  • Já descobri
    O correto é:

    tcpdump -w /tmp/dump/arquivo.pcap -nn -ni (interface) host (ip do host)

    ;)



  • Pois é Marcello eu fiz a análise mas não sei se sou muito juvenil, mas não encontrei nada de errado.
    As conexões estão sendo realizadas normalmente.

    Ser que posso colar o log aqui pra vcs darem uma olhada?



  • LOG ETH WAN
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
    15:43:08.771240 IP IP WAN.32378 > IP FTP.21: Flags [P.], ack 3588619334, win 8153, length 13
    15:43:08.786177 IP IP FTP.21 > IP WAN.32378: Flags [.], ack 13, win 46, length 0
    15:43:08.786219 IP IP FTP.21 > IP WAN.32378: Flags [P.], ack 13, win 46, length 34
    15:43:08.986044 IP IP WAN.32378 > IP FTP.21: Flags [.], ack 35, win 8119, length 0
    15:43:13.603366 IP IP WAN.32378 > IP FTP.21: Flags [P.], ack 35, win 8119, length 17
    15:43:13.625555 IP IP FTP.21 > IP WAN.32378: Flags [P.], ack 30, win 46, length 23
    15:43:13.825326 IP IP WAN.32378 > IP FTP.21: Flags [.], ack 58, win 8096, length 0
    15:43:16.771686 IP IP WAN.32378 > IP FTP.21: Flags [P.], ack 58, win 8096, length 27
    15:43:16.786957 IP IP FTP.21 > IP WAN.32378: Flags [P.], ack 57, win 46, length 27
    15:43:16.790997 IP IP WAN.32378 > IP FTP.21: Flags [P.], ack 85, win 8069, length 6
    15:43:16.806116 IP IP FTP.21 > IP WAN.32378: Flags [P.], ack 63, win 46, length 29
    15:43:17.006350 IP IP WAN.32378 > IP FTP.21: Flags [.], ack 114, win 8040, length 0

    LOG ETH LAN
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
    15:43:08.771219 IP IP LAN.30497 > IP FTP.21: Flags [P.], ack 3588619334, win 8153, length 13
    15:43:08.786211 IP IP FTP.21 > IP LAN.30497: Flags [.], ack 13, win 46, length 0
    15:43:08.786232 IP IP FTP.21 > IP LAN.30497: Flags [P.], ack 13, win 46, length 34
    15:43:08.986020 IP IP LAN.30497 > IP FTP.21: Flags [.], ack 35, win 8119, length 0
    15:43:13.603350 IP IP LAN.30497 > IP FTP.21: Flags [P.], ack 35, win 8119, length 17
    15:43:13.625569 IP IP FTP.21 > IP LAN.30497: Flags [P.], ack 30, win 46, length 23
    15:43:13.825312 IP IP LAN.30497 > IP FTP.21: Flags [.], ack 58, win 8096, length 0
    15:43:16.771664 IP IP LAN.30497 > IP FTP.21: Flags [P.], ack 58, win 8096, length 27
    15:43:16.786984 IP IP FTP.21 > IP LAN.30497: Flags [P.], ack 57, win 46, length 27
    15:43:16.790979 IP IP LAN.30497 > IP FTP.21: Flags [P.], ack 85, win 8069, length 6
    15:43:16.806138 IP IP FTP.21 > IP LAN.30497: Flags [P.], ack 63, win 46, length 29
    15:43:17.006327 IP IP LAN.30497 > IP FTP.21: Flags [.], ack 114, win 8040, length 0



  • O FTP remoto rejeita seu comando e não faz mais nada.

    Só tem log na 21.

    Nenhuma tentativa de transferencia é feita.



  • Galera resolvi todos os problemas com FTP.
    Se eu contar pra vcs vcs não vão acreditar.

    Eu segui os passos dos tutoriais antes de tentar.
    Então eu fui em system->advanced->system tunables e coloquei o valor do debug.pfftpproxy como 1.

    Então comecei a fazer as regras e os testes e nada de dar certo.

    Hoje já injuriado sem saber mais o que fazer, fui lá e mudei essa opção para 0 que é o padrão.
    Pronto problema resolvido funcionou tanto as publicações do meu FTP quanto o acesso passivo/ativo de ftps externos.

    Obrigado mais uma vez pela ajuda e atenção de vocês fico muito grato e contente em saber que tenho pra onde correr quando preciso.



  • É isso mesmo leandruco,

    Você deve ativar ou desativar o "debug.pfftpproxy" de acordo com a configuração, principalmente, do seu FTP (o teu servidor que é acessado de fora da rede). Ela define se o pfSense fará ou não proxy nas conexões FTP!

    Cada caso é um caso!

    Abraços!
    Jack



  • FTP é um dos protocolos mais chatos que tem pra configurar.

    Serve até para testar habilidades de candidatos para emprego de administrador de firewall  :)



  • Pessoal voltei a ter probleas com FTP.
    Quando o cliente acessa o ftp pelo link A o modo passivo/ativo funcionam perfeitamente.
    Quando o cliente acesso o ftp pelo link B só funciona o passivo (windows explorer)

    Via TCPDUMP realizei o mesmo tipo de conexão pelos 2 links e observei que as seguintes conexões não são realizadas no link B, porem as mesmas regras de liberação e NAT estão definidas para ambos os links.

    200.195.x.x -> IP LINK A
    201.22.95.99 -> IP CLIENTE

    10:40:52.708716 IP 200.195.x.x.50767 > 201.22.95.99.55090: Flags , seq 11229273, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    10:40:55.735015 IP 200.195.x.x.50767 > 201.22.95.99.55090: Flags , seq 11229273, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    10:41:01.780760 IP 200.195.x.x.50767 > 201.22.95.99.55090: Flags , seq 11229273, win 8192, options [mss 1460,nop,nop,sackOK], length 0



  • Segue o log do TCPDUMP no momento em que é executando o comando para listar os diretórios.
    OBS. A conexão é feita normalmente pelos 2 links porem quando é solicitado que liste o diretório que só funciona pelo link A.

    TCPDUMP link A:

    11:34:00.125920 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 691336811, win 2041, length 16
    11:34:00.126308 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 16, win 260, length 38
    11:34:00.374007 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 39, win 2031, length 0
    11:34:03.388468 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 39, win 2031, length 19
    11:34:03.389122 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 35, win 260, length 21
    11:34:03.637331 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 60, win 2026, length 0
    11:34:05.458092 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 60, win 2026, length 27
    11:34:05.458663 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 62, win 260, length 30
    11:34:05.524721 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 90, win 2019, length 6
    11:34:05.525131 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 68, win 260, length 41
    11:34:05.768959 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 131, win 2008, length 0
    11:34:26.472034 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 68, win 260, length 6
    11:34:26.745356 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 137, win 2007, length 0

    TCPDUMP link B
    11:36:00.160894 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [P.], ack 2523323193, win 2026, length 27
    11:36:00.161612 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [P.], ack 27, win 260, length 30
    11:36:00.206559 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [P.], ack 31, win 2019, length 6
    11:36:00.207220 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [P.], ack 33, win 260, length 41
    11:36:00.478272 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [.], ack 72, win 2008, length 0
    11:36:21.199448 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [P.], ack 33, win 260, length 6
    11:36:21.467695 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [.], ack 78, win 2007, length 0
    11:38:28.714855 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [R.], seq 78, ack 33, win 0, length 0



  • leandruco,

    Alguns provedores de internet simplesmente bloqueiam as conexões para a porta de comandos do FTP. Já peguei vários casos assim!

    Neste caso voltamos a indicação de uso ou não da diretiva debug.pfftpproxy, bem com, a questão do tipo de configuração do seu FTP Server!  :-\

    Abraços!
    Jack



  • Os dois links estão comunicando na porta 21, confere agora a porta de dados.

    @leandruco:

    Segue o log do TCPDUMP no momento em que é executando o comando para listar os diretórios.
    OBS. A conexão é feita normalmente pelos 2 links porem quando é solicitado que liste o diretório que só funciona pelo link A.

    TCPDUMP link A:

    11:34:00.125920 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 691336811, win 2041, length 16
    11:34:00.126308 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 16, win 260, length 38
    11:34:00.374007 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 39, win 2031, length 0
    11:34:03.388468 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 39, win 2031, length 19
    11:34:03.389122 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 35, win 260, length 21
    11:34:03.637331 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 60, win 2026, length 0
    11:34:05.458092 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 60, win 2026, length 27
    11:34:05.458663 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 62, win 260, length 30
    11:34:05.524721 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [P.], ack 90, win 2019, length 6
    11:34:05.525131 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 68, win 260, length 41
    11:34:05.768959 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 131, win 2008, length 0
    11:34:26.472034 IP 189.42.54.183.21 > 201.22.95.99.55914: Flags [P.], ack 68, win 260, length 6
    11:34:26.745356 IP 201.22.95.99.55914 > 189.42.54.183.21: Flags [.], ack 137, win 2007, length 0

    TCPDUMP link B
    11:36:00.160894 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [P.], ack 2523323193, win 2026, length 27
    11:36:00.161612 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [P.], ack 27, win 260, length 30
    11:36:00.206559 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [P.], ack 31, win 2019, length 6
    11:36:00.207220 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [P.], ack 33, win 260, length 41
    11:36:00.478272 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [.], ack 72, win 2008, length 0
    11:36:21.199448 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [P.], ack 33, win 260, length 6
    11:36:21.467695 IP 201.22.95.99.55966 > 189.42.54.183.21: Flags [.], ack 78, win 2007, length 0
    11:38:28.714855 IP 189.42.54.183.21 > 201.22.95.99.55966: Flags [R.], seq 78, ack 33, win 0, length 0



  • Opa galera
    @JackL:

    leandruco,

    Alguns provedores de internet simplesmente bloqueiam as conexões para a porta de comandos do FTP. Já peguei vários casos assim!

    Neste caso voltamos a indicação de uso ou não da diretiva debug.pfftpproxy, bem com, a questão do tipo de configuração do seu FTP Server!  :-\

    Abraços!
    Jack

    Já está habilitado esta opção. Testei das 2 formas habilitado e desabilitado.

    @marcelloc:

    Os dois links estão comunicando na porta 21, confere agora a porta de dados.

    Marcello, as mesmas regras que tem para um tem para o outro liberado a porta 20,21,22 e da 1024 até a 65000
    Não sei mas o que fazer, já conferi tudo umas 10x



  • monitora via tcpdump o ip remoto e não só a porta 21 na wan

    e monitora o ip do servidor ftp na dmz/lan

    desta forma você consegue ver aonde esta o problema



  • @leandruco:

    …as mesmas regras que tem para um tem para o outro liberado a porta 20,21,22 e da 1024 até a 65000

    Justamente,

    Talvez seja um bloqueio por parte do provedor de internet (a conexão é barrada no provedor, não no seu pfSense).

    Verifique se não é este o caso (porta 20 bloqueada no provedor, por exemplo)!

    Abraços!
    Jack



  • @marcelloc:

    monitora via tcpdump o ip remoto e não só a porta 21 na wan

    e monitora o ip do servidor ftp na dmz/lan

    desta forma você consegue ver aonde esta o problema

    Esse log já é da conexão geral e não só da porta 21, vou monitorar na rede interna esse teste realmente eu esqueci de fazer, já eu posto os resultados.



  • Seu servidor deve estar tentando comunicar via ftp modo ativo.

    ip_do_seu_ftp.porta20 -> ip_do_seu_cliente.porta alta



  • Segue o log pelos 2 links mas agora a comunicação interna

    LINK A
    15:28:20.781042 IP 201.22.x.x.60183 > 192.168.x.x.21: Flags [P.], ack 3713252912, win 2026, length 26
    15:28:20.781695 IP 192.168.x.x.20 > 201.22.x.x.60189: Flags ~~, seq 3501714132, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    15:28:20.781730 IP 192.168.x.x.21 > 201.22.x.x.60183: Flags [P.], ack 26, win 260, length 30
    15:28:20.812791 IP 201.22.x.x.60189 > 192.168.x.x.20: Flags [S.], seq 2427334378, ack 3501714133, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
    15:28:20.813346 IP 192.168.x.x.20 > 201.22.x.x.60189: Flags [.], ack 1, win 260, length 0
    15:28:20.817325 IP 201.22.x.x.60183 > 192.168.x.x.21: Flags [P.], ack 31, win 2019, length 6
    15:28:20.817903 IP 192.168.x.x.21 > 201.22.x.x.60183: Flags [P.], ack 32, win 260, length 54
    15:28:20.817924 IP 192.168.x.x.20 > 201.22.x.x.60189: Flags [P.], ack 1, win 260, length 12
    15:28:20.817938 IP 192.168.x.x.20 > 201.22.x.x.60189: Flags [F.], seq 13, ack 1, win 260, length 0
    15:28:20.817952 IP 192.168.x.x.21 > 201.22.x.x.60183: Flags [P.], ack 32, win 260, length 24
    15:28:20.848933 IP 201.22.x.x.60189 > 192.168.x.x.20: Flags [.], ack 14, win 68, length 0
    15:28:20.849671 IP 201.22.x.x.60183 > 192.168.x.x.21: Flags [.], ack 109, win 1999, length 0
    15:28:20.857958 IP 201.22.x.x.60189 > 192.168.x.x.20: Flags [F.], seq 1, ack 14, win 68, length 0
    15:28:20.858382 IP 192.168.x.x.20 > 201.22.x.x.60189: Flags [.], ack 2, win 260, length 0
    15:29:18.933997 IP 192.168.x.x.21 > 201.22.x.x.60168: Flags [R.], seq 844573360, ack 243557362, win 0, length 0
    15:30:28.933866 IP 192.168.x.x.21 > 201.22.x.x.60183: Flags [R.], seq 109, ack 32, win 0, length 0

    LINK B
    15:26:52.902409 IP 201.22.x.x.60168 > 192.168.x.x.21: Flags [P.], ack 844573283, win 2026, length 26
    15:26:52.902940 IP 192.168.x.x.20 > 201.22.x.x.60172: Flags ~~, seq 2312002024, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    15:26:52.902989 IP 192.168.x.x.21 > 201.22.x.x.60168: Flags [P.], ack 26, win 260, length 30
    15:26:52.951223 IP 201.22.x.x.60168 > 192.168.x.x.21: Flags [P.], ack 31, win 2019, length 6
    15:26:52.953779 IP 192.168.x.x.21 > 201.22.x.x.60168: Flags [P.], ack 32, win 260, length 41
    15:26:53.205003 IP 201.22.x.x.60168 > 192.168.x.x.21: Flags [.], ack 72, win 2008, length 0
    15:26:55.902657 IP 192.168.x.x.20 > 201.22.x.x.60172: Flags ~~, seq 2312002024, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    15:27:01.902678 IP 192.168.x.x.20 > 201.22.x.x.60172: Flags ~~, seq 2312002024, win 8192, options [mss 1460,nop,nop,sackOK], length 0
    15:27:13.918462 IP 192.168.x.x.21 > 201.22.x.x.60168: Flags [P.], ack 32, win 260, length 6
    15:27:14.171867 IP 201.22.x.x.60168 > 192.168.x.x.21: Flags [.], ack 78, win 2007, length 0

    Percebi que no link A tem uma comunicação maior na porta 20, o que me leva a pensar que talvez seja o problema que o Jack falou com a operadora. O que vcs acham?~~~~~~~~


Locked