Peut-être un pb de nego, tu peux essayer de fixer la vitesse aux 2 extrémités ?
Pas sur le routeur, sur ma machine je pense que oui. Je vais googler.
Est-ce qu'il y a moyen de mettre à jour le noyau ?
Sans réseau ça risque d'être difficile. J'ai installé quelques utilitaires manquants nécessaires à vos diagnostics en récupérant le paquet sur clé usb et en installant par un dpkg -i, pour une màj du noyau ça risque d'être plus coton...
En single-user : je vois la passerelle, mais le ping reste aléatoire (1 à 3 paquets sur 5), et parfois très long ( > 1 s).
J'accède aux DNS de la passerelle et à sortir, mais lentement après le tcpdump j'avais la page d'accueil de debian.org, renommée pour sa lourdeur ;), sans css ni images.
Je n'ai pas essayé de rebooter la passerelle. Les deux machines Win XP installées derrière ont l'accès sans problème : depuis la machine d'où j'écris j'ai un ping 1ms, 100 % de réussite.
Ça marche vraiment sur le même PC avec un autre OS, sans toucher à rien.
Le pare-feu n'a pas de raison de poser problème. Il est en configuration par défaut, et « chez moi ça marche » : dans mon LAN habituel où la configuration réseau est la même, aucun souci. La session Win accède au net sans avoir touché à la config IP statique.
Ma Debian est mise à jour régulièrement. Contrairement à ce que j'indiquais plus haut, c'est une testing (squeeze) avec quelques morceaux de unstable. Ces morceaux sont normalement des programmes desktop, pas des outils systèmes ou d'administration.
Je viens de tester avec un noyau 2.6.22 : j'ai d'abord eu 3 ping reçu sur 5, durée moyenne 330 ms, mini 1 ms, maxi : 1 s !
Pour la passerelle, c'est un routeur domestique D-Link, donc le tcpdump de la passerelle, il faut oublier :(
Chez moi c'est un peu pareil :
route Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.50.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
default 192.168.50.1 0.0.0.0 UG 0 0 0 eth0
route -n Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.50.1 0.0.0.0 UG 0 0 0 eth0
L'envoi de la requête en utilisant le nom d'hôte de la machine et non son IP est-il la cause de cette absence de réponse, ma machine n'étant pas dans le domaine [...].homeip.net. Si oui, la solution est-elle simplement de commenter la ligne 192.168.50.12 cf51.[...].homeip.net dans le fichier /etc/hosts ?
Heu, j'ai dit une connerie là, non ? La réponse est envoyée vers l'adresse MAC à l'origine de la requête ?
J'avais bien purgé le cache suite à ton commentaire précédent.
Après mes nouvelles tentatives, arp -an me renvoie : ? (192.168.50.1) at [incomplete] on eth0
Tu avais raison, le problème semble bien se situer au niveau d'ARP, mais pas au niveau cache.
* Incomplete est entre < et >, et semble trop ressembler à une balise html pour passer tel quel.
Si je lis bien, la passerelle ne renvoie pas de réponse... ou la réponse n'arrive pas.
L'envoi de la requête en utilisant le nom d'hôte de la machine et non son IP est-il la cause de cette absence de réponse, ma machine n'étant pas dans le domaine [...].homeip.net. Si oui, la solution est-elle simplement de commenter la ligne 192.168.50.12 cf51.[...].homeip.net
dans le fichier /etc/hosts ?
Merci pour la piste, elle permet d'éliminer la mise en cause du cache ARP : le fichier /proc/net/arp est vide, est les commandes arp -d 192.168.50.1 et arp -d tux-server me retournent Pas d'entrée ARP pour 192.168.50.1, resp. tux-server.
Le déchargement /rechargement du pilote r8169 du noyau suivi d'un /etc/init.d/networking start ne fonctionne pas non plus.
Il peut accéder à d'autres fichiers sans en avoir l'autorisation.
Deux solutions qui peuvent être combinées :
- la valeur de ta variable (le nom du fichier téléchargé) doit correspondre à un motif de regex tel que, par exemple, tout premier caractère soit une lettre ou un chiffre et les derniers caractères .ogg
- la valeur de ta variable doit également être un nom de fichier musical enregistré dans la table correspondante de la BDD
PAS DE COOKIE !
Oui, j'ai bien compris, encore qu'à cette heure j'en grignoterai bien un. Le message que j'ai essayé de faire passer, c''est qu'en php, il existe de méthodes de propagation d'un id de session :
- première méthode, celle interdite : un cookie sur le poste client
- seconde méthode, ma proposition dans mon poste précédent : l'id est propagé via la constante SID, tous tes liens internes deviennent : href="mon_lien.php?sessionid=mon_id_de_session_kinépadanzincookie"
En php, un identifiant de session peut-être propagé par un cookie ou par l'URL via get. session.use_trans_sid et SID (la constante php, pas la branche Debian) sont tes amis.
Remarques :
- pourquoi rechercher une solution fonctionnant indifféremment sous Apache et IIS ? Si tu cherches à construire un petit site web, et non une solution universelle qui concurrencera iTunes, il me semble indispensable de définir en amont l'environnement de production. Si ton projet doit réellement pouvoir être déployé indifféremment sous Apache et IIS, prends-tu bien en compte les différences entre les deux serveurs ? -Indexes, deny from all sonne pour moi comme une directive Apache... mais je ne connais pas IIS :)
- ta contrainte sur l'absence de cookie utilisateur est-elle justifiée ? Le passage d'un id de session via l'URL, quoique possible, ne me semble pas une solution propre.
- Sous Apache, l'utilisation de mod_rewrite te permettra d'utiliser une URL comme mon_site_de_zik.com/download/mon_fichier.mp3, plus propre que mon_site_de_zik.com/push.php?file=mon_fichier.mp3
- que se passe-t-il si l'utilisateur modifie l'URL à la main, genre push.php?file=index.php ?
- enfin, un conseil, révise le chapitre sessions de la doc php :)
Les contributeurs Framalang, petites mains industrieuses derrière les traductions du Framablog, recourent à une organisation digne d'un processus métier (foutaises !). Le passage par les étapes successives : traduction, relecture, validation, permet d'éviter bien des écueils.
Face aux difficultés linguistiques ou techniques, les connaissances de chacun s'avèrent souvent complémentaires, et assurent à minima une traduction qui tient la route.
La mutualisation appliqué à la traduction, en quelque sorte, même si le résultat final reste corrélé avec les compétences des contributeurs bénévoles... et leur nombre !
Une Optical Network Termination, (abbrév. ONT) est une unité de réseau optique employée pour le raccordement par fibre jusqu’au domicile (FTTH, Fiber To The Home), qui incorpore la fonction d’accès au terminal de l’utilisateur.
Postulat : ton script php est appelé par /etc/cron.monthly.
Pourrais-tu ensuite clarifier ta question : souhaites-tu que le mail soit envoyé par ton script php, auquel cas, recours à la fonction mail() de php, ou bien, souhaites-tu procéder autrement, comme par exemple en redirigeant la sortie du script php vers un fichier temporaire dont le contenu serait récupéré et envoyé par mail via un script bash ?
Je trouve à cette dernière solution un désagréable côté usine à gaz, mais elle autorise le log de la valeur de retour.
Je pense utiliser MySQL comme SGBDR, sans avoir définitivement arrêté ce choix (pourquoi pas PostgreSQL, c'est vendredi ;-) ).
Comme l'appli attaque la BDD via un ORM (Doctrine), le choix n'est pas critique à ce stade.
Ta proposition de table de tags ne me semble utilisable que pour les mots clefs, les autres champs ont, selon le standard IPTC, des tailles très variables (de mémoire, 2000 caractères pour la légende).
En revanche, la remarque sur l'utilisation de vues pour masquer la structure sous-jacente est très pertinente :-)
il peut y avoir plusieurs villes portant le même nom dans un même pays
L'écueil me semble contournable en fixant dans la table City une contrainte d'unicité sur la paire name, state_id : avec ça je dois pouvoir gérer (presque) tous les homonymes.
[^] # Re: On sais jamais...
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
ethtool -S eth0
NIC statistics:tx_packets: 42
rx_packets: 1
tx_errors: 0
rx_errors: 5
rx_missed: 0
align_errors: 655
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 1
broadcast: 0
multicast: 0
tx_aborted: 0
tx_underrun: 0
ethtool -t eth0
Cannot test: Operation not supportedethtool -i eth0
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:02:01.0
Peut-être un pb de nego, tu peux essayer de fixer la vitesse aux 2 extrémités ?
Pas sur le routeur, sur ma machine je pense que oui. Je vais googler.
Est-ce qu'il y a moyen de mettre à jour le noyau ?
Sans réseau ça risque d'être difficile. J'ai installé quelques utilitaires manquants nécessaires à vos diagnostics en récupérant le paquet sur clé usb et en installant par un dpkg -i, pour une màj du noyau ça risque d'être plus coton...
[^] # Re: On sais jamais...
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
J'accède aux DNS de la passerelle et à sortir, mais lentement après le tcpdump j'avais la page d'accueil de debian.org, renommée pour sa lourdeur ;), sans css ni images.
16:47:05.939797 IP 192.168.50.12.43894 > 213.129.232.18.80: Flags [F.], seq 447400385, ack 1204617074, win 227, options [nop,nop,TS val 10829 ecr 502396089,nop,nop,sack 2 {5761:7201}{1441:4321}], length 016:47:06.012929 IP 213.129.232.18.80 > 192.168.50.12.43894: Flags [.], ack 1, win 54, options [nop,nop,TS val 502418747 ecr 10829,nop,nop,sack 1 {0:1}], length 0
16:47:07.099679 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 1, length 64
16:47:08.105925 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 2, length 64
16:47:08.106974 IP 192.168.50.1 > 192.168.50.12: ICMP echo reply, id 3338, seq 2, length 64
16:47:09.107094 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 3, length 64
16:47:10.113902 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 4, length 64
16:47:11.121897 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 5, length 64
16:47:13.783794 IP 192.168.50.12.43893 > 213.129.232.18.80: Flags [F.], seq 439056781, ack 1191831842, win 115, options [nop,nop,TS val 12790 ecr 502399606], length 0
16:47:15.090378 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46
16:47:15.090395 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28
16:48:02.847794 IP 192.168.50.12.43889 > 213.129.232.18.80: Flags [F.], seq 152404176, ack 913552227, win 137, options [nop,nop,TS val 25056 ecr 502396640], length 0
16:48:07.180401 IP 192.168.50.12.49977 > 192.168.50.1.53: 8942+ A? www.debian.org. (32)
16:48:07.180450 IP 192.168.50.12.49977 > 192.168.50.1.53: 44564+ AAAA? www.debian.org. (32)
16:48:07.202770 IP 192.168.50.12.54310 > 192.168.50.1.53: 8853+ A? www.w3.org. (28)
16:48:07.202954 IP 192.168.50.12.54310 > 192.168.50.1.53: 36915+ AAAA? www.w3.org. (28)
16:48:07.203288 IP 192.168.50.12.57857 > 192.168.50.1.53: 62188+ A? jigsaw.w3.org. (31)
16:48:07.203376 IP 192.168.50.12.57857 > 192.168.50.1.53: 8406+ AAAA? jigsaw.w3.org. (31)
16:48:07.280480 IP 192.168.50.1.53 > 192.168.50.12.57857: 8406 0/1/0 (82)
16:48:07.847786 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
16:48:08.847786 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
16:48:09.847836 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
16:48:12.187788 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
16:48:13.187793 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
16:48:13.188406 ARP, Reply 192.168.50.1 is-at 00:22:b0:89:05:68, length 46
16:48:13.188415 IP 192.168.50.12.54310 > 192.168.50.1.53: 8853+ A? www.w3.org. (28)
16:48:13.188418 IP 192.168.50.12.54310 > 192.168.50.1.53: 36915+ AAAA? www.w3.org. (28)
16:48:13.188422 IP 192.168.50.12.57857 > 192.168.50.1.53: 62188+ A? jigsaw.w3.org. (31)
16:48:13.719078 IP 192.168.50.100.137 > 192.168.50.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:48:17.188664 IP 192.168.50.12.33302 > 192.168.50.1.53: 16715+ A? www.debian.org. (32)
16:48:17.188704 IP 192.168.50.12.33302 > 192.168.50.1.53: 44952+ AAAA? www.debian.org. (32)
16:48:17.208801 IP 192.168.50.12.50629 > 192.168.50.1.53: 52536+ A? www.w3.org. (28)
16:48:17.208840 IP 192.168.50.12.50629 > 192.168.50.1.53: 2890+ AAAA? www.w3.org. (28)
16:48:17.208973 IP 192.168.50.12.57857 > 192.168.50.1.53: 62188+ A? jigsaw.w3.org. (31)
16:48:22.189852 IP 192.168.50.12.33302 > 192.168.50.1.53: 16715+ A? www.debian.org. (32)
16:48:22.189891 IP 192.168.50.12.33302 > 192.168.50.1.53: 44952+ AAAA? www.debian.org. (32)
16:48:22.212889 IP 192.168.50.12.50629 > 192.168.50.1.53: 52536+ A? www.w3.org. (28)
16:48:22.212925 IP 192.168.50.12.50629 > 192.168.50.1.53: 2890+ AAAA? www.w3.org. (28)
16:48:22.214062 IP 192.168.50.12.52300 > 192.168.50.1.53: 62445+ A? jigsaw.w3.org. (31)
^C
39 packets captured
39 packets received by filter
0 packets dropped by kernel
[^] # Re: ethtool
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
[^] # Re: On sais jamais...
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:50:57.756036 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:52:01.262570 IP 192.168.50.100 > 224.0.0.1: ICMP echo request, id 0, seq 0, length 40
15:52:50.760030 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:52:51.760034 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:52:52.600286 IP6 fe80::20b:97ff:fea0:bc1f.5353 > ff02::fb.5353: 0 [3q][|domain]
15:52:52.600458 IP 192.168.50.12.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _http._tcp.local. PTR (QM)? _ftp._tcp.local.[|domain]
15:52:52.760038 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:54:50.760032 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:54:50.760663 ARP, Reply 192.168.50.1 is-at 00:22:b0:89:05:68, length 46
15:54:50.760675 IP 192.168.50.12.34861 > 192.168.50.1.80: Flags [P.], seq 3738846783:3738847180, ack 2458630106, win 46, options [nop,nop,TS val 131189 ecr 24647403], length 397
15:56:50.756083 IP 192.168.50.12.34861 > 192.168.50.1.80: Flags [P.], seq 0:397, ack 1, win 46, options [nop,nop,TS val 161189 ecr 24647403], length 397
15:56:51.756039 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46
15:56:51.756060 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28
15:56:51.756688 IP 192.168.50.1.80 > 192.168.50.12.34861: Flags [.], ack 397, win 5792, options [nop,nop,TS val 24691451 ecr 161189,nop,nop,sack 1 {0:397}], length 0
15:57:08.604273 IP6 fe80::20b:97ff:fea0:bc1f.5353 > ff02::fb.5353: 0 [3q][|domain]
15:57:08.604444 IP 192.168.50.12.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _http._tcp.local. PTR (QM)? _ftp._tcp.local.[|domain]
15:57:32.019943 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 309
15:57:33.013433 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 380
15:57:33.119433 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 380
15:57:33.673531 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 362
15:57:33.779309 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 362
15:59:01.864257 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 2430655162:2430656610, ack 3392990277, win 5792, options [nop,nop,TS val 24704564 ecr 50338], length 1448
15:59:01.864350 IP 192.168.50.12.34860 > 192.168.50.1.80: Flags [.], ack 1448, win 175, options [nop,nop,TS val 193966 ecr 24704564,nop,nop,sack 1 {4344:7240}], length 0
15:59:02.074165 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 1448:2896, ack 1, win 5792, options [nop,nop,TS val 24704585 ecr 193966], length 1448
15:59:02.074238 IP 192.168.50.12.34860 > 192.168.50.1.80: Flags [.], ack 2896, win 198, options [nop,nop,TS val 194018 ecr 24704585,nop,nop,sack 1 {4344:7240}], length 0
15:59:02.284121 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 2896:4344, ack 1, win 5792, options [nop,nop,TS val 24704606 ecr 194018], length 1448
15:59:02.284195 IP 192.168.50.12.34860 > 192.168.50.1.80: Flags [.], ack 7240, win 220, options [nop,nop,TS val 194071 ecr 24704606], length 0
15:59:06.864030 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:59:07.864035 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:59:08.864031 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:59:28.949563 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 7240:8688, ack 1, win 5792, options [nop,nop,TS val 24707273 ecr 194071], length 1448
15:59:28.952034 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:59:29.952036 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
15:59:30.952033 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
16:00:05.823102 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46
16:00:05.823124 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28
16:00:57.573932 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46
16:00:57.573954 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28
38 packets captured
38 packets received by filter
0 packets dropped by kernel
Je vais installer arping et voir ce que ça me raconte...
Merci.
[^] # Re: On sais jamais...
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Je n'ai pas essayé de rebooter la passerelle. Les deux machines Win XP installées derrière ont l'accès sans problème : depuis la machine d'où j'écris j'ai un ping 1ms, 100 % de réussite.
Ça marche vraiment sur le même PC avec un autre OS, sans toucher à rien.
Le pare-feu n'a pas de raison de poser problème. Il est en configuration par défaut, et « chez moi ça marche » : dans mon LAN habituel où la configuration réseau est la même, aucun souci. La session Win accède au net sans avoir touché à la config IP statique.
Ma Debian est mise à jour régulièrement. Contrairement à ce que j'indiquais plus haut, c'est une testing (squeeze) avec quelques morceaux de unstable. Ces morceaux sont normalement des programmes desktop, pas des outils systèmes ou d'administration.
Je viens de tester avec un noyau 2.6.22 : j'ai d'abord eu 3 ping reçu sur 5, durée moyenne 330 ms, mini 1 ms, maxi : 1 s !
Pour la passerelle, c'est un routeur domestique D-Link, donc le tcpdump de la passerelle, il faut oublier :(
Merci !
[^] # Re: Arp?
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
J'ai forcé avec la MAC du routeur :
arp -s 192.168.50.1 MA:C:du:r:ou:te:urdu coup, ip neigh show me retourne
192.168.50.1 dev eth0 lladdr MA:C:du:r:ou:te:urMais le routeur ne réponde toujours pas à mes pings, et impossible d'accèder à son interface de gestion.
:(
[^] # Re: ethtool
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Pour tester en filaire, c'est moyen ;-)
[^] # Re: ethtool
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
cf51:/home/balzane# ip -s link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
8010 112 0 0 0 0
TX: bytes packets errors dropped carrier collsns
8010 112 0 0 0 0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0b:97:a0:bc:1f brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
5589 41 0 0 0 0
TX: bytes packets errors dropped carrier collsns
42700 337 0 0 0 0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:12:f0:49:b0:2b brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
7190 44 0 0 0 0
[^] # Re: A quoi correspond la route vers link-local ?
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.50.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
default 192.168.50.1 0.0.0.0 UG 0 0 0 eth0
route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.50.1 0.0.0.0 UG 0 0 0 eth0
/etc/hosts
127.0.0.1 cf51.[...].homeip.net localhost.[...].homeip.net cf51 localhost
#127.0.1.1 cf51.[...].homeip.net cf51
192.168.50.12 cf51.[...].homeip.net cf51
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
#Local network
192.168.50.1 tux-server
[^] # Re: Arp?
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
Heu, j'ai dit une connerie là, non ? La réponse est envoyée vers l'adresse MAC à l'origine de la requête ?
[^] # Re: Arp?
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
Après mes nouvelles tentatives, arp -an me renvoie :
? (192.168.50.1) at [incomplete] on eth0Tu avais raison, le problème semble bien se situer au niveau d'ARP, mais pas au niveau cache.
* Incomplete est entre < et >, et semble trop ressembler à une balise html pour passer tel quel.
[^] # Re: ethtool
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
cf51:/home/balzane# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
[^] # Re: Arp?
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:26:40.259468 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28
17:26:41.259467 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28
17:26:42.259469 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28
17:26:43.275497 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28
17:26:44.275465 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28
17:26:45.275471 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
Si je lis bien, la passerelle ne renvoie pas de réponse... ou la réponse n'arrive pas.
L'envoi de la requête en utilisant le nom d'hôte de la machine et non son IP est-il la cause de cette absence de réponse, ma machine n'étant pas dans le domaine [...].homeip.net. Si oui, la solution est-elle simplement de commenter la ligne
192.168.50.12 cf51.[...].homeip.netdans le fichier /etc/hosts ?
[^] # Re: Arp?
Posté par balzane . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 1.
Le déchargement /rechargement du pilote r8169 du noyau suivi d'un /etc/init.d/networking start ne fonctionne pas non plus.
[^] # Re: SID
Posté par balzane . En réponse au message Accès réservé à des fichiers vendus. Évalué à 3.
[^] # Re: SID
Posté par balzane . En réponse au message Accès réservé à des fichiers vendus. Évalué à 4.
Deux solutions qui peuvent être combinées :
- la valeur de ta variable (le nom du fichier téléchargé) doit correspondre à un motif de regex tel que, par exemple, tout premier caractère soit une lettre ou un chiffre et les derniers caractères .ogg
- la valeur de ta variable doit également être un nom de fichier musical enregistré dans la table correspondante de la BDD
PAS DE COOKIE !
Oui, j'ai bien compris, encore qu'à cette heure j'en grignoterai bien un. Le message que j'ai essayé de faire passer, c''est qu'en php, il existe de méthodes de propagation d'un id de session :
- première méthode, celle interdite : un cookie sur le poste client
- seconde méthode, ma proposition dans mon poste précédent : l'id est propagé via la constante SID, tous tes liens internes deviennent : href="mon_lien.php?sessionid=mon_id_de_session_kinépadanzincookie"
# SID
Posté par balzane . En réponse au message Accès réservé à des fichiers vendus. Évalué à 6.
Remarques :
- pourquoi rechercher une solution fonctionnant indifféremment sous Apache et IIS ? Si tu cherches à construire un petit site web, et non une solution universelle qui concurrencera iTunes, il me semble indispensable de définir en amont l'environnement de production. Si ton projet doit réellement pouvoir être déployé indifféremment sous Apache et IIS, prends-tu bien en compte les différences entre les deux serveurs ? -Indexes, deny from all sonne pour moi comme une directive Apache... mais je ne connais pas IIS :)
- ta contrainte sur l'absence de cookie utilisateur est-elle justifiée ? Le passage d'un id de session via l'URL, quoique possible, ne me semble pas une solution propre.
- Sous Apache, l'utilisation de mod_rewrite te permettra d'utiliser une URL comme mon_site_de_zik.com/download/mon_fichier.mp3, plus propre que mon_site_de_zik.com/push.php?file=mon_fichier.mp3
- que se passe-t-il si l'utilisateur modifie l'URL à la main, genre push.php?file=index.php ?
- enfin, un conseil, révise le chapitre sessions de la doc php :)
[^] # Re: j'imagine
Posté par balzane . En réponse au journal Le linux embarqué de l'A380 a planté en plein vol. Évalué à 10.
Attention, les programmes suivants ont causé une erreur irrécupérable :
MS Flight Simulator EADS A380 edition - fly-high.exe
Codes d'erreur : #0down #0fall
Cliquez sur « OK » pour redémarrer le système, « Annuler » pour déboguer l'application.
[^] # Re: salu
Posté par balzane . En réponse au journal Sabayon Linux cherche des traducteurs français. Évalué à 4.
Face aux difficultés linguistiques ou techniques, les connaissances de chacun s'avèrent souvent complémentaires, et assurent à minima une traduction qui tient la route.
La mutualisation appliqué à la traduction, en quelque sorte, même si le résultat final reste corrélé avec les compétences des contributeurs bénévoles... et leur nombre !
[^] # Re: moi decidement pas comprendre aujourd'hui
Posté par balzane . En réponse au message La fibre chez qui ?. Évalué à 2.
Une Optical Network Termination, (abbrév. ONT) est une unité de réseau optique employée pour le raccordement par fibre jusqu’au domicile (FTTH, Fiber To The Home), qui incorpore la fonction d’accès au terminal de l’utilisateur.
Source : Wikipédia.
[^] # Re: pfiouuuu
Posté par balzane . En réponse au journal Unix a 40 ans !. Évalué à 10.
--> []
[^] # Re: À clarifier
Posté par balzane . En réponse au message EXIM pour envoie de mail. Évalué à 3.
Il me reste définitivement des progrès à faire en admin :~|
# À clarifier
Posté par balzane . En réponse au message EXIM pour envoie de mail. Évalué à 2.
Postulat : ton script php est appelé par /etc/cron.monthly.
Pourrais-tu ensuite clarifier ta question : souhaites-tu que le mail soit envoyé par ton script php, auquel cas, recours à la fonction mail() de php, ou bien, souhaites-tu procéder autrement, comme par exemple en redirigeant la sortie du script php vers un fichier temporaire dont le contenu serait récupéré et envoyé par mail via un script bash ?
Je trouve à cette dernière solution un désagréable côté usine à gaz, mais elle autorise le log de la valeur de retour.
[^] # Re: table de tags
Posté par balzane . En réponse au message Structure de BDD pour une base photo. Évalué à 2.
Comme l'appli attaque la BDD via un ORM (Doctrine), le choix n'est pas critique à ce stade.
Ta proposition de table de tags ne me semble utilisable que pour les mots clefs, les autres champs ont, selon le standard IPTC, des tailles très variables (de mémoire, 2000 caractères pour la légende).
En revanche, la remarque sur l'utilisation de vues pour masquer la structure sous-jacente est très pertinente :-)
[^] # Re: le design d'abord !
Posté par balzane . En réponse au message Structure de BDD pour une base photo. Évalué à 2.
il peut y avoir plusieurs villes portant le même nom dans un même pays
L'écueil me semble contournable en fixant dans la table City une contrainte d'unicité sur la paire name, state_id : avec ça je dois pouvoir gérer (presque) tous les homonymes.