Greywolf

c'est bizarre, l'exécutable cdrecord appartient à l'utilisateur root (normal) mais également au groupe root (moins normal). Si tu remets les droits tel que l'exécutable de jeanbi cela change-t-il qqch? en root: chown root:cdwriter /usr/bin/cdrecord Ton utilisateur fait bien partie du groupe cdwriter? si tu exécutes k3b en tant qu'utilisateur root, obtiens tu le même résultat?

en tant que root, fait: chmod u+s `which cdrecord` et réessaie k3b

c'est quoi ton ecran? tu peux nous uploader ton fichier /etc/X11/XF86config-4 quelque part qu'on puisse y jeter un oeil?

tu peux nous donner le résultat de la commande suivante exécutée dans un terminal (programme Konsole sous KDE)? ls -l `which cdrecord`

kernel = noyau cheat codes = paramètres optionnels à passer au kernel lors du démarrage

iptables -L ne liste que les chaines de la table filter pour voir celles de la table nat: iptables -t nat -L j'avais commencé un topo iptables (plus pour m'amuser avec LateX par ailleurs) mais que je n'ai jamais eu le temps/courage de terminer, si ça t'intéresse de comprendre comment ça marche, c'est par là

Pour installer ton dongle wifi et à moins de disposer d'un pilote libre (marque? modèle?) il te faudra passer par ndiswrapper; y'a plusieurs sujets dans le forum OS Alternatifs sur ndiswrapper. Ensuite, une fois le dongle installé, il faudra installer wpasupplicant pour causer avec la livebox (encryption WPA-PSK)

update-pciids pour mettre à jour la base lspci (nécessite une connexion internet) les fichiers de conf de Xfree est /etc/X11/XF86Config-4 (pour xorg c'est xorg.conf) pour les pilotes, tu as le choix entre vesa, le pilote libre radeon (pas d'accélération 3D) ou installer les drivers proprio d'ati

Salut, content que ça marche. Pour la redirection de ports, ça se passe dans la table nat chaine PREROUTING exemple pour le cas d'un serveur web hébergé sur une machine interne d'adressage 192.168.0.3: iptables -t nat -A PREROUTING -i ppp0 -p tcp -dport www -j DNAT -to-destination 192.168.0.3:80 L'adresse de destination du paquet est modifié, il faut ensuite l'autoriser dans la chaine FORWARD de la table filter iptables -A ppp0-br0 -m state --state NEW -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT www est le port côté WAN (ici 80) et tu indiques le port de redirection avec l'adresse privée (ici c'est aussi 80) le port à indiquer dans la chaîne FORWARD est celui côté privé. //si tu veux éviter de saturer l'espace disque du routeur, il serait peut-être judicieux d'enlever la règle permettant de logger les paquets sortants; à moins que tu ne fasses un contrôle/effacement régulier du fichier de log ou à moins d'installer un demon syslog sur une de tes machines et de rediriger les logs de iptables vers celle ci. (mais je sais pas si ça existe sous windows)

alors là... j'en perds mon latin... surtout pour les temps de latence observés. se pourrait-t-il que cette version de DWB ait si peu de place que rajouter un script le perturbe autant? tu peux me donner le résultat de la commande df -h pour visualiser l'espace disque disponible ? Pour l'accès au net qui ne se fait pas, tout est pourtant en place... :-/ Si tu as toujours envie de faire des essais, on peut logger ce qui ne sort pas en rajoutant cette ligne dans la chaine log-and-drop iptables -A log-and-drop -i br0 -o ppp0 -j LOG juste avant de les dropper (ligne iptables -A log-and-drop -j DROP) et aller voir le fichier /var/log/syslog (ou /root/adsl.log) pour voir si effectivement c'est le pare-feu qui merdoie. Je pense aussi à un problème de MTU (la requête passe mais tu ne reçois pas la réponse); tu peux rajouter cette ligne à la chaine br0-ppp0 iptables -A br0-ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu juste avant la ligne iptables -A br0-ppp0 -p udp --dport domain -j ACCEPT //tu peux également me confirmer que le routage est bien activé? cat /proc/sys/net/ipv4/ip_forward doit te retourner 1 comme valeur //edit_bis: je viens de penser à ceci en revérifiant les screenshots: malgré la ligne pour https avec nom de domaine dans le script, la règle n'apparait pas dans la sortie de iptables -L car, je pense, le routeur n'a pas le droit d'interroger des serveurs de noms sur la zone internet => du coup, il pédale dans la choucroute pour interpréter la ligne Peut-être qu'en rajoutant cette règle dans OUTPUT, cela arrangera les choses: iptables -A OUTPUT -p udp --dport domain -j ACCEPT + déplacer les règles pour OUTPUT en début de script (avant la série des FORWARD) //edit_ter: avec le script chargé, arrives-tu à partir d'un des PC à faire une résolution de noms? nslookup www.zebulon.fr un ping sur www.zebulon.fr ? //rererere-edit: Si on veut que le routeur fasse une résolution DNS, il faut accepter le retour de connexion dans INPUT iptables -A ppp0-if -m state --state ESTABLISHED -j ACCEPT //j'ai refait le script que tu trouveras ici: fw.klb

si c'est l'astuce pour accélérer les ports COM dont tu parles, ceci n'est valable que pour les modems 56K branchés sur port série (ou modem PCI émulant un COM virtuel)

