Hello tous,
Pour les abonnés cegetel, depuis samedi matin (vendredi dans la nuit en fait chez moi), petit changement ADSL:
Vous êtes passés sur le réseau neuf télécom si votre ip reverse dns donne x.x.x.x.rev.gaoland.net
Deux changements
Le UP est passé de 320k à 800k chez moi. Ca c'est bien et transparent.
Par contre ces _idiots_ n'ont pas prévenu leurs abonnés (ou si ils l'ont fait, c'est raté). La principale conséquence est que le 'smtp.cegetel.net' refuse poliement vos messages avec un 'relay denied'. Normal.
La correction est simple => smtp.neuf.fr pour ceux qui ont basculé sans être prévenu et qui se demande pourquoi ca marche pas.
Peut être une façon de gagner du pognon avec la hotlline...
Il n'y a absolument rien sur la page 'états du réseau' de leur portail.
Bye
cegetel+neuf=pas mieux
Modérateur: modos Ixus
14 messages
• Page 1 sur 1
cegetel+neuf=pas mieux
par Franck78 » 19 Mars 2006 15:12
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par Franck78 » 21 Mars 2006 14:36
Et allez, encore un changement qui n'avait échappé:
03/00:32:45 ipcop CHAP authentication succeeded: CHAP authentication success, unit 4177
03/00:32:45 ipcop local IP address 86.72.26.71
03/00:32:45 ipcop remote IP address 1.1.1.1
03/00:32:45 ipcop primary DNS address 217.19.192.132
03/00:32:45 ipcop secondary DNS address 217.19.192.131
Notez l'adresse de la gateway: 1.1.1.1
Encore des conflits en prévision. C'était tellement plus simple de laisser la véritable IP à l'autre bout de la liaison ppp.
(avec la carte ethernet pour le modem pppOE qui recoit 1.1.1.1 )
ppp0 Link encap:Point-to-Point Protocol
inet addr:86.72.26.71 P-t-P:1.1.1.1 Mask:255.255.255.255
D'ores et dèja, le simple VPN vers un netgear ne passe plus...
03/00:32:45 ipcop CHAP authentication succeeded: CHAP authentication success, unit 4177
03/00:32:45 ipcop local IP address 86.72.26.71
03/00:32:45 ipcop remote IP address 1.1.1.1
03/00:32:45 ipcop primary DNS address 217.19.192.132
03/00:32:45 ipcop secondary DNS address 217.19.192.131
Notez l'adresse de la gateway: 1.1.1.1
Encore des conflits en prévision. C'était tellement plus simple de laisser la véritable IP à l'autre bout de la liaison ppp.
(avec la carte ethernet pour le modem pppOE qui recoit 1.1.1.1 )
ppp0 Link encap:Point-to-Point Protocol
inet addr:86.72.26.71 P-t-P:1.1.1.1 Mask:255.255.255.255
D'ores et dèja, le simple VPN vers un netgear ne passe plus...
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par fred24 » 01 Avr 2006 10:31
Franck78 a écrit:ppp0 Link encap:Point-to-Point Protocol
inet addr:86.72.26.71 P-t-P:1.1.1.1 Mask:255.255.255.255
la seconde adresse est une adresse locale, ca n'a rien à voir avec le Cegetel.
Faut pas non plus tout leur mettre sur le dos .... fait un reset et appel Netgear
- fred24
- Matelot
- Messages: 5
- Inscrit le: 01 Avr 2006 10:29
Re: cegetel+neuf=pas mieux
par fred24 » 01 Avr 2006 10:33
Franck78 a écrit:relay denied
Wanadoo l'a fait il n'y a pas longtemps et 9 le prepare sur son infra propre. ClubInternet le fait depuis le début sur son nouveau réseau
En gros tous les réseaux ..... tout le monde pareil
- fred24
- Matelot
- Messages: 5
- Inscrit le: 01 Avr 2006 10:29
par Franck78 » 01 Avr 2006 11:39
Deux choses Fred24:
1) Pour le SMTP, mon serveur aussi renvoie un 'relay access denied' pour ce qui ne concerne pas mon réseau. Tout le monde est d'accord la dessus. Mais quand un FAI change la config réseau(cegetel->neuf) et que du coup le client se trouve externe du point de vue du serveur SMTP, la moindre des choses est de prévenir et avant tant qu'à faire. C'est le cadet des soucis de neufcegetel.
2)
>la seconde adresse est une adresse locale, ca n'a rien à voir avec le Cegetel.
Ben voyons! Tu parles de 1.1.1.1 la? Alors si je t'étoute, ppp établit un lien entre moi et moi? Parceque tu as bien compris que 86.72.26.71 est aussi l'IP attribuée à l'interface ppp0, locale à ma machine....
Continuons le raisonnement: ca marche avec 1.1.1.1, ca marche avec une adresse correcte pour IP*, donc a priori ca marche avec n'importe quoi. Donc ca ne sert à rien. Je connais peu de protocole qui fonctionne avec des réglages qui ne servent à rien.
Alors définitivement oui, neufcegetel agit n'importe comment
*le routeur pour mon subnet.
Un simple trace route depuis l'IPCop: les deux premiers sauts sont inconnus!
Quand est-il chez vous? Les deux premiers routeurs sont aussi inconnus?
Bye
1) Pour le SMTP, mon serveur aussi renvoie un 'relay access denied' pour ce qui ne concerne pas mon réseau. Tout le monde est d'accord la dessus. Mais quand un FAI change la config réseau(cegetel->neuf) et que du coup le client se trouve externe du point de vue du serveur SMTP, la moindre des choses est de prévenir et avant tant qu'à faire. C'est le cadet des soucis de neufcegetel.
2)
>la seconde adresse est une adresse locale, ca n'a rien à voir avec le Cegetel.
Ben voyons! Tu parles de 1.1.1.1 la? Alors si je t'étoute, ppp établit un lien entre moi et moi? Parceque tu as bien compris que 86.72.26.71 est aussi l'IP attribuée à l'interface ppp0, locale à ma machine....
Continuons le raisonnement: ca marche avec 1.1.1.1, ca marche avec une adresse correcte pour IP*, donc a priori ca marche avec n'importe quoi. Donc ca ne sert à rien. Je connais peu de protocole qui fonctionne avec des réglages qui ne servent à rien.
Alors définitivement oui, neufcegetel agit n'importe comment
*le routeur pour mon subnet.
Un simple trace route depuis l'IPCop: les deux premiers sauts sont inconnus!
- Code: Tout sélectionner
traceroute to cegetel.net (217.19.196.129), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 241.253.103-84.rev.gaoland.net (84.103.253.241) 41.010 ms 40.848 ms 39.957 ms
4 34.156.96-84.rev.gaoland.net (84.96.156.34) 39.974 ms 39.794 ms 40.912 ms
5 46.156.96-84.rev.gaoland.net (84.96.156.46) 40.022 ms 39.893 ms 40.956 ms
6 50.156.96-84.rev.gaoland.net (84.96.156.50) 42.518 ms 40.802 ms 40.937 ms
7 * 54.156.96-84.rev.gaoland.net (84.96.156.54) 41.821 ms *
8 V4080.cbv1-co-2.n9uf.net (62.39.148.57) 40.800 ms 40.772 ms 41.002 ms
9 V4074.cbv1-co-1.n9uf.net (62.39.148.81) 39.946 ms 40.627 ms *
10 242-193-118-80.kaptech.net (80.118.193.242) 40.819 ms 39.950 ms 40.932 ms
11 212.94.163.13 (212.94.163.13) 40.852 ms 40.886 ms 40.960 ms
12 core1-1.courbevoie.gaoland.net (212.94.163.1) 39.954 ms 40.791 ms 42.242 ms
13 217-19-196-129.dti.cegetel.net (217.19.196.129) 40.667 ms 41.898 ms 41.041 ms
Quand est-il chez vous? Les deux premiers routeurs sont aussi inconnus?
Bye
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par fred24 » 01 Avr 2006 13:29
Franck78 a écrit:Quand est-il chez vous? Les deux premiers routeurs sont aussi inconnus?
On m'a toujours appris que les 3 premiers sauts ne devaient pas rentrer en statistiques pour un ping
et tes 2 premiers sauts ne sont pas inconnus mais n'ont pas repondus dans le delai demandé par le ping.Franck78 a écrit:Ben voyons! Tu parles de 1.1.1.1 la? Alors si je t'étoute, ppp établit un lien entre moi et moi? Parceque tu as bien compris que 86.72.26.71 est aussi l'IP attribuée à l'interface ppp0, locale à ma machine....
Continuons le raisonnement: ca marche avec 1.1.1.1, ca marche avec une adresse correcte pour IP*, donc a priori ca marche avec n'importe quoi. Donc ca ne sert à rien. Je connais peu de protocole qui fonctionne avec des réglages qui ne servent à rien.
Alors définitivement oui, neufcegetel agit n'importe comment
ton ppp0 est un bridge entre 2 réseaux c'est un pont entre le réseau internet (ton FAI t'a fourni une ip 86.72.26.71) et l'interface réseau local de mon modem routeur (qu'il a appelé 1.1.1.1 et cela dépend que de ton modem routeur). Moi perso chez CI, avec leur comtrend il y a un lien entre IP distante et 192.168.10.1 et apres un pont entre le réseau local USB (192.168.2.1), Eth (192.168.1.1) et Wifi (192.168.3.1) que d'ailleurs j'ai modifié avant qu'il n'existe qu'un pont direct entre IP public et les 3 reseaux locaux que j'ai mis en 192.168.0.1
Après ton histoire de subnet je ne comprends pas parce que ce n'est pa un sous reseau mais un réseau ponté (fonction bridge) avec le reseau internet
- fred24
- Matelot
- Messages: 5
- Inscrit le: 01 Avr 2006 10:29
par fred24 » 01 Avr 2006 13:38
et pour cloturer le tout je vois pas comment un FAI pourrait modifier l'IP d'un reseau local dans TON routeur ....
Leur produit avec un push de firmware en FTP c possible mais s'ils doivent faire des firmwares pour modifier toutes les configs de tous les modem routeurs du marché ...
Cegetel ils seraient plus fort que toi
Leur produit avec un push de firmware en FTP c possible mais s'ils doivent faire des firmwares pour modifier toutes les configs de tous les modem routeurs du marché ...
Cegetel ils seraient plus fort que toi
- fred24
- Matelot
- Messages: 5
- Inscrit le: 01 Avr 2006 10:29
par Franck78 » 01 Avr 2006 13:59
Extrait du RFC 1661
ppp agit au niveau 1 (liaison). Une fois établit, le protocole IP (réseau) entre en jeux.
Prend deux machines, relies les par un cable croisé, attribuent leurs une IP dans un subnet différent.
Et dis moi si tu obtiens un résultat utile.
3.6. Network-Layer Protocol Phase
Once PPP has finished the previous phases, each network-layer
protocol (such as IP, IPX, or AppleTalk) MUST be separately
configured by the appropriate Network Control Protocol (NCP).
Each NCP MAY be Opened and Closed at any time.
Network Control Protocols
Point-to-Point links tend to exacerbate many problems with the
current family of network protocols. For instance, assignment and
management of IP addresses, which is a problem even in LAN
environments, is especially difficult over circuit-switched
point-to-point links (such as dial-up modem servers). These
problems are handled by a family of Network Control Protocols
(NCPs), which each manage the specific needs required by their
respective network-layer protocols. These NCPs are defined in
companion documents.
ppp agit au niveau 1 (liaison). Une fois établit, le protocole IP (réseau) entre en jeux.
Prend deux machines, relies les par un cable croisé, attribuent leurs une IP dans un subnet différent.
Et dis moi si tu obtiens un résultat utile.
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par fred24 » 01 Avr 2006 14:03
Franck78 a écrit:Extrait du RFC 16613.6. Network-Layer Protocol Phase
Once PPP has finished the previous phases, each network-layer
protocol (such as IP, IPX, or AppleTalk) MUST be separately
configured by the appropriate Network Control Protocol (NCP).
Each NCP MAY be Opened and Closed at any time.Network Control Protocols
Point-to-Point links tend to exacerbate many problems with the
current family of network protocols. For instance, assignment and
management of IP addresses, which is a problem even in LAN
environments, is especially difficult over circuit-switched
point-to-point links (such as dial-up modem servers). These
problems are handled by a family of Network Control Protocols
(NCPs), which each manage the specific needs required by their
respective network-layer protocols. These NCPs are defined in
companion documents.
ppp agit au niveau 1 (liaison). Une fois établit, le protocole IP (réseau) entre en jeux.
Prend deux machines, relies les par un cable croisé, attribuent leurs une IP dans un subnet différent.
Et dis moi si tu obtiens un résultat utile.
Qui a dit le contraire ?
et pourquoi ne veux tu pas comprendre que ce 1.1.1.1 est un paramètre de ton routeur et pas de ton FAI ...
bon Ciao je jette l'eponge
- fred24
- Matelot
- Messages: 5
- Inscrit le: 01 Avr 2006 10:29
par Franck78 » 01 Avr 2006 15:56
Extraits du log pppd
Les options pppd spécifient une IP locale et une IP remote
10.0.0.5:10.0.0.1
+ipcp-accept-local
#ipcp-accept-remote
Tu constates que ppp propose 10.0.0.5 en ip locale, que ppp se fais jeter et accept 86.72... (car ipcp-accept-local)
Tu constates aussi que ppp propose 10.0.0.1 en ip remote, que ppp se fait jeter et suggérer 1.1.1.1 que ppp rejète (car pas de ipcp-accept-remote). Sanction immédiate: le ppp du FAI ferme la cnx.
Maintenant
10.0.0.5:10.0.0.1
+ipcp-accept-local
+ipcp-accept-remote
ppp fait même pas ses propositions. Il accepte sans broncher les propositions de l'autre (le FAI).
@Fred24: tu persistes à dire que l'adresse IP remote est choisie par moi ?
Les options pppd spécifient une IP locale et une IP remote
10.0.0.5:10.0.0.1
+ipcp-accept-local
#ipcp-accept-remote
Tu constates que ppp propose 10.0.0.5 en ip locale, que ppp se fais jeter et accept 86.72... (car ipcp-accept-local)
Tu constates aussi que ppp propose 10.0.0.1 en ip remote, que ppp se fait jeter et suggérer 1.1.1.1 que ppp rejète (car pas de ipcp-accept-remote). Sanction immédiate: le ppp du FAI ferme la cnx.
- Code: Tout sélectionner
Apr 1 15:04:49 thewall pppd[24403]: CHAP authentication succeeded
Apr 1 15:04:49 thewall pppd[24403]: sent [IPCP ConfReq id=0x1 <addr 10.0.0.5> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 1 15:04:49 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x1 <addr 1.1.1.1>]
Apr 1 15:04:49 thewall pppd[24403]: sent [IPCP ConfNak id=0x1 <addr 10.0.0.1>]
Apr 1 15:04:49 thewall pppd[24403]: rcvd [IPCP ConfNak id=0x1 <addr 86.72.26.155> <ms-dns1 86.64.145.140> <ms-dns3 84.103.237.140>]
Apr 1 15:04:49 thewall pppd[24403]: sent [IPCP ConfReq id=0x2 <addr 86.72.26.155> <ms-dns1 86.64.145.140> <ms-dns3 84.103.237.140>]
Apr 1 15:04:49 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x1 <addr 1.1.1.1>]
Apr 1 15:04:49 thewall pppd[24403]: sent [IPCP ConfNak id=0x1 <addr 10.0.0.1>]
Apr 1 15:04:49 thewall pppd[24403]: rcvd [IPCP ConfAck id=0x2 <addr 86.72.26.155> <ms-dns1 86.64.145.140> <ms-dns3 84.103.237.140>]
Apr 1 15:04:49 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x2 <addr 1.1.1.1>]
Apr 1 15:04:49 thewall pppd[24403]: sent [IPCP ConfNak id=0x2 <addr 10.0.0.1>]
Apr 1 15:04:49 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x3 <addr 1.1.1.1>]
Apr 1 15:04:49 thewall pppd[24403]: sent [IPCP ConfNak id=0x3 <addr 10.0.0.1>]
Apr 1 15:04:50 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x4 <addr 1.1.1.1>]
Apr 1 15:04:50 thewall pppd[24403]: sent [IPCP ConfNak id=0x4 <addr 10.0.0.1>]
Apr 1 15:04:50 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x5 <addr 1.1.1.1>]
Apr 1 15:04:50 thewall pppd[24403]: sent [IPCP ConfRej id=0x5 <addr 1.1.1.1>]
Apr 1 15:04:50 thewall pppd[24403]: rcvd [IPCP ConfReq id=0x6]
Apr 1 15:04:50 thewall pppd[24403]: sent [IPCP ConfAck id=0x6]
Apr 1 15:04:50 thewall pppd[24403]: local IP address 86.72.26.155
Apr 1 15:04:50 thewall pppd[24403]: remote IP address 10.0.0.1
Apr 1 15:04:50 thewall pppd[24403]: primary DNS address 86.64.145.140
Apr 1 15:04:50 thewall pppd[24403]: secondary DNS address 84.103.237.140
Apr 1 15:04:50 thewall pppd[24403]: Script /etc/ppp/ip-up started (pid 24411)
Apr 1 15:04:50 thewall pppd[24403]: rcvd [LCP TermReq id=0x3]
Apr 1 15:04:50 thewall pppd[24403]: LCP terminated by peer
Maintenant
10.0.0.5:10.0.0.1
+ipcp-accept-local
+ipcp-accept-remote
ppp fait même pas ses propositions. Il accepte sans broncher les propositions de l'autre (le FAI).
- Code: Tout sélectionner
Apr 1 15:20:14 thewall pppd[9904]: CHAP authentication succeeded
Apr 1 15:20:14 thewall pppd[9904]: sent [IPCP ConfReq id=0x1 <addr 10.0.0.5> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 1 15:20:14 thewall pppd[9904]: rcvd [IPCP ConfReq id=0x1 <addr 1.1.1.1>]
Apr 1 15:20:14 thewall pppd[9904]: sent [IPCP ConfAck id=0x1 <addr 1.1.1.1>]
Apr 1 15:20:14 thewall pppd[9904]: rcvd [IPCP ConfNak id=0x1 <addr 86.72.26.19> <ms-dns1 86.64.145.144> <ms-dns3 84.103.237.144>]
Apr 1 15:20:14 thewall pppd[9904]: sent [IPCP ConfReq id=0x2 <addr 86.72.26.19> <ms-dns1 86.64.145.144> <ms-dns3 84.103.237.144>]
Apr 1 15:20:14 thewall pppd[9904]: rcvd [IPCP ConfAck id=0x2 <addr 86.72.26.19> <ms-dns1 86.64.145.144> <ms-dns3 84.103.237.144>]
Apr 1 15:20:14 thewall pppd[9904]: local IP address 86.72.26.19
Apr 1 15:20:14 thewall pppd[9904]: remote IP address 1.1.1.1
Apr 1 15:20:14 thewall pppd[9904]: primary DNS address 86.64.145.144
Apr 1 15:20:14 thewall pppd[9904]: secondary DNS address 84.103.237.144
Apr 1 15:20:14 thewall pppd[9904]: Script /etc/ppp/ip-up started (pid 9917)
Apr 1 15:20:14 thewall ipcop: PPP has gone up on ppp0
et pourquoi ne veux tu pas comprendre que ce 1.1.1.1 est un paramètre de ton routeur et pas de ton FAI ...
@Fred24: tu persistes à dire que l'adresse IP remote est choisie par moi ?
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par micjack » 02 Avr 2006 01:47
Je ne suis pas d'accord avec fred24 concernant l'IP 1.1.1.1 qui soit disant fait partie de la conf du routeur.
Cela éxiste effectivement, genre une IP 10.0.0.3 dans un routeur, mais l'IP gardera cet état tant qu'elle n'a pas prise son IP publique attribuée par le FAI aprés le pap/chap.
Donc, concernant une IP genre avec un ifconfig avant : (Je donne un exemple avec un modem USB)
hsb0 Link encap:Ethernet HWaddr xx.xx.xx.xx.xx.xx
inet addr:10.0.0.3 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Il y'a bien 10.0.0.3
Puis aprés authentification
Link encap:Ethernet HWaddr xx.xx.xx.xx.xx.xx
inet addr:83.157.x.x Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Il y'a bien une IP 10.0.0.3 qui devient 83.157.x.x (La c'est normal)
Ce qui arrive à Franck reste zarbi, et je pense que seul 9euf puisse y repondre (surrement un probleme de migration) surrement aussi un probleme de LNS.
Ainsi que le traceroute qui reste zarb, justement il devrait mensionner l'IP 1.1.1.1 ainsi que l'IP de lacarte réseau. Mais le prochain saut, j'espere que c'est le LNS de ta region.
De toute facon, quand l'on construit des script demandant à avoir son IP publique on utilise bien
ifconfig ppp0 | grep P-t-P ...
Cela éxiste effectivement, genre une IP 10.0.0.3 dans un routeur, mais l'IP gardera cet état tant qu'elle n'a pas prise son IP publique attribuée par le FAI aprés le pap/chap.
Donc, concernant une IP genre avec un ifconfig avant : (Je donne un exemple avec un modem USB)
hsb0 Link encap:Ethernet HWaddr xx.xx.xx.xx.xx.xx
inet addr:10.0.0.3 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Il y'a bien 10.0.0.3
Puis aprés authentification
Link encap:Ethernet HWaddr xx.xx.xx.xx.xx.xx
inet addr:83.157.x.x Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Il y'a bien une IP 10.0.0.3 qui devient 83.157.x.x (La c'est normal)
Ce qui arrive à Franck reste zarbi, et je pense que seul 9euf puisse y repondre (surrement un probleme de migration) surrement aussi un probleme de LNS.
Ainsi que le traceroute qui reste zarb, justement il devrait mensionner l'IP 1.1.1.1 ainsi que l'IP de lacarte réseau. Mais le prochain saut, j'espere que c'est le LNS de ta region.
De toute facon, quand l'on construit des script demandant à avoir son IP publique on utilise bien
ifconfig ppp0 | grep P-t-P ...
- micjack
- Amiral
- Messages: 3113
- Inscrit le: 06 Juin 2003 00:00
- Localisation: Varois
par EyEBURNeR » 05 Avr 2006 15:32
J'ai exactement le même problème.
Mon réseau:
9box(mode bridge) <-red pppoe-> ipcop <-green nat-> lan
j'etait en 1024, tout marchait bien jusqu'a ma demande de passage en 2048,
une semaine plus tard s'en est suivi une perte de la remote ip lors de la connexion de red,
plus precisement en me basant sur les logs RED d'ipcop:
Avant le passage en 2048:
Après passage en 2048:
Alors que normalment remote IP address aurait du être 86.69.40.1 ...
Evidemment dans les deux cas RED est bien conencté mais plus rien ne peux sortir...
Ce remote IP ne correspond pas à une configuration de la 9box ( qui par ailleurs est en 192.168.1.1 par defaut) ni d'ipcop ( par ailleurs j'ai testé avec deux autres distribs: freesco et linux-livecd-router, la connexion pppoe aboutit toujours à une remote ip 1.1.1.1)
étant dans l'impasse, j'ai opté temporairement pour cette solution:
9box(mode router) <-red dhcp-> ipcop <-green nat-> lan
mais j'ai beaucoup de deconnexion intempestives, et le mode routeur simple de la 9box = DMZ, mais les port forwarding ipcop<->lan marchent très mal...
La question est de savoir comment agir sur la remote IP address attribuée lors de la transaction pppoe...
Mon réseau:
9box(mode bridge) <-red pppoe-> ipcop <-green nat-> lan
j'etait en 1024, tout marchait bien jusqu'a ma demande de passage en 2048,
une semaine plus tard s'en est suivi une perte de la remote ip lors de la connexion de red,
plus precisement en me basant sur les logs RED d'ipcop:
Avant le passage en 2048:
CHAP authentication succeeded
...
local IP address 86.69.46.197
remote IP address 86.69.46.1
Après passage en 2048:
CHAP authentication succeeded
...
default route ioctl(SIOCADDRT): Network is unreachable
local IP address 86.69.40.120
remote IP address 1.1.1.1
Alors que normalment remote IP address aurait du être 86.69.40.1 ...
Evidemment dans les deux cas RED est bien conencté mais plus rien ne peux sortir...
Ce remote IP ne correspond pas à une configuration de la 9box ( qui par ailleurs est en 192.168.1.1 par defaut) ni d'ipcop ( par ailleurs j'ai testé avec deux autres distribs: freesco et linux-livecd-router, la connexion pppoe aboutit toujours à une remote ip 1.1.1.1)
étant dans l'impasse, j'ai opté temporairement pour cette solution:
9box(mode router) <-red dhcp-> ipcop <-green nat-> lan
mais j'ai beaucoup de deconnexion intempestives, et le mode routeur simple de la 9box = DMZ, mais les port forwarding ipcop<->lan marchent très mal...
La question est de savoir comment agir sur la remote IP address attribuée lors de la transaction pppoe...
- EyEBURNeR
- Matelot
- Messages: 1
- Inscrit le: 05 Avr 2006 15:14
par Franck78 » 05 Avr 2006 17:39
La question est de savoir comment agir sur la remote IP address attribuée lors de la transaction pppoe...
En leur démontrant que c'est une config à la noix et en ne lachant pas le morceau!
Mais ca semble mal barré...
http://www.google.fr/custom?domains=www ... 1%3B&hl=fr
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
14 messages
• Page 1 sur 1
Retour vers Accès Internet et FAI
Qui est en ligne ?
Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité