Re: [FRnOG] [MISC] DOC FFT Cahier de tests génériques pour interconnexion IP sur Interface SIP

[Cedric Millet (pro)]

bah c'est juste 2 comportements différents des boucles locales.

c'est bien écrit dans la1ere colonne. une avec raccroché direct avec un
cause spécifée, l'autre avec annonce / early media qui explique le probleme
puis raccroché normal cause 31

D1.2.3
Appel d’une ligne ORT1 (clientA) vers un numéro de l’ORT2
(client B) non attribué

*Cause No. l - Unallocated (unassigned) number [Q.850] *


D2.3.6
Appel d’une ligne ORT1 (clientA)
vers un numéro de l’ORT2(client B) non attribué avec
annonce vocale émise par le demandé (laissez le film jusqu’au bout)


*Cause No. 31 - normal. unspecified [Q.850]*

2017-04-07 22:10 GMT+02:00 Alain Bieuzent :

> merci Cédric pour ce retour, tu confirme bien que l'héritage SS7 reste
> toujours présent.
>
> Pour etre plus précis je n'arrive pas a comprendre la différence entre le
> test D1.2.3 et D2.3.6 ( appel vers un numéro non utilisé) pourquoi dans un
> cas on reçoit un code SIP 404 et dans l'autre un 480 après diffusion du
> message en early media ?
>
> merci pour ton aide.
>
> Envoyé de mon iPad
>
> Le 7 avr. 2017 à 21:09, Cedric Millet (pro)  a
> écrit :
>
> hello
>
> Ces nuances servent (servaient) à mettre en exergue des comportements
> différents dans la sig entre une boucle locale mobile et une boucle locale
> fixe.
> C'est surtout flagrant sur interco SIP-I plus que SIP.
>
> Or historiquement les cahiers de tests FFT sont hérités des cahiers de
> test SS7 puis SIP-I puis SIP. Personne ne réinvente la roue. ^^
>
> Après quelques clics sur google voici un exemple
> - cahier de test SIP-I
> https://www.fftelecoms.org/sites/fftelecoms.org/files/
> cahier%20de%20tests%20SIPI%20FFTVFMR_V1_1%20.pdf
> Regarde les tests D.1.2.4.1 et D.1.2.4.2, les résultats attendus diffèrent.
>
> - alors que dans le cahier de test SIP, il n'y a plus de nuance, et plus
> qu'un seul test D.2.3.6
> http://www.fftelecoms.org/sites/fftelecoms.org/files/
> contenus_lies/cahier_tests_sip_fft_v2.0_rm.pdf
>
> car comme tu le sous entends, pourquoi faire une différence, à mon avis
> c'est juste un héritage et une vigilance qu'il fallait avoir.
> Or les différences s'estompent avec le temps et les réseaux /
> comportements deviennent homogènes quelles que soient les boucles locales.
>
> Dans quelques versions des cahiers de tests, ces notions et subtilités
> auront surement bientôt disparu (tout comme l'ISUP et le SIP-I).
>
> bon we
>
> 2017-04-07 16:10 GMT+02:00 Alain Bieuzent :
>
>> Bonjour la liste.
>>
>>
>>
>> Y a t-il quelqu’un sur cette liste vous qui pourrai m’expliquer la
>> différence entre un « Terminal RNIS mobile » et un terminal non « Terminal
>> RNIS mobile » ???
>>
>>
>>
>> Merci
>>
>>
>>
>> Alain
>>
>>
>>
>>
>>
>>
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] DOC FFT Cahier de tests génériques pour interconnexion IP sur Interface SIP

[Alain Bieuzent]

merci Cédric pour ce retour, tu confirme bien que l'héritage SS7 reste toujours 
présent.

Pour etre plus précis je n'arrive pas a comprendre la différence entre le test 
D1.2.3 et D2.3.6 ( appel vers un numéro non utilisé) pourquoi dans un cas on 
reçoit un code SIP 404 et dans l'autre un 480 après diffusion du message en 
early media ?

merci pour ton aide.

Envoyé de mon iPad

> Le 7 avr. 2017 à 21:09, Cedric Millet (pro)  a écrit 
> :
> 
> hello
> 
> Ces nuances servent (servaient) à mettre en exergue des comportements 
> différents dans la sig entre une boucle locale mobile et une boucle locale 
> fixe. 
> C'est surtout flagrant sur interco SIP-I plus que SIP.
> 
> Or historiquement les cahiers de tests FFT sont hérités des cahiers de test 
> SS7 puis SIP-I puis SIP. Personne ne réinvente la roue. ^^
> 
> Après quelques clics sur google voici un exemple
> - cahier de test SIP-I
> https://www.fftelecoms.org/sites/fftelecoms.org/files/cahier%20de%20tests%20SIPI%20FFTVFMR_V1_1%20.pdf
> Regarde les tests D.1.2.4.1 et D.1.2.4.2, les résultats attendus diffèrent.
> 
> - alors que dans le cahier de test SIP, il n'y a plus de nuance, et plus 
> qu'un seul test D.2.3.6
> http://www.fftelecoms.org/sites/fftelecoms.org/files/contenus_lies/cahier_tests_sip_fft_v2.0_rm.pdf
> 
> car comme tu le sous entends, pourquoi faire une différence, à mon avis c'est 
> juste un héritage et une vigilance qu'il fallait avoir.
> Or les différences s'estompent avec le temps et les réseaux / comportements 
> deviennent homogènes quelles que soient les boucles locales.
> 
> Dans quelques versions des cahiers de tests, ces notions et subtilités auront 
> surement bientôt disparu (tout comme l'ISUP et le SIP-I).
> 
> bon we
> 
> 2017-04-07 16:10 GMT+02:00 Alain Bieuzent :
>> Bonjour la liste.
>> 
>>  
>> 
>> Y a t-il quelqu’un sur cette liste vous qui pourrai m’expliquer la 
>> différence entre un « Terminal RNIS mobile » et un terminal non « Terminal 
>> RNIS mobile » ???
>> 
>>  
>> 
>> Merci
>> 
>>  
>> 
>> Alain
>> 
> 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] DOC FFT Cahier de tests génériques pour interconnexion IP sur Interface SIP

