WhiteCat a écrit 699 commentaires

Contribue-t-il à OpenStreetMap, puisque c'est utilisé sur jlm2017 ? Wikipedia ? Rapporte-il des bugs sur le bug tracker Debian ?

L’utilisation de logiciel libre n'implique pas de contribuer.

J'avais mal lu ton message, je croyais que c'était uniquement Linux qui était proposé au boot.
L'installateur de Mint a peut-être buggué et pas finalisé l'installation de grub.
Essaye de réinstaller Mint encore une fois.

Par rapport à ton PC, il date d'avant 2004 ? Si non, alors il est très certainement 64 bits.

Pourquoi 32 bits ?

Sinon, pour essayer de résoudre ton problème, tu peux nous poster le résultat de ces commandes dans un premier temps :
$ sudo parted -l ; sudo lsblk

Ton BIOS est configuré en mode UEFI ou CSM (= legacy) ?

Juste un tout petit bémol : au boot, après validation du menu GRUB, il me faut attendre 1mn30 pour pouvoir commencer à travailler.

Tu peux exécuter cette commande pour voir ce qui prends du temps à booter :
# systemd-analyze blame

Est-ce que ça signifie qu'on peut faire de l'OpenCL avec un pilote Libre?

Non c'est encore totalement à la ramasse si tu veux faire des trucs sérieux, genre minage.
Déjà même avec le pilote proprio c'est limite…

Un ajout notable en ce qui concerne le pilote AMDGPU est la possibilité d'overclocker son GPU grâce à la prise en charge d'OverDrive. Une fonctionnalité qui ravira joueurs et mineurs de tout poil.

Mouais, ce qui me ravirai surtout c'est de pouvoir downvolter le GPU ! Pour le minage c'est essentiel. L'overclocking on s'en fou.
Mais bon… AMD est encore une fois à côté de la plaque. Je me demande s'ils sont au courant que pour le minage leurs cartes sont majoritairement utilisées.

oui wireshark voit les paquets quand ils arrivent sur l'interface
donc AVANT le firewall.

OK c'est bon à savoir !

J'avais rajouté la "rule" de blocage pour la destination et la source en fait aussi.

ton pc fedora n'a pas encore d'adresse ip, il ne peut donc pas s'adresser à un serveur dhcp en spécifiant son @ip (celle du serveur), au lieu de ça, le pc client va envoyer un message en broadcast à toutes les machines du réseau, le premier serveur dhcp à répondre va te proposer une adresse ip

OK je vois ce que tu veux dire.
Cependant si je regarde mes traces réseaux Wireshark, je vois ma requête DHCP partir (de 0.0.0.0 vers 255.255.255.255) et une réponse revenir de mon serveur DHCP légitime (172.16.30.254). Donc si mon pare-feu bloque cette IP, je n'aurais pas du voir cette trame. Enfin je pense.
Ou alors Wireshark peut voir toutes les paquets/trames réseaux avant même que le pare-feu ne s'en occupe ?!

je ne sais pas si tu peux refuser l'offre venant d'un serveur spécifique, sur mon client dchp, j'ai vu des options whitelist/blacklist mais je n'ai pas essayé

Merci pour l'info. Je viens de tester et en effet ça marche bien ! J'ai pu blacklister mon serveur DHCP légitime.

en revanche, si tu as la main sur le serveur dhcp officiel, tu peux probablement le configurer pour ne pas communiquer avec l'@mac de ton pc fedora de test

J'ai la main dessus mais c'est un serveur DHCP intégré à un routeur D-Link et y'a pas d'option pour bloquer une machine à ce niveau. Dommage oui sinon ça aurait été plus simple !

Comme Wireshark donc. Mais ça ne m'aide en rien. Moi je veux forcer mon PC à communiquer avec un serveur DHCP inconnu, et pour ça je dois définitivement couper la communication entre mon PC et mon serveur DHCP légitime (afin qu'il ne me réponde pas).
Si mon PC obtient un bail DHCP de mon serveur DHCP légitime, mon PC ne fera plus beaucoup de requêtes DHCP et donc aucune raison de voir un autre serveur DHCP dans mes traces réseau.

