[réseau] eth0 flapping à mort (résolu)
[réseau] eth0 flapping à mort (résolu)
Bonjour les loutres,
je vais commencer l'histoire par un truc qui n'a peut être rien à voir mais sait-on jamais!
Ma machine principal est toujours allumé et accessible en ssh depuis mon boulot.
Je m'y connecte régulièrement pour lancer un petit yaourt -Syu des familles.
La machine est up depuis plusieurs jours (faudrait que je scrute les logs pour déterminer si besoin) et lundi, mardi, par de soucis particulier.
Aujourd'hui, c'est la merde: problème d'écriture dans /tmp, monté en RO, blablabla...
Chelou !!!
Je lance un touch /tmp/macouille et en effet, c'est la merde.
Je teste dans mon home (partition séparé), idem.
Comme un nigaud, je reboot. Erreur
Ce soir, de retour chez moi, je constate qu'au reboot la machine n'a pas put monter ma partion /dev/sda3 (mon /).
Évidemment, le busybox disponible ne me fournis pas de fsck.
Un reboot sur un ctkarch plus tart, le fsck.ext4 me parle d'une feature "FEATURE_I15".
e2fsck me dit qu'il y trop vieux pour certaines feature du fs, blablabla...
Un coup de debugfs pour retirer cette feature et fsck est enfin d'accord pour le faire.
Évidemment, c'est la cata, le bordel, la misère. Bref, pleins d'erreurs (mais corrigé).
Reboot sur ma arch à moi, fsck des autres fs et me revoilà sur mon bureau.
Plus de peur que de mal mais va falloir que je creuse l'affaire.
Nous voilà maintenant à mon soucis du moment: le link sur ma connexion est très très versatile.
ping de l'ip d'eth0 ok mais ping de la passerelle KO.
une boucle de mii-tool eth0 avec un sleep à 0.1 me montre ceci: environ 0,8s de up puis environ 1,5s de down, en boucle.
lspci m'indique une carte realtek RTL8111/8168B (rev 03).
lsmod m'indique le module r8169.
un peu de google plus tard, je vois des posts du ce genre de problème et l'existence du module r8168. A là bonne heure!
Je le télécharge depuis un autre pc, et l'installe avec un pacman -U depuis une clef usb.
Je pense bien à blacklister le r8169 et plein d'espoir décharge le pourri, charge le nouveau, relance le daemon network. Pareil.
Pris d'un doute, je reboot. Pareil.
J'ai testé de forcer les vitesses/duplex avec ethtool mais ça reste foireux. Par exemple, en 10Mbit half duplex, le lien reste up mais je ne ping toujours pas ma passerelle ou d'autres machines du même lan.
Encore plus drôle, je dispose d'une mythtv box sous archlinux (en i686 par contre) qui dispose également du même contrôleur réseau, avec le noyau juste précédent (j'ai préféré ne pas prendre le risque pour le moment d'y lancer un yaourt -Syu...). Le module chargé est le r8169 et même si (très très) ponctuellement on retrouve des link down/link up dans les logs, pas de problème particulier.
J'ai tester un autre câble, les autres prise rj45 de ma vieille freebox v5, redémarré cette dernière, downgradé le kernel jusqu'à la version n-2 du moment, sans plus de succès.
A noter également qu'avec ctkarch en v0.7 et un noyau 2.6.37 (de mémoire), le problème de lien reste entier. J'ai également vu un option dans le bios pour tester le lien réseau durant la POST et même là, indépendamment de tout OS, ça foire.
Z'avez des idées ?
je vais commencer l'histoire par un truc qui n'a peut être rien à voir mais sait-on jamais!
Ma machine principal est toujours allumé et accessible en ssh depuis mon boulot.
Je m'y connecte régulièrement pour lancer un petit yaourt -Syu des familles.
La machine est up depuis plusieurs jours (faudrait que je scrute les logs pour déterminer si besoin) et lundi, mardi, par de soucis particulier.
Aujourd'hui, c'est la merde: problème d'écriture dans /tmp, monté en RO, blablabla...
Chelou !!!
Je lance un touch /tmp/macouille et en effet, c'est la merde.
Je teste dans mon home (partition séparé), idem.
Comme un nigaud, je reboot. Erreur
Ce soir, de retour chez moi, je constate qu'au reboot la machine n'a pas put monter ma partion /dev/sda3 (mon /).
Évidemment, le busybox disponible ne me fournis pas de fsck.
Un reboot sur un ctkarch plus tart, le fsck.ext4 me parle d'une feature "FEATURE_I15".
e2fsck me dit qu'il y trop vieux pour certaines feature du fs, blablabla...
Un coup de debugfs pour retirer cette feature et fsck est enfin d'accord pour le faire.
Évidemment, c'est la cata, le bordel, la misère. Bref, pleins d'erreurs (mais corrigé).
Reboot sur ma arch à moi, fsck des autres fs et me revoilà sur mon bureau.
Plus de peur que de mal mais va falloir que je creuse l'affaire.
Nous voilà maintenant à mon soucis du moment: le link sur ma connexion est très très versatile.
ping de l'ip d'eth0 ok mais ping de la passerelle KO.
une boucle de mii-tool eth0 avec un sleep à 0.1 me montre ceci: environ 0,8s de up puis environ 1,5s de down, en boucle.
lspci m'indique une carte realtek RTL8111/8168B (rev 03).
lsmod m'indique le module r8169.
un peu de google plus tard, je vois des posts du ce genre de problème et l'existence du module r8168. A là bonne heure!
Je le télécharge depuis un autre pc, et l'installe avec un pacman -U depuis une clef usb.
Je pense bien à blacklister le r8169 et plein d'espoir décharge le pourri, charge le nouveau, relance le daemon network. Pareil.
Pris d'un doute, je reboot. Pareil.
J'ai testé de forcer les vitesses/duplex avec ethtool mais ça reste foireux. Par exemple, en 10Mbit half duplex, le lien reste up mais je ne ping toujours pas ma passerelle ou d'autres machines du même lan.
Encore plus drôle, je dispose d'une mythtv box sous archlinux (en i686 par contre) qui dispose également du même contrôleur réseau, avec le noyau juste précédent (j'ai préféré ne pas prendre le risque pour le moment d'y lancer un yaourt -Syu...). Le module chargé est le r8169 et même si (très très) ponctuellement on retrouve des link down/link up dans les logs, pas de problème particulier.
J'ai tester un autre câble, les autres prise rj45 de ma vieille freebox v5, redémarré cette dernière, downgradé le kernel jusqu'à la version n-2 du moment, sans plus de succès.
A noter également qu'avec ctkarch en v0.7 et un noyau 2.6.37 (de mémoire), le problème de lien reste entier. J'ai également vu un option dans le bios pour tester le lien réseau durant la POST et même là, indépendamment de tout OS, ça foire.
Z'avez des idées ?
Dernière modification par peshane le sam. 03 déc. 2011, 18:10, modifié 1 fois.
Re: [réseau] eth0 flapping à mort
indépendamment de tout OS, ça foire.
newegg.comZ'avez des idées ?
y'a pas une mise a jour du bios dispo a tout hasard
Re: [réseau] eth0 flapping à mort
dans le doute, bios mise à jour ce matin. Rien de plus.
je garde espoir, mon pc peut vivre
je garde espoir, mon pc peut vivre
Re: [réseau] eth0 flapping à mort
suite des mésaventures:
soit j'ai cafouillé l'autre fois, soit le fait d'avoir été arrêter pendant la journée lui a fait un peu de bien, soit c'est encore plus mystérieux mais à présent si je force la carte en 10Mbit full duplex, j'ai enfin du réseau. D’ailleurs j'écris depuis mon pc.
Cependant, cela ne fonctionne qu'avec le pilote r8168 et pas avec le r8169.
pour le fun, un exemple de ce que donne l'état du link quand ça foire:
test de débit via le site de free: environ 70ko/s (environ 1Mo/s normalement)
test de débit via nc vers mon htpc (même contrôleur réseau avec le pilote r8169 pour mémoire): environ 980ko/s (environ 10Mo/s normalement).
Dans la mesure où pendant la POST le link n'est pas up d'après les leds du port sur le pc et la led de la freebox (où d'un vieux routeur linksys que j'ai retrouvé dans mes cartons), j'en déduis un problème matériel suffisamment subtil pour que ça fonctionne en forçant le lien à 10Mbit.
D'un autre coté, je ne m'explique pas la diminution à tel point de ma connexion internet (qui est à son débit nominale sur le htpc). De même, pourquoi je n'obtiens rien avec le module r8169 avec lequel pourtant je tournais depuis que j'ai ce pc et qui fonctionne toujours normalement sur le htpc.
je reste bien sur ouvert à toutes vos idées !
soit j'ai cafouillé l'autre fois, soit le fait d'avoir été arrêter pendant la journée lui a fait un peu de bien, soit c'est encore plus mystérieux mais à présent si je force la carte en 10Mbit full duplex, j'ai enfin du réseau. D’ailleurs j'écris depuis mon pc.
Cependant, cela ne fonctionne qu'avec le pilote r8168 et pas avec le r8169.
pour le fun, un exemple de ce que donne l'état du link quand ça foire:
Code : Tout sélectionner
[peshane@pesharch3 ~]$ while true; do sudo mii-tool eth0; sleep 0.1; done | awk '{if(/ok$/){ok=ok+1; nok=0; print "ok="ok,"\tnok="nok}else{nok=nok+1; ok=0; print "ok="ok,"\tnok="nok}}'
ok=1 nok=0
ok=2 nok=0
ok=3 nok=0
ok=4 nok=0
ok=0 nok=1
ok=0 nok=2
ok=0 nok=3
ok=0 nok=4
ok=0 nok=5
ok=0 nok=6
ok=0 nok=7
ok=0 nok=8
ok=0 nok=9
ok=0 nok=10
ok=0 nok=11
ok=0 nok=12
ok=0 nok=13
ok=0 nok=14
ok=0 nok=15
ok=0 nok=16
ok=1 nok=0
ok=2 nok=0
ok=3 nok=0
ok=4 nok=0
ok=5 nok=0
ok=6 nok=0
ok=7 nok=0
ok=8 nok=0
ok=0 nok=1
ok=0 nok=2
ok=0 nok=3
ok=0 nok=4
ok=0 nok=5
ok=0 nok=6
ok=0 nok=7
ok=0 nok=8
ok=0 nok=9
ok=0 nok=10
ok=0 nok=11
ok=0 nok=12
ok=0 nok=13
ok=0 nok=14
ok=0 nok=15
ok=0 nok=16
ok=0 nok=17
ok=1 nok=0
ok=2 nok=0
ok=3 nok=0
ok=4 nok=0
ok=5 nok=0
ok=6 nok=0
ok=7 nok=0
ok=0 nok=1
ok=0 nok=2
ok=0 nok=3
ok=0 nok=4
ok=0 nok=5
ok=0 nok=6
ok=0 nok=7
ok=0 nok=8
ok=0 nok=9
ok=0 nok=10
ok=0 nok=11
^C
[peshane@pesharch3 ~]$
test de débit via le site de free: environ 70ko/s (environ 1Mo/s normalement)
test de débit via nc vers mon htpc (même contrôleur réseau avec le pilote r8169 pour mémoire): environ 980ko/s (environ 10Mo/s normalement).
Dans la mesure où pendant la POST le link n'est pas up d'après les leds du port sur le pc et la led de la freebox (où d'un vieux routeur linksys que j'ai retrouvé dans mes cartons), j'en déduis un problème matériel suffisamment subtil pour que ça fonctionne en forçant le lien à 10Mbit.
D'un autre coté, je ne m'explique pas la diminution à tel point de ma connexion internet (qui est à son débit nominale sur le htpc). De même, pourquoi je n'obtiens rien avec le module r8169 avec lequel pourtant je tournais depuis que j'ai ce pc et qui fonctionne toujours normalement sur le htpc.
je reste bien sur ouvert à toutes vos idées !
Re: [réseau] eth0 flapping à mort
j'ai acheté une carte ethernet en pci et évidemment le lien est à présent ok.
Par contre, ça ne ping dans le lan où sur internet QUE si je fixe la vitesse à 10Mbit.
Le disque refait des siennes:
Pour ce que ça vaut, SMART me dit que mon disque se porte bien:
à votre avis, la carte mère est morte ?
Par contre, ça ne ping dans le lan où sur internet QUE si je fixe la vitesse à 10Mbit.
Le disque refait des siennes:
Code : Tout sélectionner
ov 25 20:22:38 localhost kernel: [ 258.595995] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x280100 action 0x6 frozen
Nov 25 20:22:38 localhost kernel: [ 258.596114] ata1.00: irq_stat 0x08000000, interface fatal error
Nov 25 20:22:38 localhost kernel: [ 258.596194] ata1: SError: { UnrecovData 10B8B BadCRC }
Nov 25 20:22:38 localhost kernel: [ 258.596271] ata1.00: failed command: READ FPDMA QUEUED
Nov 25 20:22:38 localhost kernel: [ 258.596350] ata1.00: cmd 60/00:00:e0:1d:9d/02:00:2f:00:00/40 tag 0 ncq 262144 in
Nov 25 20:22:38 localhost kernel: [ 258.596351] res 40/00:04:e0:1d:9d/00:00:2f:00:00/40 Emask 0x10 (ATA bus error)
Nov 25 20:22:38 localhost kernel: [ 258.596565] ata1.00: status: { DRDY }
Nov 25 20:22:38 localhost kernel: [ 258.596639] ata1: hard resetting link
Nov 25 20:22:48 localhost kernel: [ 268.577425] ata1: softreset failed (1st FIS failed)
Nov 25 20:22:48 localhost kernel: [ 268.577512] ata1: hard resetting link
Nov 25 20:22:48 localhost kernel: [ 269.063360] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 25 20:22:48 localhost kernel: [ 269.075011] ata1.00: configured for UDMA/133
Nov 25 20:22:48 localhost kernel: [ 269.086663] ata1: EH complete
Nov 25 20:22:54 localhost kernel: [ 274.493172] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x280100 action 0x6 frozen
Nov 25 20:22:54 localhost kernel: [ 274.493291] ata1.00: irq_stat 0x08000000, interface fatal error
Nov 25 20:22:54 localhost kernel: [ 274.493370] ata1: SError: { UnrecovData 10B8B BadCRC }
Nov 25 20:22:54 localhost kernel: [ 274.493447] ata1.00: failed command: READ FPDMA QUEUED
Nov 25 20:22:54 localhost kernel: [ 274.493526] ata1.00: cmd 60/00:00:e0:63:de/02:00:2f:00:00/40 tag 0 ncq 262144 in
Nov 25 20:22:54 localhost kernel: [ 274.493527] res 40/00:04:e0:63:de/00:00:2f:00:00/40 Emask 0x10 (ATA bus error)
Nov 25 20:22:54 localhost kernel: [ 274.493741] ata1.00: status: { DRDY }
Code : Tout sélectionner
Nov 25 20:22:57 localhost kernel: [ 277.436492] ata1: SATA link down (SStatus 0 SControl 310)
Nov 25 20:23:02 localhost kernel: [ 282.428543] ata1: hard resetting link
Nov 25 20:23:20 localhost kernel: [ 282.914437] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Nov 25 20:23:20 localhost kernel: [ 282.926034] ata1.00: configured for UDMA/133
Nov 25 20:23:20 localhost kernel: [ 282.937688] ata1: EH complete
Nov 25 20:23:20 localhost kernel: [ 282.955902] ata1.00: exception Emask 0x50 SAct 0xf SErr 0x280900 action 0x6 frozen
Nov 25 20:23:20 localhost kernel: [ 282.956019] ata1.00: irq_stat 0x08000000, interface fatal error
Nov 25 20:23:20 localhost kernel: [ 282.956097] ata1: SError: { UnrecovData HostInt 10B8B BadCRC }
Nov 25 20:23:20 localhost kernel: [ 282.956175] ata1.00: failed command: READ FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [ 282.956252] ata1.00: cmd 60/00:00:e0:6f:e0/02:00:2f:00:00/40 tag 0 ncq 262144 in
Nov 25 20:23:20 localhost kernel: [ 282.956253] res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [ 282.956465] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [ 282.956535] ata1.00: failed command: WRITE FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [ 282.956612] ata1.00: cmd 61/08:08:9a:38:6a/00:00:03:00:00/40 tag 1 ncq 4096 out
Nov 25 20:23:20 localhost kernel: [ 282.956613] res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [ 282.956824] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [ 282.956894] ata1.00: failed command: WRITE FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [ 282.956971] ata1.00: cmd 61/20:10:b2:68:87/00:00:01:00:00/40 tag 2 ncq 16384 out
Nov 25 20:23:20 localhost kernel: [ 282.956972] res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [ 282.957183] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [ 282.957254] ata1.00: failed command: WRITE FPDMA QUEUED
Nov 25 20:23:20 localhost kernel: [ 282.957331] ata1.00: cmd 61/08:18:02:23:ca/00:00:01:00:00/40 tag 3 ncq 4096 out
Nov 25 20:23:20 localhost kernel: [ 282.957332] res 40/00:1c:02:23:ca/00:00:01:00:00/40 Emask 0x50 (ATA bus error)
Nov 25 20:23:20 localhost kernel: [ 282.957543] ata1.00: status: { DRDY }
Nov 25 20:23:20 localhost kernel: [ 282.957621] ata1: hard resetting link
Code : Tout sélectionner
[peshane@pesharch3 ~]$ sudo smartctl -H /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.1.2-1-ARCH] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
à votre avis, la carte mère est morte ?
Re: [réseau] eth0 flapping à mort
t'as pas un cable sata en rab pour voir si ca change quelquechose?
Re: [réseau] eth0 flapping à mort
j'viens justement d'essayer de le brancher sur un autre port sata de la CM mais il n'était alors plus vu pendant la POST. Je l'ai donc rebrancher sur le port SATA 1 et depuis (uptime d'1h au moment où j'écris), pas de nouveau message dans /var/log/kernel.log. Au prochain plantage, je testerais avec le câble sata du lecteur dvd (que j'ai débranché pour le moment).
Cependant, et malgré la carte pci ethernet, toujours obliger de forcer le lien en 10Mbits pour un réseau fonctionnel.
Cependant, et malgré la carte pci ethernet, toujours obliger de forcer le lien en 10Mbits pour un réseau fonctionnel.
Re: [réseau] eth0 flapping à mort
t'es sur que le probleme de vitesse ne vient pas de l'autre cote du cable (je sais plus a quoi t'es connecte...) t'as bien un cable de la bonne categorie ? 5 mini pour du gigabit je crois.
Re: [réseau] eth0 flapping à mort
de l'autre côté, c'est une freebox v5 (100 Mbits).
J'ai également tester le lien sur les autres ports de la freebox, sur un switch linksys 100Mbits, avec un autre câble, le problème reste présent.
Les câbles sont des cat5 STP.
J'ai également tester le lien sur les autres ports de la freebox, sur un switch linksys 100Mbits, avec un autre câble, le problème reste présent.
Les câbles sont des cat5 STP.
Re: [réseau] eth0 flapping à mort
t'as pris quoi comme carte?
Re: [réseau] eth0 flapping à mort
une carte tp-link. Le contrôleur dessus est un realtek RTL8169C.
En négociation auto, elle se met bien à 100Mbits, mais unreachable vers la freebox alors que c'est ok à 10Mbits
En négociation auto, elle se met bien à 100Mbits, mais unreachable vers la freebox alors que c'est ok à 10Mbits
Re: [réseau] eth0 flapping à mort
si tu ping 127.0.0.1 en 100M, ca marche ?
Re: [réseau] eth0 flapping à mort
ma loopback est intact
je ping aussi l'ip d'eth0 en 100Mbits.
je ping aussi l'ip d'eth0 en 100Mbits.
Re: [réseau] eth0 flapping à mort
je persiste à tenter de sauver mon pc
je ne sais pas si ça peut aider les plus perspicaces d'entre vous mais lorsque mon pc mourant est en 100 Mbit et que je lance un tcpdump arp sur un autre pc du lan, j'obtiens ça:
ma freebox demande qui est 192.168.1.128 (mon pc mourant).
les 3 derniers sont un arping depuis le pc mourant qui est bien reçu par l'autre pc.
Si je fait un arping vers 192.168.1.123 (mon deuxième pc), alors vu du deuxième pc:
alors que le pc en souffrance ne reçoit aucune réponse:
évidement, dès que je passe à 10 Mbit, tout est ok.
je ne sais pas si ça peut aider les plus perspicaces d'entre vous mais lorsque mon pc mourant est en 100 Mbit et que je lance un tcpdump arp sur un autre pc du lan, j'obtiens ça:
Code : Tout sélectionner
21:46:45.790950 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:46.790928 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:47.790933 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:48.840229 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:49.838947 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:50.838961 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:53.395013 ARP, Request who-has 192.168.1.128 tell 192.168.1.254, length 48
21:46:53.726293 ARP, Request who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:46:54.726444 ARP, Request who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:46:55.726569 ARP, Request who-has 192.168.1.254 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
les 3 derniers sont un arping depuis le pc mourant qui est bien reçu par l'autre pc.
Si je fait un arping vers 192.168.1.123 (mon deuxième pc), alors vu du deuxième pc:
Code : Tout sélectionner
21:54:14.859469 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:54:14.859484 ARP, Reply 192.168.1.123 is-at 00:19:66:fd:9e:6b, length 28
21:54:15.859580 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:54:15.859595 ARP, Reply 192.168.1.123 is-at 00:19:66:fd:9e:6b, length 28
21:54:16.859705 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 46
21:54:16.859722 ARP, Reply 192.168.1.123 is-at 00:19:66:fd:9e:6b, length 28
Code : Tout sélectionner
21:54:14.700514 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 28
21:54:15.700619 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 28
21:54:16.700749 ARP, Request who-has 192.168.1.123 (ff:ff:ff:ff:ff:ff) tell 192.168.1.128, length 28
Re: [réseau] eth0 flapping à mort (résolu)
pour conclure, j'ai racheté une carte mère (même modèle que la précédente) et tout va pour le mieux (jusqu') à présent.