[Cedric Millet (pro)]

hello

Ces nuances servent (servaient) à mettre en exergue des comportements
différents dans la sig entre une boucle locale mobile et une boucle locale
fixe.
C'est surtout flagrant sur interco SIP-I plus que SIP.

Or historiquement les cahiers de tests FFT sont hérités des cahiers de test
SS7 puis SIP-I puis SIP. Personne ne réinvente la roue. ^^

Après quelques clics sur google voici un exemple
- cahier de test SIP-I
https://www.fftelecoms.org/sites/fftelecoms.org/files/cahier%20de%20tests%20SIPI%20FFTVFMR_V1_1%20.pdf
Regarde les tests D.1.2.4.1 et D.1.2.4.2, les résultats attendus diffèrent.

- alors que dans le cahier de test SIP, il n'y a plus de nuance, et plus
qu'un seul test D.2.3.6
http://www.fftelecoms.org/sites/fftelecoms.org/files/contenus_lies/cahier_tests_sip_fft_v2.0_rm.pdf

car comme tu le sous entends, pourquoi faire une différence, à mon avis
c'est juste un héritage et une vigilance qu'il fallait avoir.
Or les différences s'estompent avec le temps et les réseaux / comportements
deviennent homogènes quelles que soient les boucles locales.

Dans quelques versions des cahiers de tests, ces notions et subtilités
auront surement bientôt disparu (tout comme l'ISUP et le SIP-I).

bon we

2017-04-07 16:10 GMT+02:00 Alain Bieuzent :

> Bonjour la liste.
>
>
>
> Y a t-il quelqu’un sur cette liste vous qui pourrai m’expliquer la
> différence entre un « Terminal RNIS mobile » et un terminal non « Terminal
> RNIS mobile » ???
>
>
>
> Merci
>
>
>
> Alain
>
>
>
>
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] DOC FFT Cahier de tests génériques pour interconnexion IP sur Interface SIP

[Alain Bieuzent]

Bonjour la liste.

 

Y a t-il quelqu’un sur cette liste vous qui pourrai m’expliquer la différence 
entre un « Terminal RNIS mobile » et un terminal non « Terminal RNIS mobile » 
???

 

Merci

 

Alain

 

 

 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Hugues VOITURIER]

Ils ont quand même mis des trucs en place pour supporter PPTP/GRE et IPSec dans 
le 4Rd, et selon Rani (Sur lafibre) c'était pas gagné. 

Sent from my iPhone

> On 7 Apr 2017, at 15:56, David Ponzone  wrote:
> 
> Non mais tout CGNAT a ses contraintes, et Free qui a des millions de clients 
> derrière n’ira pas chercher pourquoi son CGNAT gêne des clients pro avec un 
> client VPN précis.
> Déjà qu’ils n’ont rien fait (à ma connaissance) pour les clients qui ont une 
> Playstation4, qui sont certainement nombreux.
> Je ne leur jette pas la pierre, ils sont sur un modèle où la prise en compte 
> des problèmes de Pierre, Paul ou Jacques n’est pas possible.
> 
>> Le 7 avr. 2017 à 15:16, Buzzer  a écrit :
>> 
>> Nous n'avons pas d'ipv6 sur notre accès.
>> Mais je pense effectivement que ce serait la solution.
>> 
>> Cependant ce serait un contournement comme l'ipv4 full-stack. Il n'y a pas 
>> de raison, autre qu'un pb sur l'infra, pour que ça ne fonctionne pas
>> -- 
>> Christophe
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[David Ponzone]

Non mais tout CGNAT a ses contraintes, et Free qui a des millions de clients 
derrière n’ira pas chercher pourquoi son CGNAT gêne des clients pro avec un 
client VPN précis.
Déjà qu’ils n’ont rien fait (à ma connaissance) pour les clients qui ont une 
Playstation4, qui sont certainement nombreux.
Je ne leur jette pas la pierre, ils sont sur un modèle où la prise en compte 
des problèmes de Pierre, Paul ou Jacques n’est pas possible.

> Le 7 avr. 2017 à 15:16, Buzzer  a écrit :
> 
> Nous n'avons pas d'ipv6 sur notre accès.
> Mais je pense effectivement que ce serait la solution.
> 
> Cependant ce serait un contournement comme l'ipv4 full-stack. Il n'y a pas de 
> raison, autre qu'un pb sur l'infra, pour que ça ne fonctionne pas
> -- 
> Christophe
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Buzzer]

Bonjour

Le 7 avril 2017 14:46:01 GMT+02:00, "Jérôme BERTHIER"  a 
écrit :
>Bonjour,
>
>Le 07/04/2017 à 14:08, Buzzer a écrit :
>> Bonjour,
>>
>>
>> Je fais parti d'un service réseau d'une banque, qui a un grand nombre
>d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect
>sur des Cisco ASA en mode dtls.
>>
>>
>> Nous avons constaté que nos utilisateur clients chez Free en fibre
>optique et en zone moyennement dense n'arrivent pas à monter le vpn.
>
>Si DTLS ne fonctionne pas, le client est sensé utiliser la session 
>TCP443 qui est initiée au départ.
>Du coup, c'est bizarre qu'ils "n'arrivent pas à monter le vpn".
>

Le problème justement ce n'est pas que dtls ne marche pas, mais que juste une 
partie de la négociation echoue. Le client reste donc bloqué sur dtls en boucle.

>>
>>
>> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
>entre les utilisateurs.
>>
>>
>> Le symptôme est que le vpn tente de négocié un mtu, mais la perte de
>paquet sur l'infrastructure empêche cette négociation d'aboutir.
>
>Un cas "similaire" semble explicitement décrit :
>http://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116881-technote-anyconnect-00.html
>
>Bon courage ;-)

Merci je n'avais pas trouvé celui là.
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Xavier Beaudouin]

Hello,

>>Et en IPv6 ca donne quoi ?
> 
> Nous n'avons pas d'ipv6 sur notre accès.
> Mais je pense effectivement que ce serait la solution.

Surtout en 2017...

> Cependant ce serait un contournement comme l'ipv4 full-stack. Il n'y a pas de
> raison, autre qu'un pb sur l'infra, pour que ça ne fonctionne pas

Après y a toujours la demande de passage en full stack qui marche... Ou si tu 
veux pas demander a te collègues de passer en ipv6 et/ou en full stack de 
passer via un rebond OpenVPN qui LUI passe a travers le CGN en question.

A noter que... les CGN vont devenir de plus en plus courant... il serait 
intéressant de passer en ipv6 :)

Xavier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Buzzer]

Nous avons déjà testé avec certaine personne de l'IT possédant un firewall.
L'interdiction de l'udp 443 fait tomber en défaut sur TLS (tcp 443) qui lui ne 
pose pas de problème, puisque le tcp gère la négociation des taille (tcp mss) 
et les pertes de paquets.

Cependant cette solution n'est pas optimale pour la TOIP. (UDP Dans un tunnel 
tcp)

Le 7 avril 2017 14:32:28 GMT+02:00, Dominique Rousseau  a 
écrit :
>Le Fri, Apr 07, 2017 at 02:08:37PM +0200, Buzzer [buz...@free.fr] a
>écrit:
>> Bonjour,
>> 
>> Je fais parti d'un service réseau d'une banque, qui a un grand nombre
>> d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect
>> sur des Cisco ASA en mode dtls.
>
>Je connaissais pas, mais Goggle semble dire que c'est de l'UDP sur le
>port 443...
>
>> Nous avons constaté que nos utilisateur clients chez Free en fibre
>> optique et en zone moyennement dense n'arrivent pas à monter le vpn.
>> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
>> entre les utilisateurs.
>
>En ADSL aussi.
>... et du coup, DTLS, ca presume peut-etre des choses sur le port
>source, qui se retrouverait (mal) re-mappé du fait de l'ip partagée.
>
>Tu n'as pas moyen d'utiliser un autre mode que DTLS ?
>
>
>
>-- 
>Dominique Rousseau 
>Neuronnexion, Prestataire Internet & Intranet
>21 rue Frédéric Petit - 8 Amiens
>tel: 03 22 71 61 90 - fax: 03 22 71 61 99 -
>http://www.neuronnexion.coop
>
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Joël DEREFINKO]

"IPv6 serait un contournement"... Oula tu va t'attirer des foudres ici 
Heureusement qu'on est Trolldi !

Joël 

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Buzzer
Envoyé : vendredi 7 avril 2017 15:17
À : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense



Le 7 avril 2017 14:14:43 GMT+02:00, Radu-Adrian Feurdean 
 a écrit :
>On Fri, Apr 7, 2017, at 14:08, Buzzer wrote:
>> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
>> entre les utilisateurs.
>> 
>> Le symptôme est que le vpn tente de négocié un mtu, mais la perte de
>> paquet sur l'infrastructure empêche cette négociation d'aboutir.
>> 
>> La solution fonctionnelle au problème consiste, pour nos
>utilisateurs, à
>> demander une vraie ipv4 (full-stack)
>
>Et en IPv6 ca donne quoi ?

Nous n'avons pas d'ipv6 sur notre accès.
Mais je pense effectivement que ce serait la solution.

Cependant ce serait un contournement comme l'ipv4 full-stack. Il n'y a pas de 
raison, autre qu'un pb sur l'infra, pour que ça ne fonctionne pas
-- 
Christophe
---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Buzzer]

Le 7 avril 2017 14:14:43 GMT+02:00, Radu-Adrian Feurdean 
 a écrit :
>On Fri, Apr 7, 2017, at 14:08, Buzzer wrote:
>> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
>> entre les utilisateurs.
>> 
>> Le symptôme est que le vpn tente de négocié un mtu, mais la perte de
>> paquet sur l'infrastructure empêche cette négociation d'aboutir.
>> 
>> La solution fonctionnelle au problème consiste, pour nos
>utilisateurs, à
>> demander une vraie ipv4 (full-stack)
>
>Et en IPv6 ca donne quoi ?

Nous n'avons pas d'ipv6 sur notre accès.
Mais je pense effectivement que ce serait la solution.

Cependant ce serait un contournement comme l'ipv4 full-stack. Il n'y a pas de 
raison, autre qu'un pb sur l'infra, pour que ça ne fonctionne pas
-- 
Christophe
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Loïc Guiraud]

Bonjour,

La modification pour passer en IPv4 full stack est dispo sur l'interface
client :
http://www.universfreebox.com/article/35583/Freebox-l-option-vraie-IP-fixe-en-ZMD-est-disponible

Loïc

2017-04-07 14:46 GMT+02:00 Jérôme BERTHIER :

> Bonjour,
>
> Le 07/04/2017 à 14:08, Buzzer a écrit :
>
>> Bonjour,
>>
>>
>> Je fais parti d'un service réseau d'une banque, qui a un grand nombre
>> d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect sur
>> des Cisco ASA en mode dtls.
>>
>>
>> Nous avons constaté que nos utilisateur clients chez Free en fibre
>> optique et en zone moyennement dense n'arrivent pas à monter le vpn.
>>
>
> Si DTLS ne fonctionne pas, le client est sensé utiliser la session TCP443
> qui est initiée au départ.
> Du coup, c'est bizarre qu'ils "n'arrivent pas à monter le vpn".
>
>
>>
>> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
>> entre les utilisateurs.
>>
>>
>> Le symptôme est que le vpn tente de négocié un mtu, mais la perte de
>> paquet sur l'infrastructure empêche cette négociation d'aboutir.
>>
>
> Un cas "similaire" semble explicitement décrit :
> http://www.cisco.com/c/en/us/support/docs/security/anyconnec
> t-secure-mobility-client/116881-technote-anyconnect-00.html
>
> Bon courage ;-)
>
>
> --
> Jérôme BERTHIER
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech]Question sur les émissions radio

[Michel Hostettler]

Etienne,

> Mais dans ce cas de figure, tout les appareils désireux de se connecter 
> à cette source proche, mais saturée par du bruit, devraient être 
> affectés de manière équivalente ?

A priori oui, une émission anormalement forte doit occulter les autres.

Maintenant, je ne suis pas un dépanneur expert.
Le PC incriminé dispose peut-être d'une émission Bluetooth active qui dérange 
le Wi-Fi.

Tout est possible, et réciproquement.

Cordialement,
Michel


- Mail original -
De: "Carroussel Informatique" 
À: "Michel Hostettler" 
Cc: frnog@frnog.org
Envoyé: Vendredi 7 Avril 2017 11:52:48
Objet: Re: [FRnOG] [Tech]Question sur les émissions radio

Merci Michel.

C'est en effet plus clair. Il y a donc une exception possible.
Mais dans ce cas de figure, tout les appareils désireux de se connecter 
à cette source proche, mais saturée par du bruit, devraient être 
affectés de manière équivalente ?

> Dans les relations humaines, le bruit peut se transformer en signal... vous 
> avez certainement des exemples sur ce sujet.
En effet :p

Merci beaucoup.
ES

Le 07/04/2017 à 10:32, Michel Hostettler a écrit :
> Bonjour,
>
>> Plus on est loin d'une source radio, moins bonne est la connexion ?
> D'après ce que j'ai compris, vous semblez demander : plus la liaison 
> hertzienne est de distance importante, plus la transmission est entachée 
> d'erreurs.
>
> Ce fait est une question de rapport signal à bruit en réception. Plus la 
> liaison est de grande distance, plus la puissance du signal reçu s'affaiblit, 
> et plus la puissance du bruit cumulé s'accroit.
>
> Le principe a ses limites puisqu'à courte distance, la puissance du signal 
> reçu peut saturer le dispositif de réception, et se trouver au-delà de la 
> limite supérieure attendue. Le signal engendre du bruit à la réception.
>
> Dans les relations humaines, le bruit peut se transformer en signal... vous 
> avez certainement des exemples sur ce sujet.
>
> Cordialement,
> Michel
>
>
> - Mail original -
> De: "Carroussel Informatique" 
> À: frnog@frnog.org
> Envoyé: Vendredi 7 Avril 2017 09:58:21
> Objet: [FRnOG] [Tech]Question sur les émissions radio
>
> Bonjour
>
> Je m'excuse par avance si ma question est stupide, j’espère au moins
> qu'elle vous fera marrer...
>
> Voila : J'ai une cliente qui connecte un de ses PC portable via un
> module CPL wifi de marque Devolo.
> La liaison entre l'ordi le le module me semble à priori bonne...
> Malgré ça, elle rencontre pas mal de soucis pour sortir sur le net.
> Ce qui me cause soucis, c'est que tout les ordis de la maison, et y
> compris le mien, se connectent à l’extérieur.
> Bref...
> Là ou je coince c'est que la cliente me soutiens que la connexion est
> meilleure lorsque elle est loin de la source...
> Évidemment c'est juste son impression, elle n'a pas fait de test... Pour
> moi c'est de la pensée magique...
>
> Mais j'aimerais quand même avoir l'avis de gens avec une vraie expertise
> dans ce domaine :
> Plus on est loin d'une source radio, moins bonne est la connexion ?
> C'est bien juste ?
>
> Merci de vos lumières, et désolé, mais c'est trolldi, les questions de
> noob, c'est permis.
>
> Etienne
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Jérôme BERTHIER]

Bonjour,

Le 07/04/2017 à 14:08, Buzzer a écrit :

Bonjour,


Je fais parti d'un service réseau d'une banque, qui a un grand nombre 
d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect sur des 
Cisco ASA en mode dtls.


Nous avons constaté que nos utilisateur clients chez Free en fibre optique et 
en zone moyennement dense n'arrivent pas à monter le vpn.


Si DTLS ne fonctionne pas, le client est sensé utiliser la session 
TCP443 qui est initiée au départ.

Du coup, c'est bizarre qu'ils "n'arrivent pas à monter le vpn".




Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4 entre les 
utilisateurs.


Le symptôme est que le vpn tente de négocié un mtu, mais la perte de paquet sur 
l'infrastructure empêche cette négociation d'aboutir.


Un cas "similaire" semble explicitement décrit :
http://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116881-technote-anyconnect-00.html

Bon courage ;-)


--
Jérôme BERTHIER


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Dominique Rousseau]

Le Fri, Apr 07, 2017 at 02:08:37PM +0200, Buzzer [buz...@free.fr] a écrit:
> Bonjour,
> 
> Je fais parti d'un service réseau d'une banque, qui a un grand nombre
> d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect
> sur des Cisco ASA en mode dtls.

Je connaissais pas, mais Goggle semble dire que c'est de l'UDP sur le
port 443...

> Nous avons constaté que nos utilisateur clients chez Free en fibre
> optique et en zone moyennement dense n'arrivent pas à monter le vpn.
> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
> entre les utilisateurs.

En ADSL aussi.
... et du coup, DTLS, ca presume peut-etre des choses sur le port
source, qui se retrouverait (mal) re-mappé du fait de l'ip partagée.

Tu n'as pas moyen d'utiliser un autre mode que DTLS ?



-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Radu-Adrian Feurdean]

On Fri, Apr 7, 2017, at 14:08, Buzzer wrote:
> Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4
> entre les utilisateurs.
> 
> Le symptôme est que le vpn tente de négocié un mtu, mais la perte de
> paquet sur l'infrastructure empêche cette négociation d'aboutir.
> 
> La solution fonctionnelle au problème consiste, pour nos utilisateurs, à
> demander une vraie ipv4 (full-stack)

Et en IPv6 ca donne quoi ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Fibre FREE en zone moyennement dense

[Buzzer]

Bonjour,


Je fais parti d'un service réseau d'une banque, qui a un grand nombre 
d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect sur des 
Cisco ASA en mode dtls.


Nous avons constaté que nos utilisateur clients chez Free en fibre optique et 
en zone moyennement dense n'arrivent pas à monter le vpn.


Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4 entre les 
utilisateurs.


Le symptôme est que le vpn tente de négocié un mtu, mais la perte de paquet sur 
l'infrastructure empêche cette négociation d'aboutir.


La solution fonctionnelle au problème consiste, pour nos utilisateurs, à 
demander une vraie ipv4 (full-stack)


J'ai donc plusieurs questions à une éventuelle personne de Free lisant la liste 
:

Ce problème est-il connu ?

L'infrastructure partage d'ipv4 et ipv4 full-stack sont-elles distinctes?

Comment fait-on pour joindre FREE dans ce genre de cas, sachant que tous les 
numéros que j'ai essayé, finissent toujours pareil : quel est votre numéro 
d'abonné ?


Merci de votre aide

-- 
Christophe
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech]Question sur les émissions radio

[Carroussel Informatique]

Merci Michel.

C'est en effet plus clair. Il y a donc une exception possible.
Mais dans ce cas de figure, tout les appareils désireux de se connecter 
à cette source proche, mais saturée par du bruit, devraient être 
affectés de manière équivalente ?



Dans les relations humaines, le bruit peut se transformer en signal... vous 
avez certainement des exemples sur ce sujet.

En effet :p

Merci beaucoup.
ES

Le 07/04/2017 à 10:32, Michel Hostettler a écrit :

Bonjour,


Plus on est loin d'une source radio, moins bonne est la connexion ?

D'après ce que j'ai compris, vous semblez demander : plus la liaison hertzienne 
est de distance importante, plus la transmission est entachée d'erreurs.

Ce fait est une question de rapport signal à bruit en réception. Plus la 
liaison est de grande distance, plus la puissance du signal reçu s'affaiblit, 
et plus la puissance du bruit cumulé s'accroit.

Le principe a ses limites puisqu'à courte distance, la puissance du signal reçu 
peut saturer le dispositif de réception, et se trouver au-delà de la limite 
supérieure attendue. Le signal engendre du bruit à la réception.

Dans les relations humaines, le bruit peut se transformer en signal... vous 
avez certainement des exemples sur ce sujet.

Cordialement,
Michel


- Mail original -
De: "Carroussel Informatique" 
À: frnog@frnog.org
Envoyé: Vendredi 7 Avril 2017 09:58:21
Objet: [FRnOG] [Tech]Question sur les émissions radio

Bonjour

Je m'excuse par avance si ma question est stupide, j’espère au moins
qu'elle vous fera marrer...

Voila : J'ai une cliente qui connecte un de ses PC portable via un
module CPL wifi de marque Devolo.
La liaison entre l'ordi le le module me semble à priori bonne...
Malgré ça, elle rencontre pas mal de soucis pour sortir sur le net.
Ce qui me cause soucis, c'est que tout les ordis de la maison, et y
compris le mien, se connectent à l’extérieur.
Bref...
Là ou je coince c'est que la cliente me soutiens que la connexion est
meilleure lorsque elle est loin de la source...
Évidemment c'est juste son impression, elle n'a pas fait de test... Pour
moi c'est de la pensée magique...

Mais j'aimerais quand même avoir l'avis de gens avec une vraie expertise
dans ce domaine :
Plus on est loin d'une source radio, moins bonne est la connexion ?
C'est bien juste ?

Merci de vos lumières, et désolé, mais c'est trolldi, les questions de
noob, c'est permis.

Etienne


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech]Question sur les émissions radio

[Carroussel Informatique]

Bonjour David

Le 07/04/2017 à 10:15, David Ponzone a écrit :

Perso, j’ai pas tout compris à l’archi.
Quelqu’un d’autre utilise le WIFI de ce module CPL ?

L'architecture du réseau est simple :
- A l'étage, une box, de chez OVH, avec capacité wifi.
- Au rez de chaussée, un point d’accès wifi delovo, relié à la box par 
un câble Ethernet qui se balade entre les étages, mais je sais pas comment.


C'est une vieille maison Vaudoise, en pierre, avec des murs épais. 
Suffisamment pour bloquer le signal de la box entre le troisième étage 
et le rez de chaussée. D’où l’intérêt du module CPL.

L'installation filaire est de type "je ne veux pas toucher à ça"

Sur ce PA, j'ai eu jusque 3 pc connectés, plus une tablette et un 
téléphone. Même tous simultanément je n'ai pas eu de soucis... (mais je 
vais quand même vérifier).
Tout les appareils que j'ai pu connecter, ont vu le PA, et sont "sorti" 
sur le net. (avec des pings et des traceroute).
Seul un appareil a refusé de sortir. Un PC portable Asus, tournant sous 
ubuntu 16.04, avec une puce wifi realtek.
(problème similaire : 
https://askubuntu.com/questions/872313/wireless-issues-on-16-04-with-rtl8821ae-asus-e202s)


A priori, je pense que c'est le PC, pas le PA, mais sait on jamais.

Merci.
ES


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech]Question sur les émissions radio

[frnog . kapush]

On vendredi 7 avril 2017 09:58:21 CEST Carroussel Informatique - 
carrous...@wanadoo.fr wrote:
> Bonjour
> 
> Je m'excuse par avance si ma question est stupide, j’espère au moins
> qu'elle vous fera marrer...
> 
> Voila : J'ai une cliente qui connecte un de ses PC portable via un
> module CPL wifi de marque Devolo.
> La liaison entre l'ordi le le module me semble à priori bonne...
> Malgré ça, elle rencontre pas mal de soucis pour sortir sur le net.
> Ce qui me cause soucis, c'est que tout les ordis de la maison, et y
> compris le mien, se connectent à l’extérieur.
> Bref...
> Là ou je coince c'est que la cliente me soutiens que la connexion est
> meilleure lorsque elle est loin de la source...
> Évidemment c'est juste son impression, elle n'a pas fait de test... Pour
> moi c'est de la pensée magique...
> 
> Mais j'aimerais quand même avoir l'avis de gens avec une vraie expertise
> dans ce domaine :
> Plus on est loin d'une source radio, moins bonne est la connexion ?
> C'est bien juste ?
> 
> Merci de vos lumières, et désolé, mais c'est trolldi, les questions de
> noob, c'est permis.
> 
> Etienne
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Bonjour Etienne,

Même si en théorie et dans un environnement parfait plus la distance est 
grande entre le point d'accès et le client et plus le signal est atténué, en 
pratique ce n'est pas aussi simple que ça.

Déjà qu'est ce que tu entends par "bonne" connexion ? 
Latence, débit, stabilité sont trois choses différentes. 

Dans la pratique, tant qu'on reste à portée, il n'est pas impossible que la 
qualité de la connexion s'améliore en s'éloignant du point d'accès, par 
exemple dépendamment de la topologie des lieux qui peut causer des rebonds qui 
génèrent des interférences, ou selon le diagramme de rayonnement des antennes 
qui peuvent comporter des oreilles ou des trous. 
Dans tous les cas, le mieux c'est de faire des relevés sur place pour te faire 
une idée.

Cordialement


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech]Question sur les émissions radio

[Michel Hostettler]

Bonjour,

> Plus on est loin d'une source radio, moins bonne est la connexion ?

D'après ce que j'ai compris, vous semblez demander : plus la liaison hertzienne 
est de distance importante, plus la transmission est entachée d'erreurs.

Ce fait est une question de rapport signal à bruit en réception. Plus la 
liaison est de grande distance, plus la puissance du signal reçu s'affaiblit, 
et plus la puissance du bruit cumulé s'accroit.

Le principe a ses limites puisqu'à courte distance, la puissance du signal reçu 
peut saturer le dispositif de réception, et se trouver au-delà de la limite 
supérieure attendue. Le signal engendre du bruit à la réception.

Dans les relations humaines, le bruit peut se transformer en signal... vous 
avez certainement des exemples sur ce sujet.

Cordialement,
Michel


- Mail original -
De: "Carroussel Informatique" 
À: frnog@frnog.org
Envoyé: Vendredi 7 Avril 2017 09:58:21
Objet: [FRnOG] [Tech]Question sur les émissions radio

Bonjour

Je m'excuse par avance si ma question est stupide, j’espère au moins 
qu'elle vous fera marrer...

Voila : J'ai une cliente qui connecte un de ses PC portable via un 
module CPL wifi de marque Devolo.
La liaison entre l'ordi le le module me semble à priori bonne...
Malgré ça, elle rencontre pas mal de soucis pour sortir sur le net.
Ce qui me cause soucis, c'est que tout les ordis de la maison, et y 
compris le mien, se connectent à l’extérieur.
Bref...
Là ou je coince c'est que la cliente me soutiens que la connexion est 
meilleure lorsque elle est loin de la source...
Évidemment c'est juste son impression, elle n'a pas fait de test... Pour 
moi c'est de la pensée magique...

Mais j'aimerais quand même avoir l'avis de gens avec une vraie expertise 
dans ce domaine :
Plus on est loin d'une source radio, moins bonne est la connexion ? 
C'est bien juste ?

Merci de vos lumières, et désolé, mais c'est trolldi, les questions de 
noob, c'est permis.

Etienne


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] Contacts pour Societé de Maintenance en datacenters

[Jérémy RIZZOLI]

Précision importante par rapport à cette annonce sur laquelle nombre
d'entre vous m'ont déjà répondu et je vous en remercie

Ce sera dans le cadre d'un appel d'offre, donc pour le moment c'est une
prise de contacts, ne vous étonnez pas si on ne répond pas tout de suite,
on se donne 1 semaine pour collecter, 1 semaine pour vous recontacter et 1
semaine pour lancer l'appel d'offre.
Les processus internes ça peu prendre du temps ...

Autres précisions importantes, on privilégiera une societé capable
d'intervenir sur les 3 pays: France (Paris), Allemagne (Frankfurt) et Suède
idéalement (mais pour celui-ci on se fait pas trop d'illusions quand même)
car notre intéret c'est de gérer le stock sur les 3 surtout ..
Les équipements vont du système pur (serveurs) aux équipement telco legacy
parfois complexes en passant par du Réseau pur (switchs/routeurs), là aussi
on privilégiera le savoir-faire et l'expérience forcément .. et les équipes
qui ont déjà tout dans leurs valises (Fibres / câbles série / PC avec
connection 4G, matos de spare demandé,  etc etc)

En attendant merci pour l'efficacité de certains sur cette Mailling-list,
les contacts [BiZ] c'est tout de même impressionant de réactivité ..

Jérémy


Le 7 avril 2017 à 09:39, Jérémy RIZZOLI  a écrit :

> Bonjour à tous,
>
> Nous sommes actuellement à la recherche d'une societé prestataire pour
> faire la maintenance physique complète de nos équipements en Datacenter, en
> France et en Allemagne notamment.
>
> Il s'agirait entre autres de:
>
>
>- Racker / Dé-racker des machines  et/ou équipements réseaux
>- Savoir configurer un iDRAC/ILO/ilom/IPMI avec un minimum
>d'instructions
>- Câblage et etiquettage propre avec référentiel et respect de
>consignes imposées.
>- Remplacement de cartes et/ou composants hardware dans des machines
>ou équipements (Disques durs, RAM, switchs, controlleurs)
>- Debug physique basique: savoir se connecter sur une console série
>sur les équipements avec un PC/adaptateur et idéalement possibilité
>d'intervention remote pour nous en cas de gros pépins.
>- Gestion complète d'un stock de pièce de spare, stockage inclu
>idéalement.
>
> Bref, être nos yeux et nos mains sur site.
> Le tout en autonomie totale dans nos emplacements de DC en France,
> Allemagne et Suède , avec si possible une Garantie de temps d'intervention
> <4h.
>
>
> Si vous avez des contacts de societé à même de gérer cela et avec une
> certaine réputation/professionalisme, je suis preneur.
>
> Merci
>
> Bien cordialement
>
> Jérémy Rizzoli
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech]Question sur les émissions radio