Merci pour la suggestion, mais d'après la doc ça ne fait que parser (de manière plus complète je suppose) les dump de tcpdump. Donc je ne vois pas en quoi ça m'aide.
Ah et puis le paquet est pas dispo sur Fedora :/

Si tu sais pas ce que ça fait, listes les règles ça doit utiliser iptables, non ?

En effet, aucune trace de mon IP 172.16.30.254 avec "iptables --list"
Même après reboot tu PC.

Je ne suis pas sûr de bien comprendre ce que tu me suggères.
J'ai bien sûr déjà regardé ce qui passe sur le réseau de ma carte avec Wireshark, c'est pour ça que je vois bien des requêtes DNS passer de/vers 172.16.30.254 alors que le firewalld est censé bloquer tout le traffic de/vers cette IP.

Oui c’est bien la bonne zone et la bonne carte :

# firewall-cmd --get-default-zone
FedoraWorkstation

# firewall-cmd --get-active-zone
FedoraWorkstation
interfaces: wlp1s0

wlp1s0 est effectivement ma carte WiFi, sur laquelle je veux faire le blocage. La carte filaire n'est pas connectée.

Ben oui et ça me montre que les paquets passent tranquillement sans problème, je ne suis pas plus avancé :D

Je fais tout depuis la même machine (un PC portable sur Fedora 24).
L'adresse IP 172.16.30.254 que j'essaye de bloquer est un modem-routeur D-Link.

Oui c’est ce que je me suis dit aussi, du coup j'ai aussi ajouté le blocage "echo-request" mais c’est pareil.

Ba je veux pas bloquer ces ports. Je veux juste bloquer tout ce qui vient (ou va) vers 172.16.30.254.
Sur la doc Red Hat (enfin c'est juste un post de forum mais bon) c’est pas précisé qu'il faut spécifier des ports en plus : https://access.redhat.com/discussions/1342573

Ah ah OK j'avoue mon test est foireux :D
Ceci dit, j'ai toujours des paquets DNS qui passent très bien avec 172.16.30.254 donc le blocage ne fonctionne vraiment pas.

J'ai ajouté :
# firewalld-cmd --permanent --add-icmp-block=echo-reply

Mais le ping passe toujours aussi bien…

J'ai eu l’occasion d'avoir testé 3 clés USB WiFi :

=> Belkin F7D2102 : fonctionne nativement même avec un "vieux" kernel Fedora 17 (3.9+). Marche toujours aussi bien aujourd'hui sur Fedora 25 (kernel 4.7)
lsusb => ID 050d:2103 Belkin Components F7D2102 802.11n N300 Micro Wireless Adapter v3000 [Realtek RTL8192CU]

=> D-Link DWA-125 : ne fonctionne pas sur Fedora 25 (kernel 4.7)
lsusb => ID 2001:330f D-Link Corp.
C'est la version HW:D1 / FW:4.02 de ce modèle que j'ai testé.

=> TP-Link TL-WN725N : ne fonctionne pas sur Fedora 25 (kernel 4.7)
lsusb => ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
C'est la version 2.2 de ce modèle que j'ai testé.

Les fabricants semblent faire régulièrement de nouvelles versions de leur modèles, donc ils peuvent changer les puces WiFi entre différentes versions… Pas évident de choisir…

je suis pas super chaud pour màj le bios. J’ai un pote qui a briqué sa cm asus comme ça.

C'est pourtant bien une chose extrêmement importante à faire dans ton cas. Si ça se trouve le BIOS corrige un bug errata du chipset… comment savoir, les changelogs ASUS sont complètement bidons.
Je suis partisan de mettre à jour son BIOS quand il y a une mise à jour (sauf si le changelog est suffisamment explicite pour voir que cela n'est pas pertinent bien sûr).

À moins d'avoir une coupure électrique pendant les 2 minutes que dure le flash (grosso modo), c'est difficile de bousiller sa carte mère en mettant à jour son BIOS. Je me demande comment ton pote s'y est pris. Depuis des années j'ai mis à jour plusieurs dizaines de BIOS, de façon bien différente sans problème (màj via utilitaire Windows, via utilitaire DOS, via le BIOS + clé USB, via l'utilitaire flahsrom sur Linux sur des cartes mères déjà testées ou non, sur Linux avec les utilitaires HP et IBM pour serveurs, etc.).

Assures-toi juste de prendre une clé USB FAT32 que tu estimes fiable, copie ton BIOS dessus, fais un checksum du BIOS sur ton HDD et sur ta clé pour vérifier qu'elle est bien copiée dessus.

avec le noyau 4.6.0-0.bpo.1-686-pae (backports).

Tu as une raison particulière de fonctionner en 32 bits ?

J’ai aussi testé avec un livecd fedora

En 32 ou 64 bits ?

alors ma sortie audio est la mini jack vert de la carte mère

OK donc tu est bien sûr que tes enceintes ou casque fonctionne bien aussi ? :-)

visiblement il faudrait que j'installe une autre version de linux

C'est sûr que c'est un test essentiel pour déboguer ton problème. Surout que le noyau de ta version de Linux est relativement ancien. Bon normalement ça devrais fonctionner car ton chip son n'est pas très récent. Essaye quand même avec Fedora 24 ou Ubuntu 16.04/16.10 par exemple.

Deux choses supplémentaires :
- quelle est le modèle de ta carte mère ? Le constructeur a mal fait son boulot et l'information n'apparait pas dans ce que tu as fournis. Connaitre le modèle de ta carte mère permettrait de savoir s'il y a une mise à jour du BIOS disponible.
- Ton Linux est actuellement installé en 32 bits, ce qui n'est vraiment pas approprié car tu disposes d'un processeur 64 bits et de 8 Go de RAM. Actuellement ton PC est limité à 4 Go de RAM en fait, car en 32 bits c'est le maximum gérable.

Bonsoir,

Tu utilises quelle sortie audio ? Celle de la carte mère (mini jack vert) ou l'audio via l'HDMI de ta carte graphique ?

Il y a un outil sur Linux, qui s'appelle efibootmgr. Il est surement disponible sur le LiveCD d'Ubuntu.
Il permet de gérer les entrées de boot UEFI.

Donc démarres ton Uubntu, et supprimes l'entrée correspondante à ton ancien Ubuntu, ensuite mets l'entrée correspondant à Windows en primaire :

$ sudo efibootmgr
Cela va t'afficher l'état actuel du boot UEFI, par exemple (exemple pris du wiki d'Ubuntu fr car je ne suis pas sur un PC UEFI actuellement pour tester) :

BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,3001,0002,2001,2002,2004
Boot0000* Disque dur USB (UEFI) - Generic Flash Disk ACPI(a0341d0,0)PCI(14,0)USB(1,0)HD(1,3e,3b5b92,000bb565)RC
Boot0001* ubuntu HD(1,145800,82000,393abc6a-5b46-4392-a2fa-aebd5ee7d640)File(\EFI\ubuntu\shimx64.efi)
Boot0002* Windows Boot Manager HD(1,145800,82000,393abc6a-5b46-4392-a2fa-aebd5ee7d640)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS…….
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot3001* Internal Hard Disk or Solid State Disk RC

$ sudo efibootmgr --delete-bootnum 0001
Pour supprimer l'entrée UEFI d'Ubuntu (en prenant la sortie de l'exemple ci-dessus).

$ sudo efibootmgr --bootorder 3001,0002,2001,2002,2004
Pour mettre l'ordre de boot que tu veux. Ce qui compte c'est d'enlever l'ancien d'entrée d'Ubuntu (0001) si la commande "delete-bootnum" ne l'avait pas fait, et de mettre Windows dans les 1er choix aussi.

Par contre ce sera à toi de « gérer les dépendances » manuellement. Si tu veux installer un packageA qui dépend de packageB et packageC, il faudra d’abord installer B et C, etc… Pour être clair, s’il n’y a pas trop de dépendances cette méthode est viable mais s’il y en a beaucoup ce sera l’enfer.

Même pas ! Il suffit de télécharger les RPM, les mettre tous dans un même dossier, et lancer le gestionnaire de paquets (dnf) pour installer le paquet principal. dnf va trouver automatiquement les dépendances en utilisant les paquets présents dans le même dossier.