bon, c'était les LF alors. Pour ta question, le script réinitialise en effet toutes les règles préétablies et repart de zero à chaque fois qu'il est lancé. Si le script te plante la connexion (étrange, ça fonctionnait bien chez moi DHCP ethernet et wifi), il ne vaut mieux pas créer le lien qui lancerait le script systématiquement (et donc plus de connexion, plus de telnet, plus rien....). J'ai cru noté que ta version du dwb était plus récente que celle que j'avais (rapport au login/pass de l'invite telnet), peux-tu me donner le résultat de ifconfig et iptables -L pour ta config originale? //les lignes suivantes sont censées permettre un accès total au routeur depuis le LAN, étrange que cela t'ait planté la connexion telnet #Les connexions entrantes sur l'interface LAN sont autorisees iptables -A br0-if -p icmp -j icmp-acc iptables -A br0-if -j ACCEPT Comment as-tu rétabli ta connexion si cela avait planté? reset du routeur? Pour tes règles de NAT, il faudra en effet les recréer/inclure dans le script

#! /bin/sh indique l'interpréteur à utiliser: en l'occurence /bin/sh qui est un lien vers le shell du sytème (bash, csh, zsh,.....) => ne pas enlever les autres commentaires sont superflus mais aident à la compréhension du script. Si tu as créé ton fichier sous notepad (windows), il est fort probable que celui-ci ai placé des caractères ^LF et ^CR. Il faudrait convertir ce fichier avec dos2unix pour n'avoir que le carriage return (ou le line feed je sais plus): http://www.iconv.com/dos2unix.htm ou sinon utiliser l'éditeur de texte du shell du DWB-200 (vi ou pico je ne sais plus)

ah oui, en effet. Peut être est-ce du au partitionnement du DWB, certaines partitions étaient en lecture seule et on pouvait écrire sur d'autres (mais pas beaucoup car peu de place). Peut-être que /etc/init.d est placée dans une partition read-only et que je ne m'en souvienne plus. Pour ton erreur, je ne vais pas te faire l'affront de te demander si tu étais bien dans le répertoire contenant klb.fw avant d'essayer de le lancer. Comment as-tu fait pour créer le fichier, j e me souviens avoir galéré à cause de retour à la ligne intempestifs qui faisaient planter le script. Chaque ligne iptables .... ne doit tenir que sur une seule ligne (ou on rajoute un \ avant de faire retour chariot)

Le plus simple serait alors de recopier l'intégralité du script que j'avais laissé sur wlan-fr.net en modifiant uniquement la ligne pour https dans un fichier firewall.klb si tu veux. Une fois dans le répertoire contenant ce fichier (/etc/init.d en toute rigueur), Il faut le rendre exécutable chmod +x firewall.klb et le lancer ./firewall.klb vérification de l'existence de la chaine br0-ppp0 iptables -L br0-ppp0

peu de gens utilisent les serveurs imap; la plupart utilisent leur compte pop sur pop.free.fr

a priori, si tes PC obtiennent une adresse IP publique de ta freebox, c'est que celle ci n'est pas en mode routeur. Active le via la console d'administration sur http://adsl.free.fr Une fois le mode routeur activé, tes PC obtiendront via DHCP une adresse du type 192.168.0.x avec comme adresse de passerelle celle de la Freebox: 192.168.0.254

Quel est le mode d'authentification choisi sur le serveur VPN? si tu as choisi un système à clé assymétrique, il te faut en effet générer des certificats pour chaque client.

tu as essayé de changer de canal wifi?

http://forum.zebulon.fr/index.php?showtopic=88289 merci de continuer dans le même topic. Je présume qu'il s'agit soit d'un problème d'adressage IP sur ton interface wifi soit ta freebox qui n'est pas en mode routeur. Si tu peux répondre dans le topic original, merci.

oui, tu as compris le principe* mais si tu n'as que la règle pour le https dans la chaine br0-ppp0, tu n'iras pas loin (il manque au moins les requêtes DNS et l'acceptation des réponses aux requêtes dans une chaine ppp0-br0). Je pensais que tu avais recopié l'intégralité du script? * déclaration d"une chaine utilisateur iptables -N truc redirection vers la chaine utilisateur à partir des chaines de base avec un motif particulier iptables -A FORWARD -i eth0 -o ppp0 -j truc définition des différents filtrages applicables dans la chaine utilisateur iptables -A truc -p tcp -j accept iptables -A truc -p udp -j deny si aucune règle de la chaine utilisateur ne matche le paquet, celui ci est renvoyé dans la chaine de base à l'endroit à partir duquel il est parti.

normal, ceci fait partie de l'url et non du nom de domaine => erreur de syntaxe comme tu l'écris. Cependant, il est étrange qu'en ne donnant que le nom de domaine, le script passe bien mais que la connexion soit refusée..... Le script est appelé à chaque démarrage du routeur en dernière position et devrait donc être actif (je n'ai plus de DWB sous la main pour tester :-/); la première partie du script réinitialise les tables, crée les tables perso br0-ppp0, ppp0-br0 et log-and-drop (bien que cette dernière ne soit pas utilisée) et les appels aux tables perso se font via les premières lignes de la table FORWARD en fonction du sens des paquets. Si, en effet, tu n'utilisais que la ligne pour le port https et pas l'intégralité du script (donc br0-ppp0 n'était pas créée), il faut voir la structure de la table FORWARD pour y insérer la ligne pour la gestion de https. (iptables -L FORWARD)

255.255.255.255 est une adresse de diffusion large et n'est pas utilisable pour désigner une machine particulière. Tu peux nous fournir toutes les indications que te donne Outpost?

pour lancer un exécutable dans le répertoire courant, c'est: ./firewall.klb si j'en crois ta capture d'écran, le fichier est dans /etc; le lien symbolique doit alors pointer vers /etc/firewall.klb ln -s /etc/firewall.klb /etc/rc1.d/S99firewall.klb pour virer le lien: rm /etc/rc1.d/S99firewall.klb pour vérifier la chaine br0-ppp0 iptables -L br0-ppp0

iptables -A br0-ppp0 -m mac --mac-source XX:XX:XX:XX:XX:XX -s 192.168.1.201 -p tcp -d www.bidule.truc --dport 443 -j ACCEPT exact pas d'espace.