Et cela concerne la CG de l'hôte qui est "partagée" avec les VM.
D'après ce que je comprends (très loin d'être un spécialiste), il n y a pas de connecteur dédié et je ne vois pas comment bénéficier de l'accélération à part à travers une session spice (si c'est possible).
OK, on avance!
Alignment Error:
Alignment Error happens in IEEE 802.3(Ethernet) networks. It is an error that occurs when the total number of bits of a received frame is not divisible by eight. Alignment errors are usually caused by frame damage due to collisions and by misaligned reads and writes. For example, a two-byte read where the memory address is not an even multiple of two bytes is an alignment error. Alignment errors are caused by a software bug.
Donc, à priori, il reçoit des paquets corrompus et n'en tient pas compte.
Ça pue! y a un bug soit dans le driver (peut-être résolu dans une version plus récente du noyau) soit dans le firmware du d-link (voir si il y a une version plus récente).
Essaie de désactiver l'autoneg et de forcer la vitesse en 10half avec ethtool.
Ça va ramer mais ça peut pas être pire...
OK, donc pour résumé:
- tu reçois aléatoirement des réponses à tes paquets
- ça marche sous windows
- ça marche sur un autre réseau avec la même config
Peux-tu envoyer le résultat de la commande:
ethtool -S eth0
ethtool -t eth0
ethtool -i eth0
Peut-être un pb de nego, tu peux essayer de fixer la vitesse aux 2 extrémités?
Est-ce qu'il y a moyen de mettre à jour le noyau?
ah d'accord :)
Par contre, on voit que tu reçois des trucs sur eth0, est-ce que tu peux laisser traîner le tcpdump un peu plus longtemps pour voir ce que c'est?
Ca, on dirait que c'est ton réseau WIFI en 192.168.0 pas ton LAN en 192.168.50.
Est-ce que tu pourrais envoyer tout ton fichier "interfaces" complet ainsi que le résultat de la commande "ip addr show"
Peut-être qu'il considère icecast comme un device, c est ce qui s'en rapproche le plus dans ta config.
Peux-tu copier ici ton icecast.xml?
Sur quel host écoute-t-il? si c'est localhost ou epy.dyndns.com?
Il ne faut pas mettre quality et bitrate en même temps, c est soit l'un soit l'autre
Si c est pas ca:
oui, c est bien log_level "verbose" pour le debug
Sinon tu peux le lancer depuis une console en tapant:
mpd --no-daemon --verbose --stdout
A propos de ton fichier de conf, je commencerais par enlever tout ce qui n est pas essentiel comme:
password "YYYYYYYY@read,add,control,admin"
replaygain "album"
volume_normalization "yes"
audio_buffer_size "2048"
connection_timeout "60"
N'as tu bien que l'audio_output "shout" dans ton /etc/mpd.conf ?
Et si oui, est-ce que tu pourrais nous le donner (en virant le mot de passe)?
Et peut-être aussi lancer le daemon en mode debug
Autre chose, avec le client mpc, tu peux activer/désactiver avec les options enable/disable
Exemple chez moi:
moi@monpc ~% mpc disable 1
Output 1 (My ALSA Device) is disabled
Output 2 (My Shout Stream) is enabled
moi@monpc ~%
Tu peux tenter un startx après avoir arrêté GDM (ou autre), tu auras peut-être plus d'infos
Sinon, ca doit être un fichier de config de gnome (ou kde...) qui est corrompu, donc tu supprimes les fichiers de conf dans ton /root (genre .gnome .gconf ...) après les avoir sauvegardé au cas où
Normalement, cron envoie un mail pour avertir le user de l'échec de la commande. As-tu vérifié sa BAL?
J'ai essayé ta commande de test, elle passe avec zsh mais pas avec sh/bash qui est utilisé par CRON.
C'est normal que tu ne vois les paquets que dans un seul sens, pour le retour l'adresse destination est une adresse du WAN et elle est routée vers l'extérieur.
Quant au fait que tu reçoives beaucoup de paquets, c'est normal aussi :) ç'est parce que ça floodera tant que l'entrée sera présente dans la table ARP du switch (mais pas dans sa table MAC).
Pour Info, sur Cisco, c'est (de mémoire):
timeout table ARP: 4 heures
timeout table MAC: 5 minutes ...
normalement si tu ping le flooder, ça devrait s'arrêter (temporairement...)
Bon courage, je sais pas s'ils vont être très chaud pour modifier tous leurs switchs aussi facilement... mais normalement c est sans danger
Non, ça n'est pas tordu (c est assez classique en fait) et les serveurs n'ont pas a avoir plusieurs interfaces.
Je vais essayé de faire un petit schéma en espérant que ça passera bien:
tu essaies de joindre le serveur 2, sauf que switch1 est mettre VRRP sur ce VLAN donc ca part vers lui, ca passe par la rocade pour aboutir au serveur2.
Le retour, par contre, est directe: serveur2 - switch2 - routeur - WAN
Le problème c'est que les entrées de la table mac (faisant le lien entre @MAC et port du switch) disparaissent (timeout) beaucoup plus vite que celles de la table ARP (@MAC - @IP).
Et donc parfois, si le switch1 recoit un paquet a destination de serveur2 il a encore dans sa table ARP mais pas dans sa table MAC.
Il n'envoie pas de requete ARP, ca servirait à rien vu qu'il l'a toujours l'entrée dans sa table ARP, mais il ne sait pas par quelle interface balancer le paquet: méthode bourrin: il flood sur toutes les interfaces, y compris la rocade et donc serveur2 obtient bien son paquet. Par contre, serveur1 (qui est dans le même VLAN) l'a également reçu.
C'est assez effrayant qu'OVH dise que c'est "normal" qu'un client reçoive des paquets (peut-être confidentiel) d'un autre client...
Ca ressemble beaucoup à de l'unicast flooding.
En clair, quand le switch a une entrée dans ca table ARP correspondant à un quelconque serveur mais qu'il ne l'a pas dans sa table MAC, alors il flood sur tous ses ports appartenant au VLAN de ce serveur.
Ca arrive entre autre sur du traffic asymétrique (chemin différent à l'allée et au retour).
C'est du au fait que les tables MAC et ARP n'ont pas par défaut le même timeout.
Tu n'as pas besoin d'un AP, juste d'un client wifi. L'AP, c est la LB.
Je vois 2 solutions suivant ton budget.
-Un 2nd routeur avec interface wifi qui serait relié à la fois à ton réseau filaire et au réseau wifi du voisin (mais en client pas en AP).
-Tu équipes l'un des tes PC/serveurs d'une carte wifi et il jouera lui-même le rôle de passerelle/NAT.
Une fois ton choix fait, tu configures sur tes postes une 2nde route par défaut pointant vers cette nouvelle passerelle mais avec une métrique supérieure et le jour ou ta ligne FREE tombe, tu auras juste à arrêter/déconnecter ton routeur Zyxell.
J ai du mal à suivre, si tu peux le faire manuellement alors tu as juste à désactiver l'interface filaire de ton serveur puis activer son interface wifi configurée pour se connecter sur la LB.
Par contre, il faudra configurer des redirections de port sur la LB.
# KVMGT
Posté par nicolasi . En réponse au journal 3D pour VM. Évalué à 3.
Ça répond pas vraiment à ta question mais c est voisin et ça m'a l'air prometteur…
http://www.phoronix.com/scan.php?page=news_item&px=MTg1MzQ
Bon par contre, c est dédié Intel…
Et cela concerne la CG de l'hôte qui est "partagée" avec les VM.
D'après ce que je comprends (très loin d'être un spécialiste), il n y a pas de connecteur dédié et je ne vois pas comment bénéficier de l'accélération à part à travers une session spice (si c'est possible).
[^] # Re: On sais jamais...
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Alignment Error:
Alignment Error happens in IEEE 802.3(Ethernet) networks. It is an error that occurs when the total number of bits of a received frame is not divisible by eight. Alignment errors are usually caused by frame damage due to collisions and by misaligned reads and writes. For example, a two-byte read where the memory address is not an even multiple of two bytes is an alignment error. Alignment errors are caused by a software bug.
source: http://www.javvin.com/networkingterms/AlignmentError.html
Donc, à priori, il reçoit des paquets corrompus et n'en tient pas compte.
Ça pue! y a un bug soit dans le driver (peut-être résolu dans une version plus récente du noyau) soit dans le firmware du d-link (voir si il y a une version plus récente).
Essaie de désactiver l'autoneg et de forcer la vitesse en 10half avec ethtool.
Ça va ramer mais ça peut pas être pire...
[^] # Re: On sais jamais...
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
- tu reçois aléatoirement des réponses à tes paquets
- ça marche sous windows
- ça marche sur un autre réseau avec la même config
Peux-tu envoyer le résultat de la commande:
ethtool -S eth0
ethtool -t eth0
ethtool -i eth0
Peut-être un pb de nego, tu peux essayer de fixer la vitesse aux 2 extrémités?
Est-ce qu'il y a moyen de mettre à jour le noyau?
[^] # Re: ethtool
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Par contre, on voit que tu reçois des trucs sur eth0, est-ce que tu peux laisser traîner le tcpdump un peu plus longtemps pour voir ce que c'est?
[^] # Re: ethtool
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
Est-ce qu'elle est utilisée pour autre chose?
Est-ce que tu peux passer sur eth1?
[^] # Re: ethtool
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Est-ce que tu peux regarder les erreurs (ip -s link)
[^] # Re: Arp?
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
Est-ce que tu pourrais envoyer tout ton fichier "interfaces" complet ainsi que le résultat de la commande "ip addr show"
# ethtool
Posté par nicolasi . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Qu'est-ce que te renvoie la commande:
ethtool eth0
[^] # Re: mpd.conf + mpc
Posté par nicolasi . En réponse au message Mpd et icecast. Évalué à 1.
user "source" # optional
Tu ferais mieux de le commenter
[^] # Re: mpd.conf + mpc
Posté par nicolasi . En réponse au message Mpd et icecast. Évalué à 2.
Peux-tu copier ici ton icecast.xml?
Sur quel host écoute-t-il? si c'est localhost ou epy.dyndns.com?
[^] # Re: mpd.conf + mpc
Posté par nicolasi . En réponse au message Mpd et icecast. Évalué à 2.
Je changerais ça aussi (je me méfie des accents...)
genre "Varié" # optional
[^] # Re: mpd.conf + mpc
Posté par nicolasi . En réponse au message Mpd et icecast. Évalué à 2.
Si c est pas ca:
oui, c est bien log_level "verbose" pour le debug
Sinon tu peux le lancer depuis une console en tapant:
mpd --no-daemon --verbose --stdout
A propos de ton fichier de conf, je commencerais par enlever tout ce qui n est pas essentiel comme:
password "YYYYYYYY@read,add,control,admin"
replaygain "album"
volume_normalization "yes"
audio_buffer_size "2048"
connection_timeout "60"
Bon courage
# mpd.conf + mpc
Posté par nicolasi . En réponse au message Mpd et icecast. Évalué à 1.
N'as tu bien que l'audio_output "shout" dans ton /etc/mpd.conf ?
Et si oui, est-ce que tu pourrais nous le donner (en virant le mot de passe)?
Et peut-être aussi lancer le daemon en mode debug
Autre chose, avec le client mpc, tu peux activer/désactiver avec les options enable/disable
Exemple chez moi:
moi@monpc ~% mpc disable 1
Output 1 (My ALSA Device) is disabled
Output 2 (My Shout Stream) is enabled
moi@monpc ~%
# startx
Posté par nicolasi . En réponse au message Impossible de se loguer en root. Évalué à 2.
Tu peux tenter un startx après avoir arrêté GDM (ou autre), tu auras peut-être plus d'infos
Sinon, ca doit être un fichier de config de gnome (ou kde...) qui est corrompu, donc tu supprimes les fichiers de conf dans ton /root (genre .gnome .gconf ...) après les avoir sauvegardé au cas où
# mail?
Posté par nicolasi . En réponse au message Pas de tâches cron. Évalué à 1.
Normalement, cron envoie un mail pour avertir le user de l'échec de la commande. As-tu vérifié sa BAL?
J'ai essayé ta commande de test, elle passe avec zsh mais pas avec sh/bash qui est utilisé par CRON.
a+
Nicolas
[^] # Re: broadcast != flood
Posté par nicolasi . En réponse au message sécurité réseau chez OVH. Évalué à 1.
[^] # Re: broadcast != flood
Posté par nicolasi . En réponse au message sécurité réseau chez OVH. Évalué à 2.
Quant au fait que tu reçoives beaucoup de paquets, c'est normal aussi :) ç'est parce que ça floodera tant que l'entrée sera présente dans la table ARP du switch (mais pas dans sa table MAC).
Pour Info, sur Cisco, c'est (de mémoire):
timeout table ARP: 4 heures
timeout table MAC: 5 minutes ...
normalement si tu ping le flooder, ça devrait s'arrêter (temporairement...)
Bon courage, je sais pas s'ils vont être très chaud pour modifier tous leurs switchs aussi facilement... mais normalement c est sans danger
Nicolas
[^] # Re: broadcast != flood
Posté par nicolasi . En réponse au message sécurité réseau chez OVH. Évalué à 1.
[^] # Re: broadcast != flood
Posté par nicolasi . En réponse au message sécurité réseau chez OVH. Évalué à 6.
Je vais essayé de faire un petit schéma en espérant que ça passera bien:
serveur1 ----- switch1 ------------------
| |
| |
Rocade Routeur -------- WAN
| |
| |
serveur2 ----- switch2 ------------------
tu essaies de joindre le serveur 2, sauf que switch1 est mettre VRRP sur ce VLAN donc ca part vers lui, ca passe par la rocade pour aboutir au serveur2.
Le retour, par contre, est directe: serveur2 - switch2 - routeur - WAN
Le problème c'est que les entrées de la table mac (faisant le lien entre @MAC et port du switch) disparaissent (timeout) beaucoup plus vite que celles de la table ARP (@MAC - @IP).
Et donc parfois, si le switch1 recoit un paquet a destination de serveur2 il a encore dans sa table ARP mais pas dans sa table MAC.
Il n'envoie pas de requete ARP, ca servirait à rien vu qu'il l'a toujours l'entrée dans sa table ARP, mais il ne sait pas par quelle interface balancer le paquet: méthode bourrin: il flood sur toutes les interfaces, y compris la rocade et donc serveur2 obtient bien son paquet. Par contre, serveur1 (qui est dans le même VLAN) l'a également reçu.
C'est assez effrayant qu'OVH dise que c'est "normal" qu'un client reçoive des paquets (peut-être confidentiel) d'un autre client...
Nicolas
# broadcast != flood
Posté par nicolasi . En réponse au message sécurité réseau chez OVH. Évalué à 7.
Ca ressemble beaucoup à de l'unicast flooding.
En clair, quand le switch a une entrée dans ca table ARP correspondant à un quelconque serveur mais qu'il ne l'a pas dans sa table MAC, alors il flood sur tous ses ports appartenant au VLAN de ce serveur.
Ca arrive entre autre sur du traffic asymétrique (chemin différent à l'allée et au retour).
C'est du au fait que les tables MAC et ARP n'ont pas par défaut le même timeout.
http://www.cisco.com/en/US/products/hw/switches/ps700/produc(...)
La solution: initialiser le timeout des tables des différents switchs avec la même valeur.
Reste plus qu'à convaincre OVH... Bon courage ;)
Nicolas
# DNS?
Posté par nicolasi . En réponse au message iptables & Windows Update. Évalué à 2.
Si tu gères toi-même le DNS, tu dois pouvoir fixer l'adresse de update.microsoft.com.
[^] # Re: conflit d'adressage
Posté par nicolasi . En réponse au message Réunir deux réseaux locaux. Évalué à 3.
Je vois 2 solutions suivant ton budget.
-Un 2nd routeur avec interface wifi qui serait relié à la fois à ton réseau filaire et au réseau wifi du voisin (mais en client pas en AP).
-Tu équipes l'un des tes PC/serveurs d'une carte wifi et il jouera lui-même le rôle de passerelle/NAT.
Une fois ton choix fait, tu configures sur tes postes une 2nde route par défaut pointant vers cette nouvelle passerelle mais avec une métrique supérieure et le jour ou ta ligne FREE tombe, tu auras juste à arrêter/déconnecter ton routeur Zyxell.
[^] # Re: conflit d'adressage
Posté par nicolasi . En réponse au message Réunir deux réseaux locaux. Évalué à 1.
A-t-il une interface wifi?
Est-ce que l'un de tes équipements à une interface wifi?
[^] # Re: conflit d'adressage
Posté par nicolasi . En réponse au message Réunir deux réseaux locaux. Évalué à 2.
Par contre, il faudra configurer des redirections de port sur la LB.
# nouvelles questions
Posté par nicolasi . En réponse au message Le son pour un autre utilisateur sans quitter la session. Évalué à 1.
Est-ce que ca marche pour user1?
que donne la commande: ls -l /dev/dsp
PS: moi non plus je connais pas pulseaudio