[David Ponzone]

Perso, j’ai pas tout compris à l’archi.
Quelqu’un d’autre utilise le WIFI de ce module CPL ?

La radio peut réserver quelques surprises.
Chaque émetteur radio a un rayonnement précis, qu’on peut connaitre sur le 
matériel sérieux grâce à un diagramme de rayonnement fourni avec.
Et il peut y avoir des trous de couverture, surtout sur du matériel comme 
celui-là, pas sérieux et grand public.
Après, il faut se méfier des impressions des clients…..et aller sur place pour 
tester.
Ou lui dire de lancer Teamviewer, te connecter dessus, et lui demander de se 
déplacer.
Si vraiment, sa navigation Internet est modifiée, la fluidité de ton accès TV 
devrait aussi en prendre un coup.


> Le 7 avr. 2017 à 09:58, Carroussel Informatique  a 
> écrit :
> 
> Bonjour
> 
> Je m'excuse par avance si ma question est stupide, j’espère au moins qu'elle 
> vous fera marrer...
> 
> Voila : J'ai une cliente qui connecte un de ses PC portable via un module CPL 
> wifi de marque Devolo.
> La liaison entre l'ordi le le module me semble à priori bonne...
> Malgré ça, elle rencontre pas mal de soucis pour sortir sur le net.
> Ce qui me cause soucis, c'est que tout les ordis de la maison, et y compris 
> le mien, se connectent à l’extérieur.
> Bref...
> Là ou je coince c'est que la cliente me soutiens que la connexion est 
> meilleure lorsque elle est loin de la source...
> Évidemment c'est juste son impression, elle n'a pas fait de test... Pour moi 
> c'est de la pensée magique...
> 
> Mais j'aimerais quand même avoir l'avis de gens avec une vraie expertise dans 
> ce domaine :
> Plus on est loin d'une source radio, moins bonne est la connexion ? C'est 
> bien juste ?
> 
> Merci de vos lumières, et désolé, mais c'est trolldi, les questions de noob, 
> c'est permis.
> 
> Etienne
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [Tech]Question sur les émissions radio

[Carroussel Informatique]

Bonjour

Je m'excuse par avance si ma question est stupide, j’espère au moins 
qu'elle vous fera marrer...


Voila : J'ai une cliente qui connecte un de ses PC portable via un 
module CPL wifi de marque Devolo.

La liaison entre l'ordi le le module me semble à priori bonne...
Malgré ça, elle rencontre pas mal de soucis pour sortir sur le net.
Ce qui me cause soucis, c'est que tout les ordis de la maison, et y 
compris le mien, se connectent à l’extérieur.

Bref...
Là ou je coince c'est que la cliente me soutiens que la connexion est 
meilleure lorsque elle est loin de la source...
Évidemment c'est juste son impression, elle n'a pas fait de test... Pour 
moi c'est de la pensée magique...


Mais j'aimerais quand même avoir l'avis de gens avec une vraie expertise 
dans ce domaine :
Plus on est loin d'une source radio, moins bonne est la connexion ? 
C'est bien juste ?


Merci de vos lumières, et désolé, mais c'est trolldi, les questions de 
noob, c'est permis.


Etienne


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Contacts pour Societé de Maintenance en datacenters

[Jérémy RIZZOLI]

Bonjour à tous,

Nous sommes actuellement à la recherche d'une societé prestataire pour
faire la maintenance physique complète de nos équipements en Datacenter, en
France et en Allemagne notamment.

Il s'agirait entre autres de:


   - Racker / Dé-racker des machines  et/ou équipements réseaux
   - Savoir configurer un iDRAC/ILO/ilom/IPMI avec un minimum d'instructions
   - Câblage et etiquettage propre avec référentiel et respect de consignes
   imposées.
   - Remplacement de cartes et/ou composants hardware dans des machines ou
   équipements (Disques durs, RAM, switchs, controlleurs)
   - Debug physique basique: savoir se connecter sur une console série sur
   les équipements avec un PC/adaptateur et idéalement possibilité
   d'intervention remote pour nous en cas de gros pépins.
   - Gestion complète d'un stock de pièce de spare, stockage inclu
   idéalement.

Bref, être nos yeux et nos mains sur site.
Le tout en autonomie totale dans nos emplacements de DC en France,
Allemagne et Suède , avec si possible une Garantie de temps d'intervention
<4h.


Si vous avez des contacts de societé à même de gérer cela et avec une
certaine réputation/professionalisme, je suis preneur.

Merci

Bien cordialement

Jérémy Rizzoli

---
Liste de diffusion du FRnOG
http://www.frnog.org/