Por que o localizador do Mac OS X (10.6) não consegue se conectar a computadores Windows?

2

Temos um Mac (um MacBook Pro Unibody) entre nossas máquinas Windows, que se conecta ao "servidor" (na verdade, um Dell executando o Windows XP Pro) para acessar documentos. Isso funciona muito bem na maior parte do tempo, mas, às vezes, depois de acordar, ele não consegue se conectar a qualquer computador com Windows na rede.

Não há erros (nem mesmo mensagens) no aplicativo Console ao tentar conectar-se pela navegação de rede do Finder, nem ao usar o menu "Conectar ao servidor", por nome ou IP.

Eu tentei "Reiniciar" no Finder, alterei o Compartilhamento de Arquivos, desabilitei e reativei o Airport, mas nada faz com que o Mac possa se conectar novamente até que eu o reinicie!

Outros computadores podem se conectar às máquinas, então é definitivamente culpa do Mac.

Existe alguma solução alternativa que alguém tenha encontrado? Existe talvez uma maneira de reiniciar o cliente samba?

Editar:

O laptop está de fato usando wireless, mas toda a conectividade de rede está funcionando, o Mac pode fazer o ping no host XP que está tentando se conectar e navegar na internet. Eu tentei usar o endereço IP da máquina host no item de menu "Conectar ao Servidor"; Isso é agora mencionado acima.

    
por Drarok 16.03.2010 / 13:35

2 respostas

1

[Editar: removidas as perguntas que você respondeu em sua edição, fez novas perguntas, fez esclarecimentos.]

  1. O compartilhamento SMB montado (ou uma pasta com o mesmo nome) ainda é exibido em /Volumes ?
  2. O que o comando mount reporta?
  3. O umount /Volumes/<name of share> faz alguma coisa? (Observe que é "umount", não "desmontar").

Observe que o registro do Console do Mac OS X geralmente apenas informa mensagens de aplicativos que são executados como o usuário atual. O software executado como raiz (ou "nobody" ou qualquer uma das contas padrão do sistema restrito, como "www") geralmente registra em log /var/log/system.log ou outros logs. Em 10.6, as mensagens do kernel, que provavelmente incluem mensagens do sistema de arquivos, vão para /var/log/kernel.log, então olhe lá também. O aplicativo Console permite que você navegue por todos esses registros se clicar em "Mostrar lista de registros". O cliente SMB do Mac OS X (que eu pareço lembrar é da própria implementação da Apple, não baseado em Samba deriva do FreeBSD smbfs de Boris Popov, que não é baseado em Samba) provavelmente não é executado como o usuário atual , por isso, provavelmente não registra no log do console. Olhe no system.log e no kernel.log.

    
por 16.03.2010 / 17:41
1

É altamente recomendável que você verifique as correção do TCP ACK aqui . Eu apliquei-o em muitas situações onde os clientes do Mac OS X engasgam com ambientes Windows & funciona muito bem. Explicação detalhada aqui

A versão curta, do que isto faz: Há um erro de incompatibilidade na forma como a pilha TCP Mac OS X manipula as TCP ACKs, o que basicamente resulta na perda de pacotes. Beachball girando? Conexões lentas? Coisas assim. Uma correção como essa não corre o risco de corromper os dados porque está mudando a maneira como os pacotes TCP enviados / recebidos se comportam. Então, em vez de usar uma implementação falha do algoritmo de Nagle, a configuração desativa o algoritmo para que os pacotes possam ser enviados / recebidos sem esperar

Agora, para começar, verifique isso no terminal:

sysctl net.inet.tcp.delayed_ack

Deve ser um dos 4 números:

  • 0 = Responde após cada pacote (OFF)
  • 1 = Sempre emprega ACK atrasado, 6 pacotes podem receber 1 ACK
  • 2 = ACK Imediato após o 2º pacote, 2 pacotes por ACK (Modo de Compatibilidade)
  • 3 = Deve detectar automaticamente quando usar atraso ack, 4 pacotes por ack. (Padrão)

99% das vezes, um Mac será configurado para a opção 3 , que é o que é um Mac sufocado quando conectado a servidores que não são Mac. As duas opções para tentar são 0 & %código%. Eu padrão para usar 0 hoje em dia & não teve problemas.

Isso definirá a configuração de 2 como 0:

sudo sysctl -w net.inet.tcp.delayed_ack=0

Desmontar compartilhamentos de arquivos & reconectar. As coisas deveriam ser melhores.

Agora, se você quiser manter essa configuração na reinicialização, será necessário criar um delayed_ack :

sudo nano /etc/sysctl.conf

E cole esta linha solitária:

net.inet.tcp.delayed_ack=0

Se você quiser testar se fez isso corretamente, basta reinicializar sua máquina & faça isso sysctl.conf novamente. Deve ser sysctl net.inet.tcp.delayed_ack .

Espero que isso ajude!

    
por 29.01.2013 / 05:10