Re: [FRnOG] [TECH] Certificats ssl - rechercher les sites proteges par une CA en particulier ?

[Frederic Dumas]

Bonjour,

> https://search.censys.io/
> il faut juste que tu spécifies que tu cherche un certificat.


par exemple avec l'opérateur 
services.tls.certificate.parsed.issuer.serial_number: , le mode de recherche 
"host" sur Censys permet aussi d'utiliser les certificats comme critère de 
recherche. Les résultats retournés font penser à nmap sous stéroïdes. 

Sais-tu quel opérateur de recherche utiliser dans le mode "host", pour ne faire 
apparaitre dans les résultats que les machines avec des certificats en cours de 
validité ? Le label "unexpired" ne fonctionne que dans le mode de recherche 
"certificate". Je n'ai pas su prompter l'outil censysgpt pour lui faire 
construire une requête "host" avec la notion d'expiration du certificat.

Merci de nous avoir parlé de censys, c'est un bel outil.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


> Le 20 sept. 2024 à 13:09, Shams Hanna via frnog  a écrit :
> 
> Bonjour, 
> 
> Tu peux utiliser Censys aussi avec la query "parsed.serial_number="
> https://search.censys.io/
> il faut juste que tu spécifies que tu cherche un certificat.





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

[FRnOG] [TECH] Wanadoo / SMTP Pro Orange - Defaut d'alignement DMARC vers Gmail

[Frederic Dumas]

Bonjour,

un ami s'occupe d'une asso, il reçoit de Gmail des rapports de non alignement 
DMARC quand il fait des envois groupés de mails par plusieurs dizaines de 
membres à la fois. Les SMTP et DNS de l'association sont chez Orange. Le client 
de messagerie est configuré pour utiliser le SMTP d'Orange.


émetteur Wanadoo/Orange -> récepteur Gmail

> ;; ANSWER SECTION:
> chenes-lieges.fr. 86400 IN MX 10 smtppromx.orange.fr.


Extrait d'en-tête de mail reçu par Gmail:

> Return-Path: 
> Received: from msa.smtpout.orange.fr (msa-210.smtpout.orange.fr. 
> [193.252.23.210])
> by mx.google.com with ESMTPS id 
> a640c23a62f3a-a7dc9d67bf0si583820266b.458.2024.08.06.07.21.12
> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
> Tue, 06 Aug 2024 07:21:12 -0700 (PDT)
> Received-SPF: pass (google.com: domain of bur...@chenes-lieges.fr designates 
> 193.252.23.210 as permitted sender) client-ip=193.252.23.210;
> Authentication-Results: mx.google.com;
>dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=NJG4EMTN;
>spf=pass (google.com: domain of bur...@chenes-lieges.fr designates 
> 193.252.23.210 as permitted sender) smtp.mailfrom=bur...@chenes-lieges.fr
> Received: from opme11oxa06aub.op.aub.pom.fr.intraorange ([10.110.82.102])
> by smtp.orange.fr with ESMTP
> id bKWrsIy8K95X4bKWrse6ja; Tue, 06 Aug 2024 15:47:09 +0200
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr;
> s=t20230301; t=1722952029;
> bh=zPh5QVE5V/dBG4I71BoetuM6g6wws1P+gXS11HgUY6M=;
> h=Date:From:Message-ID:Subject:MIME-Version;
> b=NJG4EMTN6NqLe4PgvI9GEtxf43o/8snDCk9TRVm4kz2q4VVzQeQwtwMo1Q5y2DjJ6
> HMiMS7kGVvDxWc4NdBvsufsgmTDRqEE9nhCVhJT7BJ3zvntmFjeLZcCUjPmzag36C0
> ZFtAvDHKpbiGC7XLU18RL7mauqu3YvlSfWtzYKObSeuatPaEsat4C+sl2SJ1Zp2Jow
> Qg37S7PdUOFslgLVAqz7SgdbAXqkkNZ0jbAQob6Ue9JTdTE8n2RHVHaLEopbulCp8w
> +7Dc2Wj3oJ1Xo9e6hHzT4dzn/tlJXM5vfjyaHSqe/6YxZP9x9df9dpKDjDY/PRb7Gh
> 4DzKjZGteDHgA==
[SNIP]
> Date: Tue, 6 Aug 2024 15:47:09 +0200 (CEST)
> From: CHENES LIEGES 


Associés au domaine chenes-lieges.fr , on trouve les enregistrements suivants:

> ;; ANSWER SECTION:
> chenes-lieges.fr. 2045 IN TXT "v=spf1 include:wanadoo.fr ?all"
> chenes-lieges.fr. 2045 IN TXT 
> "google-site-verification=1eSWSCk_dqxgN_ZpzPl5CN6kXvZYoJOLsZb3Qyj_6wk"


> ;; ANSWER SECTION:
> _dmarc.chenes-lieges.fr. 2401 IN TXT "v=DMARC1; p=quarantine; aspf=r"


Par contre

> dig t20230301._domainkey.chenes-lieges.fr TXT

ne renvoie aucune réponse. Pour trouver la clé DKIM associée au sélecteur 
t20230301, il faut interroger le domain wanadoo.fr:

> % dig t20230301._domainkey.wanadoo.fr TXT

> ;; ANSWER SECTION:
> t20230301._domainkey.wanadoo.fr. 3600 IN TXT "v=DKIM1; k=rsa; 
> p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuPHvs+06M3wpFzT/WbbK+NOTyyfnTuXfjkjFXqyhykcu7jrvYwXzz4aw1VswJmaLs3s7aHS7SUQcMcl70IazW1FR1aYvBpf4OGrefekbPnRSxbH9keC0h2KQtGozzkfi2+BMduaEVJ7eZtCcK073bvWHUZ"
>  
> "W2wiDtZVLtiVzcooT4NFOvHgEi9L/j6tflm71iZYdyf+XoY/AzdRrf7+OBrCZ5eUiFHHEQw8PXYWmKvKGjslDW+sQGcOV48h15JJg3RgWANHKsSv0Z2NzcIlFatrTuc+Lw6QmbUaVTs309LupW/bXZXpOpr4XkxAZmz+Y64PeRh9B/i2Arh2Gbxv+NFwIDAQAB;"



La validation par Gmail de DKIM sur le domaine wanadoo.fr et non sur 
chenes-lieges.fr est-elle la cause du défaut d'alignement DMARC ? Le panneau de 
configuration des abonnées Orange Pro a-t-il un paramètre pour importer sur le 
domaine chenes-lieges.fr la configuration DKIM de wanadoo.fr ?


Merci pour vos conseils.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr




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

Re: [FRnOG] [TECH] Certificats ssl - rechercher les sites proteges par une CA en particulier ?

[Frederic Dumas]

Merci Shams et Florian pour vos réponses. Censys exige des opérateurs de 
recherche texte, mais grâce à l'auto-completion, ça ne demande pas beaucoup 
d'efforts à prendre en main. J'y ai trouvé les résultats que je cherchais 
(statistiques pas très fines de certificats dv signés par un certificat 
intermédiaire en particulier, sur quelques pays européens). Censys ne permet 
pas malheureusement de personnaliser l'ordre de tri des résultats.

Censys autorise 250 requêtes par mois quand on crée un compte, au-delà la 
tarification commerciale tape un peu. Les requêtes filent vite, passer d'une 
page de résultats à la suivante compte pour une requête supplémentaire. Cliquer 
sur un choix offert par l'auto-completion, sans avoir vraiment pu écrire encore 
la requête, consomme aussi une requête ! On a intérêt à ouvrir un bloc-note 
dans une fenêtre à coté.

Les certificats DV ne portent pas d'autres informations personnelles que le 
common name, donc l'opérateur de recherche parsed.subject.common_name="*.fr" 
montre rapidement sa limite pour une recherche géographique. Sans grande valeur 
statistique, on peut s'amuser un peu, par exemple 
parsed.subject.common_name="*paris*". Curieusement, les requêtes 
‘parsed.subject.common_name=’*.ru‘’ et parsed.subject.common_name=‘*.by’ 
renvoient des ensembles vides. Y-a-t-il un lien avec les sanctions contre la 
Russie et la Bielorussie ? Qui a entendu qu'elles aient concerné les moteurs de 
recherche ?!?

Sur crt.sh, pour trouver la boite de dialogue de recherche des certificats 
enfants dont tu parles Florian, il faut cliquer sur le lien "Issuer Name" et 
non le lien "crt.sh ID" du certificat parent. On peut passer facilement à coté. 
À partir de là, une recherche sans filtre affiche par ordre chronologique la 
masse colossale des derniers certificats leaf signés. Est-ce que tu parviens à 
lancer une recherche plus fine de certificats leaf sur crt.sh ? Un simple 
"*.fr" sur le common name, et c'est une attente sans fin, sans aucun résultat.

Entre crt.sh et Censys, le second est beaucoup plus utilisable.

Merci encore pour vos infos. Ça a fait le boulot.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


> Le 20 sept. 2024 à 13:21, Florian Stosse  a écrit :
> 
> Bonjour,
> 
> https://crt.sh/ permet de faire une recherche avancée, si vous connaissez
> le nom de la CA et/ou son ID, et de lister les certificats connus liés.
> Exemple avec ISRG Root X1, autorité racine de Let's Encrypt :
> 
> https://crt.sh/?Identity=%25&iCAID=7394
> 
> --
> Florian STOSSE | Ingénieur en sécurité informatique



> Le 20 sept. 2024 à 13:09, Shams Hanna  a écrit :
> 
> Bonjour, 
> 
> Tu peux utiliser Censys aussi  avec la query "parsed.serial_number="
> https://search.censys.io/
> il faut juste que tu spécifies que tu cherche un certificat.
> 
> 
> Shams Hanna
> sh...@astroman.dev
> https://astroman.dev
> https://as215605.net
> https://lg.as215605.net






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

Re: [FRnOG] [TECH] Certificats ssl - rechercher les sites proteges par une CA en particulier ?

[Frederic Dumas]

Merci Julien pour l'info sur shodan, merci Paul aussi, je découvre. Y créer un 
compte n'obligeait pas à sortir la carte, ça devient peut-être payant à partir 
d'un volume de requêtes ?

L'opérateur de recherche que tu donnes en exemple Julien - ssl.cert.subject.cn: 
- , il lance la recherche sur le Common Name. Un autre opérateur permettrait de 
lancer la recherche sur l' Organisational Unit Name, le serial number ou le 
hash digest du certificat ? RTFM.


Richard, sympa l'info sur les google dorks. Je n'ai pas creusé, mais les 
exemples donnés laissent penser que ça fouine dans tout ce qui vient par le 
traffic http(s) et à pu être capturé par Google. Ce que je cherche se base sur 
le contenu du certificat, ça vient avant http, au moment de la négociation tls. 
Je garde l'idée des dorks sous le coude, mais à vérifier si ça travaille au bon 
endroit.


Sinon, sslmate met une api de recherche des logs 'certificate transparency' en 
libre usage, avec une limite de 100 requêtes par jour. Après c'est payant. Et 
il faut allumer python pour parler à l'api. :-)

https://sslmate.com/ct_search_api/


--
Frédéric Dumas
f.du...@ellis.siteparc.fr



> Le 19 sept. 2024 à 14:03, Julien Rouxel via frnog  a écrit :
> 
> Bonjour,
> 
> Shodan permet de faire des recherche sur les certificats
> 
> https://www.shodan.io/search?query=ssl.cert.subject.cn%3Agoogle.com+-HTTP
> 
> Julien
> 
> On 2024-09-19 12:37:21, Frederic Dumas wrote:
>> 
>> Bonjour à tous,
>> 
>> comment faire s'afficher en résultat sur Google ou un autre moteur de 
>> recherche, les sites web protégés par une autorité de certification en 
>> particulier ?
>> 
>> J'ai essayé d'utiliser en mot clé des éléments tirés de la chaine de 
>> certification ssl/tls, mais ça ne marche pas, les résultats sont noyés par 
>> les pages web de l'autorité de certification elle-même. La recheche ne 
>> renvoie pas les sites web dont les certificats ssl sont signés par cette 
>> autorité.
>> 
>> Ce n'est pas mon cas d'usage exact, mais une utilité de ce genre de 
>> recherche pourrait être d'identifier des sites protégés par Entrust, par 
>> exemple.
>> 
>> Les logs "certificate transparency" pourraient être une piste, mais des 
>> outils comme crt.sh ne semblent pas conçus pour sortir des listes, des 
>> relations, mais seulement des certificats pris individuellement, à condition 
>> de connaître déjà un élément distinctif, comme  par exemple leur numéro de 
>> série ou leur hash digest.
>> 
>> 
>> Quelqu'un saura peut-être ici comment construire une requête Google pour 
>> mettre le focus sur la chaine de validation ssl ?
>> 
>> Merci.
>> 
>> --
>> Frédéric Dumas
>> f.du...@ellis.siteparc.fr






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

[FRnOG] [TECH] Certificats ssl - rechercher les sites proteges par une CA en particulier ?

[Frederic Dumas]

Bonjour à tous,

comment faire s'afficher en résultat sur Google ou un autre moteur de 
recherche, les sites web protégés par une autorité de certification en 
particulier ?

J'ai essayé d'utiliser en mot clé des éléments tirés de la chaine de 
certification ssl/tls, mais ça ne marche pas, les résultats sont noyés par les 
pages web de l'autorité de certification elle-même. La recheche ne renvoie pas 
les sites web dont les certificats ssl sont signés par cette autorité.

Ce n'est pas mon cas d'usage exact, mais une utilité de ce genre de recherche 
pourrait être d'identifier des sites protégés par Entrust, par exemple.

Les logs "certificate transparency" pourraient être une piste, mais des outils 
comme crt.sh ne semblent pas conçus pour sortir des listes, des relations, mais 
seulement des certificats pris individuellement, à condition de connaître déjà 
un élément distinctif, comme  par exemple leur numéro de série ou leur hash 
digest.


Quelqu'un saura peut-être ici comment construire une requête Google pour mettre 
le focus sur la chaine de validation ssl ?

Merci.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr




smime.p7s
Description: S/MIME cryptographic signature

Re: [FRnOG] [TECH] Contact SFR Demande IPV4 dédié OK mais filtrage ports en amont empêchant l’accès au service via port forwarding

[Frederic Dumas]

Bonjour Benoît,

> En analysant le problème j'ai détecté que le port en question semble 
> bloqué/filtré par SFR en amont de la box.

Sans te donner la martingale, peut-être faut-il aller moins vite en besogne, et 
vérifier encore une fois si une règle pour chacun des ports sur lesquels 
OpenVPN écoute est bien en place sur ton routeur. En udp comm en tcp ? Quand 
nmap signale "filtered", c'est qu'il ne reçoit aucune réponse, juste le 
silence. Une règle de forward mal définie sur ton routeur pourrait avoir 
exactement cet effet là: le paquet entrant passe le NAT et n'aboutit à rien. 
Donc évidemment il n'y a aucune réponse. Le temps d'un test, si ton routeur 
dispose de cette fonction, lui désigner l'IP LAN de ton OpenVPN comme étant la 
"DMZ". Les routeurs SoHo ont parfois cette appellation: indépendamment de toute 
règle de translation d'adresse, cette option redirige alors tout et n'importe 
quel paquet entrant vers l'IP LAN de ton OpenVPN, parce qu'il est "la DMZ"; à 
ce moment, il est complètement exposé à l'Internet et rien dans ta 
configuration ne devrait t'empêcher de l'atteindre depuis l'extérieur.

C'est vrai que les FAI nous ont habitué à filtrer certains ports, à notre insu 
de notre plein gré; mais ici tu as testé aussi des ports classiques http(s), et 
reproduit le même problème. Ça laisse espérer que la configuration de ton 
routeur soit la cause, facile à corriger. Bonne chance.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


> Le 10 sept. 2024 à 16:22, Benoît LAVIALE  a écrit :
> 
> Bonjour à tous,
> 
> Y aurait il quelqu'un chez SFR  qui serait en mesure de m'aiguiller au sujet 
> de la problématique suivante :
> 
> J'ai une ligne SFR fibre qui était en "partage" d'ip (Une IP public pour 
> plusieurs clients). J'ai donc fait une demande d'IP "fullstack" afin d'avoir 
> une IP dédiée.
> 
> Un fois l'ip dédiée active, j'ai bien eu accès dans ma box SFR à l'interface 
> permettant de faire du routage de port/port forwarding.
> Une fois avoir mis des règles de port forwarding au niveau de la box  j'ai 
> tenté de me connecter au service derrière ma box sans succés.
> 
> En analysant le problème j'ai détecté que le port en question semble 
> bloqué/filtré par SFR en amont de la box.
> 
> Je n'arrive pas à avoir quelqu'un chez SFR pour me débloquer...
> 
> Je fais une erreur dans mon analyse?
> 
> Ci après la trace de mes analyses (IP fictive et  Port fictif). Pour le vrai 
> numéro de port je suis dans les 60k+. J'ai essayé avec des ports classiques 
> (80/443) -> meme résultat -> "filtered".
> 
> Le service à l'écoute est un OpenVPN qui en "local"(192.168.0.0/24) 
> fonctionne.
> 
> Merci
> 
> 
> benoit@pc-benoit:~$ nmap -p 3615  95.173.136.72
> Starting Nmap 7.93 ( https://nmap.org ) at 2024-08-15 21:10 CEST
> Note: Host seems down. If it is really up, but blocking our ping probes, try 
> -Pn
> Nmap done: 1 IP address (0 hosts up) scanned in 3.37 seconds
> benoit@pc-benoit:~$ nmap -Pn -p 3615 95.173.136.72
> Starting Nmap 7.93 ( https://nmap.org ) at 2024-08-15 21:10 CEST
> Nmap scan report for tototititutu (95.173.136.72 )
> Host is up.
> rDNS record for 95.173.136.72 : 95.173.136.72 .rev
> 
> PORT  STATESERVICE
> 3615/tcp filtered unknown
> 
> Nmap done: 1 IP address (1 host up) scanned in 2.68 seconds





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

Re: [FRnOG] [MISC] Cherche dock / hub Thunderbolt 2

[Frederic Dumas]

Bonjour Xavier,

> Le 20 août 2024 à 14:00, Xavier Lecluse  a écrit :
> 
> L'idée est d'avoir un (ou deux) port(s) écran et un ou deux ports USB 
> (histoire de pouvoir brancher écran/clavier/souris).

Au passage, sans répondre à ta question principale, les docks Thunderbolt pour 
Mac ne supportent qu'un seul écran externe, car Apple ne supporte pas les 
écrans Displayport chainés l'un à l'autre. Or, dans un dock avec plusieurs 
sorties vidéo Displayport, ces sorties sont en fait montées en daisychain. 
MacOS n'a pas les pilotes pour envoyer les images en Displayport Multistream 
Transport. Du coup, la même image du bureau est dupliquée sur tous les écrans 
externes. Cette limitation ne concerne pas les écrans Thunderbolts natifs; eux 
peuvent eux être chainés avec succès: macOS a les pilotes pour étendre des 
parties différentes du bureau sur plusieurs écrans externes Thunderbolt. 

Cette précision, pour que tu ne sois pas déçu par les possibilités d'extension 
de ton futur dock. Un écran, pas plus (sauf à acheter des moniteurs Thunderbolt 
Apple). L'incompatibilité de la daisychain Displayport et de macOS n'est pas un 
bug, c'est une feature.™ C'est une volonté marketing d'Apple de favoriser sa 
technologie Thunderbolt plutôt que la norme Displayport.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr




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

[FRnOG] [BIZ] Contact Iliad chez Play (Pologne)

[Frederic Dumas]

Bonjour à tous,

Quelqu'un d'Iliad voudrait-il m'aider à entrer en contact avec Play en Pologne, 
au marketing grand public ?

Merci.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr




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

Re: [FRnOG] [MISC] Ca se finit bien - Numericable a resilie ma ligne vielle de 40 ans, puis-je encore sauver mon numero ?

[Frederic Dumas]

Bonjour à tous,

> Moi je pense que sans appui interne, c’est mort.

Ton affirmation, David, fut une exacte prophétie. C’est grâce aux appuis 
internes chez SFR/Numéricable, obtenus cette semaine par plusieurs membres de 
FRnOG, qu’une solution heureuse est advenue.


Mardi vers 9:30, l’un d’entre vous parvenait à me communiquer le RIO de notre 
ligne résiliée. Il venait de multiplier par 10 les chances qu’une demande de 
portabilité permette de sauver au moins notre numéro. J’étais surpris que c’ait 
été possible, et je prenais le temps de vérifier la clé du RIO, grâce à l’outil 
indiqué par Richard [1]. Tout concordait. Merci à notre collègue pour sa 
démarche réussie.

Mais déjà vers 11h00, la cellule « Carré Bleu Service » (un service client 
dédié « VIP », de ce que mon interlocutrice me disait), me téléphonait grâce à 
l’intervention d’un second d’entre vous, et d’un clic a réactivé tous les 
services. Aucune nouvelle souscription, maintien des conditions commerciales, 
réapparition de notre numéro fixe, CPE inchangé, accès Internet retrouvé !

Une conclusion à laquelle je ne m’attendais pas. C’était un peu comme 
appartenir à la famille des miraculés.


Un mot sur la cause de la résiliation inopinée, éclaircie elle aussi.

À la suite des obsèques de notre mère fin juin, ma belle soeur a jugé utile de 
résilier ses abonnements téléphoniques et Internet. Mon frère fut son homme de 
paille. Sans considération particulière pour les conséquences, ni s’inquiéter 
si quelqu’un dans la famille souhaitait changer à son nom le titulaire des 
abonnements.

Pour parodier les Inconnus, « cela ne nous regarde pas » sur cette liste. 
Simplement, l’honnêteté m’oblige à reconnaitre que j’ai incriminé à tort 
SFR/Numericable. Hélas, personne au service clientèle n’a su me dire 
l’existence de ce courrier, avant la conversation que j’ai eu mardi avec mon 
interlocutrice du « Carré Bleu Service ».


Sincères et amicaux remerciements à la demi-douzaine de membres de FRnOG qui 
m’ont répondu en privé ces huit derniers jours, très souvent avec des 
propositions d’action concrètes, toujours avec une très bonne connaissance de 
ce dont ils parlaient. Sans eux, je n’aurai pas reçu d’aide de SFR/Numéricable. 
La liste FRnOG a démontré s’il le fallait son efficacité par l’action.


En souhaitant à tous bonne journée.

Frédéric.


[1] https://kpym.github.io/verificateur-rio/
--
Frédéric Dumas
f.du...@ellis.siteparc.fr



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

Re: [FRnOG] [MISC] Numericable a resilie ma ligne vielle de 40 ans, puis-je encore sauver mon numero ?

[Frederic Dumas]

Merci à ceux qui continuent à m’apporter leurs conseils,


> As-tu essayé d'appeler le 0800 97 3179 ?

Oui, c’est même le service clientèle SFR qui m’avait fait faire cette manip la 
semaine dernière. Aussitôt que j’ai fini de saisir le 10ème chiffre de mon 
numéro fixe, le serveur vocal raccroche, sans aucun message. Et je ne reçois 
aucun SMS qui aurait pu contenir le code RIO.

La même personne chez SFR m’avait aussi proposé de composer le 0805 85 89 85, 
m’expliquant qu’il s’agit de l’automate RIO propre à Numericable. Mais ce 
denier numéro semble ne plus être en service.


> "Dans le cas d’une portabilité d’un numéro fixe SFR, si vous ne pouvez pas 
> appeler le 3179 depuis la ligne fixe concernée, il est possible de récupérer 
> son code RIO SFR depuis une autre ligne. Pour ce faire, il suffit d’appeler 
> le 0800 97 3179 depuis une autre ligne (appel gratuit)."


--
Frédéric Dumas
f.du...@ellis.siteparc.fr




> 
> [Réponse hors liste.]
> 
>> 
>> Ça confirme ton idée, si Numéricable est incapable de réactiver notre 
>> abonnement, resterait possible de porter notre numéro ailleurs. Un autre 
>> membre de la liste me proposait en privé de m’y aider, et ça m’ouvre une 
>> possible voie de sortie. Mais, comme la ligne est résiliée du point de vue 
>> de Numéricable (plus de tonalité), je ne peux donc m’en servir pour obtenir 
>> son RIO par le 3179.


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

Re: [FRnOG] [MISC] Numericable a resilie ma ligne vielle de 40 ans, puis-je encore sauver mon numero ?

[Frederic Dumas]

Bonjour Laurent,
bonjour à tous,

> Simple curiosité : c'est un numéro exceptionnel, très facile à mémoriser ou 
> avec une signification particulièrement évidente ?


L’installation est à Paris, la ligne commence donc par 01. Les huit autres 
chiffres sont tous pairs; oui, notre numéro est relativement facile à dicter et 
mémoriser. Mais la première raison pour laquelle je cherche à faire annuler 
cette résiliation par Numéricable, c’est que ce numéro est connu de centaines 
de personnes, famille et amis, car c’est notre ligne fixe depuis 40 ans.

> Une idée sur une piste à explorer : le numéro a-t-il été réattribué ? Si ce 
> n'est pas le cas, cela permet peut-être d'espérer qu'il puisse être récupéré.

Geoffroy répondait qu’existe une période de grâce de 40 jours, à compter de 
l’effet de la résiliation. Ça confirme ton idée, si Numéricable est incapable 
de réactiver notre abonnement, resterait possible de porter notre numéro 
ailleurs. Un autre membre de la liste me proposait en privé de m’y aider, et ça 
m’ouvre une possible voie de sortie. Mais, comme la ligne est résiliée du point 
de vue de Numéricable (plus de tonalité), je ne peux donc m’en servir pour 
obtenir son RIO par le 3179.

> Oui ça c’est ce que dit le régulateur.
> Après y a la réalité, et en plus on parle de SFR/NC….


David tu as raison, le service client Numéricable me répond ne pas connaitre le 
RIO.

Deux autres personnes qui elles aussi m’ont contacté en privé et tentent de 
solliciter un appui interne chez SFR/Numericable, n’y parviennent pas. Les gens 
changent d’employeur ou sont en vacances.

Ce qui est contrariant [1], de mon point de vue de simple client dans cette 
affaire, c’est l’incapacité de SFR/Numéricable à escalader le problème, pour 
annuler cette résiliation erronée. Le CPE est sous-tension, le numéro n’est pas 
réattribué, il « suffirait » d’un peu de provisionning pour tout résoudre.

Au contraire, toutes les réponses des services clients SFR/Numéricable visent à 
contenir et ligoter ma réclamation dans un énorme édredon, et beaucoup 
d’énergie y est utilisée (des heures de palabres, des agents de centre d’appels 
qu’il faut bien payer à la fin), plutôt que de consacrer cette énergie à 
restituer l’abonnement et la ligne téléphonique qui ont été supprimés. C’est un 
peu comme si l’opérateur se protégeait lui-même d’avoir à réaliser les actions 
auxquelles son workflow est inadapté et trouvait préférable d’épuiser son 
client jusqu’à ce qu’il cesse de protester, grâce à l’action du temps qui 
passe. Curer la maladie par la mort du patient est sans doute une forme 
légitime de résolution de l'incident.

> Moi je pense que sans appui interne, c’est mort.


Là aussi tu as raison David, jusqu’à présent, même en passant par les personnes 
présentes sur FRnOG, impossible de faire réactiver mon abonnement par 
SFR/Numericable.

Merci à tous de vos conseils et de votre aide.


[1] euphémisme
--
Frédéric Dumas
f.du...@ellis.siteparc.fr




> Le 14 juil. 2022 à 09:08, Laurent Barme <5...@barme.fr> a écrit :
> 
> 
> Le 13/07/2022 à 23:29, Frederic Dumas a écrit :
> …
> 
> Il y aurait comme une contradiction sémantique entre “…aucune trace de … 
> résiliation," et "… vous avez résilié” ; c'est très impressionnant !
> 
> …
> 
> C'est incroyable cette histoire ! D'habitude, c'est la résiliation qui est 
> impossible avec SFR :-)
>> 
>> Je suis rentré à Paris cet après-midi. Quelqu’un connaitrait-il un 
>> interlocuteur capable ce jeudi 14 juillet férié de cliquer sur les bons 
>> boutons du SI chez SFR, pour faire revenir mon abonnement et mon numéro de 
>> téléphone à la vie ?
>> 
> La suite donnée à cette demande aura un impact conséquent sur la réputation 
> de SFR (et un indice de l’influence potentielle de cette liste)…
> 
> 
> Une idée sur une piste à explorer : le numéro a-t-il été réattribué ? Si ce 
> n'est pas le cas, cela permet peut-être d'espérer qu'il puisse être récupéré. 
> Sinon, l'appeler permettrait d'en savoir plus sur la personne qui l'a 
> récupéré et peut-être de comprendre comment ou pourquoi il a changé de 
> destinataire, voire de le récupérer aussi.
> 
> 
> Simple curiosité : c'est un numéro exceptionnel, très facile à mémoriser ou 
> avec une signification particulièrement évidente ?


> Le 13 juil. 2022 à 23:29, Frederic Dumas  a écrit :
> 
> 
>> Hello!
>> 
>> jeudi 7 juillet, j’étais à l’étranger, un mail de Numericable m’annonce ceci 
>> à 19:04, heure de Paris: 
>> 
>> 
>> Nous avons bien reçu la demande de résiliation de votre offre Numericable.
>> Nous vous confirmons que cette demande a bien été enregistrée par nos 
>> services.
>> La résiliation de votre offre sera effective le : 07-07-

[FRnOG] [MISC] Numericable a resilie ma ligne vielle de 40 ans, puis-je encore sauver mon numero ?

[Frederic Dumas]

Hello!

jeudi 7 juillet, j’étais à l’étranger, un mail de Numericable m’annonce ceci à 
19:04, heure de Paris: 


Nous avons bien reçu la demande de résiliation de votre offre Numericable.
Nous vous confirmons que cette demande a bien été enregistrée par nos services.
La résiliation de votre offre sera effective le : 07-07-2022.
A partir de cette date, vous ne pourrez plus accéder aux services Numericable.


Notre numéro de téléphone familial, ancien de 40 ans, venait de mourir sans 
avertissement préalable.

J’ai passé des heures à distance ces quatre derniers jours ouvrés avec le 
service clientèle Numéricable/SFR, pour demander le rétablissement de mon 
contrat, ou tout au moins la récupération du numéro. Le discours dominant de 
mes interlocutrices en call center marocain peut se résumer ainsi: “Nous ne 
trouvons aucune trace de votre demande de résiliation, j’ai vérifié deux fois, 
et donc c’est pour ça que nous ne pouvons réactiver la ligne que vous avez 
résilié”. Verbatim.

J’ai dû me plier à des manipulations hasardeuses, on m'a fait par exemple 
essayer successivement les plateformes RIO de divers opérateurs, espérant que 
l’une d’elle allait me fournir le RIO de ma ligne défunte. J’ai essayé 
d’identifier et d’échapper aux peaux de banane habituelles, du type “je vais 
demander au service expertise de vous rappeler sous 48h”, ce qui n’arrive 
jamais bien sûr. En bref, quatre jours plus tard, le chou blanc sur toute la 
ligne.

Je suis rentré à Paris cet après-midi. Quelqu’un connaitrait-il un 
interlocuteur capable ce jeudi 14 juillet férié de cliquer sur les bons boutons 
du SI chez SFR, pour faire revenir mon abonnement et mon numéro de téléphone à 
la vie ?

En vous remerciant.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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

[FRnOG] [MISC] Suppression de compte XING au titre de la RGPD ?

[Frederic Dumas]

Bonjour,

quelqu'un saurait-il comment demander à XING la suppression de toutes 
mes données personnelles (et donc y compris mon compte), au titre de la 
RGPD ?


Le réseau social offre évidement la possibilité de demander la 
"suppression" d'un compte, par son utilisateur. Mais le bouton est si 
facilement accessible, et les gens du marketing "digital" si matois, que 
je me demande si ce bouton ne sert pas simplement à supprimer l'accès au 
compte (il disparait du front-end web), tandis que les données elles 
sont silencieusement conservées par XING.


Interrogé par écrit à propos des modalités de suppression au titre de la 
RGDP, le support Xing n'a pu répondre autrement que par un mail 
pré-formaté, rappelant l'existence du bouton en question, point barre.


Merci pour vos conseils.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


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

Re: [FRnOG] [TECH] TNTSat - geolocalisation IP et sondes Atlas (titre un peu putaclic, c'est 'dredi)

[Frederic Dumas]

Le 04/12/2020 à 16:02, Hugues Voiturier a écrit :
Par Scaleway, pas Free, deux réseaux différents. Et si, il a été 
flag comme un range Néerlandais, puisque c’est le cas.



stat.ripe.net le signale lui comme français.

https://stat.ripe.net/widget/rir-geo#w.resource=51.158.0.0%2F15

Comment voit-on que 51.158.0.0/15 annoncé par AS12876 est un range 
hollandais ?




Ce préfixe est celui de Scaleway à Amsterdam



Tu veux dire que la filiale de Free est de droit néerlandais? C'est une 
histoire de double sandwich irlandais au gouda?



--
Frederic Dumas
f.du...@ellis.siteparc.fr


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

[FRnOG] [TECH] TNTSat - geolocalisation IP et sondes Atlas (titre un peu putaclic, c'est 'dredi)

[Frederic Dumas]

Un sujet plus léger pour vendredi.


Le site TNTsat interdit de commander une nouvelle carte depuis une IP 
étrangère (le genre de truc que la commission européenne dénonce, mais bon).


Pour déjouer cette limite j'imaginais qu'une DediBox dans le range 
51.158.128.0/17 utilisée en proxy ferait l'affaire.


Pour le moment, tous mes efforts sont infructueux: invariablement, 
"CANAL+ n'est pas disponible dans votre pays".



 - tunnel SOCKSv5 depuis ma machine locale jusqu'à la Dedibox
   + WebRTC IP leak désactivé dans Firefox

   "CANAL+ n'est pas disponible dans votre pays"


 - l'IPv6 de la DediBox est localisée en Hollande (?!?)
   Stack IPv6 désactivée.

   "CANAL+ n'est pas disponible dans votre pays"


 - consultation du site TNTSat en ligne de commandes, avec links,
   depuis la DediBox

   "CANAL+ n'est pas disponible dans votre pays"


J'en viens à me demander si le range 51.158.0.0/15, annoncé par Free, 
n'aurait pas été flagé dans le temps comme un range non français ?


https://stat.ripe.net/51.158.0.0%2F15#tabId=routing

Malheureusement, son historique par les sondes Atlas ne remonte pas 
au-delà de 2018.



J'imagine que si le webmestre du site canal lit la liste, il accrochera 
mon mail à son tableau de chasse. :-)



--
Frederic Dumas
f.du...@ellis.siteparc.fr


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

Re: [FRnOG] [TECH] Codecs VoIP sur OVH

[Frederic Dumas]

Hello,


Le 04/12/2020 à 11:58, David Ponzone a écrit :

Personne a envie de se taper du transcoding à la place des autres

Donc c’est la patate chaude: non non j’en veux pas de ton G729,
envoie-moi du bon 711 qui prend 0% de CPU à relayer.


Intéressant d'apprendre que l'opérateur est incité à favoriser G711 pour 
tous les appels terminés par un opérateur tiers, pour s'éviter de les 
transcoder.



Le 04/12/2020 à 11:49, Oliver varenne a écrit :

Je ne vois pas le probleme...


Le problème venait de la réponse formulée par le support technique: elle 
donnait à croire que la négociation du codec se faisait de bout en bout, 
pour chaque communication, où que soit terminé l'appel.



Le 04/12/2020 à 14:13, Sébastien Lesimple a écrit :
J'ai lu quelque part dans leurs docs que le G722 n'était supporté 
qu'entre deux lignes OVH pas vers l'extérieur qui doit est soit en

SS7, soit en G711.


C'est peut-être ce qu'a voulu dire le support OVH: si l'appel est 
terminé par un opérateur tiers, OVH négocie G711, si l'appel est terminé 
chez OVH, G722 est négocié. Dis comme ça c'est plus clair.



Merci à tous pour vos réponses.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


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

Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

[Frederic Dumas]

Merci Fabien, Philippe, Raphaël pour vos réponses.

Par le calcul, je n'arrive pas à retrouver vos conclusions.

Au moment des tests, j'avais un rtt de 174ms en moyenne et un jitter de 
10ms. J'étais cappé à 132Mbps (pas MBps, coquille). Et aucun paquet n'a 
été réémis; pas de pertes. Si le facteur qui a limité le débit, c'est 
comme vous le suggérez la fenêtre TCP et non pas un shapping du trafic 
par l'opérateur, la fenêtre aurait été à ce moment là de ~2,8Mio. Je 
lisais que sa taille peut théoriquement aller jusqu'au Gio pour laisser 
le débit augmenter malgré la latence.


Est-ce que l'explication par le fenêtre trop petite est vraiment la 
bonne pour un trafic tcp wan transatlantique cappé à ~130Mbps ?



Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr





Bonjour,

iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre 
iperf.he.net et ma machine. C'est
suffisamment haut pour ne pas poser de problème. Par curiosité, 
est-il possible d'identifier aux

alentours de quel hop le shaping serait appliqué ?


J'ai l'impression que ton problème de TCP shapé n'en est pas un, que 
c'est juste l'effet de la latence que tu mesures...
En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la 
limite un WAN national.
Pour la longue distance, si tu veux mesurer une bande passante max, 
c'est forcément avec de l'UDP.




Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt 
long, multiplie le nombre de flows:


-P, --parallel  # number of parallel client streams to run









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

[FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

[Frederic Dumas]

Bonjour,

iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre 
iperf.he.net et ma machine. C'est suffisamment haut pour ne pas poser de 
problème. Par curiosité, est-il possible d'identifier aux alentours de 
quel hop le shaping serait appliqué ?


D'après le looking glass de HE, les paquets allant de la Californie vers 
l'Europe ne traversent que deux AS: HE et celui de mon FAI (UPC). Ça ne 
nous laisse pas beaucoup de coupables.


Sans sondes le long du chemin, je ne vois pas comment en savoir plus. 
Existe-t-il un outil publiquement accessible du style des sondes Atlas, 
non pas pour regarder les annonces BGP, mais pour tester les débits 
depuis différents points de l'internet? Je préfère poser la question que 
de conclure trop vite.



C'est une question de curiosité, pas un problème réel dans le cas présent.

Bonne journée.



$ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending

[SNIP]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   472 MBytes   132 Mbits/sec0 sender
[  4]   0.00-30.00  sec   473 MBytes   132 Mbits/sec receiver



$ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R -P2
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending

[SNIP]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   456 MBytes   128 Mbits/sec0 sender
[  4]   0.00-30.00  sec   457 MBytes   128 Mbits/sec receiver
[  6]   0.00-30.00  sec   456 MBytes   128 Mbits/sec0 sender
[  6]   0.00-30.00  sec   457 MBytes   128 Mbits/sec receiver
[SUM]   0.00-30.00  sec   912 MBytes   255 Mbits/sec0 sender
[SUM]   0.00-30.00  sec   914 MBytes   256 Mbits/sec receiver



--
Frederic Dumas
f.du...@ellis.siteparc.fr




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

Re: [FRnOG] [TECH] Visio & partage d'écran

[Frederic Dumas]

Bonjour Alexandre, Wallace,


Un lien vers un produit d'une boîte francaise que j'ai rencontré à 
Lannion : https://www.izeeconf.com/


Je viens de tester, l'ergonomie est très agréable. Ça m'a l'air de 
couvrir toutes les fonctions de whereby.com. Dans ce cas, autant aller 
sur une plateforme française.




Je te conseille vivement JitSi https://meet.jit.si/  open source que
tu peux directement utilisé sur l'url donnée sans authentification ou
on premise.


Le déploiement d'un serveur en propre est recommandé à partir de combien 
d'utilisateurs simultanés ? Quatre comme pour les autres ?



--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 11/12/2019 à 01:27, Alexandre Moutot a écrit :

Salut Fabien,

Un lien vers un produit d'une boîte francaise que j'ai rencontré à Lannion
: https://www.izeeconf.com/

Alexandre

On Tue, Dec 10, 2019 at 9:45 PM Frederic Dumas 
wrote:



Salut Fabien,

Probablement une réponse plus [BIZ] que [TECH]: whereby.com est une
solution tout terrain, sur tout navigateur, sans pluggin, audio, video,
chat et partage d'écran (ou même partage limité à une fenêtre
d'application seulement). Inconvénient du WebRTC de pair à pair: la
conf. call est limitée à quatre participants. Une version payante
passant par un serveur central autorise jusqu'à 12 participants.

Je n'ai aucune affiliation avec eux, je ne fais que citer ce site pour
l'utiliser depuis longtemps.

Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 10/12/2019 à 12:17, Fabien SEGURA a écrit :

J’aurai besoin d’une solution avec un client qui tourne sur tout type de
bécanne sans avoir besoin d’installer de pluggin, l’idée étant que les
invités puissent accéder aux conférences facilement et rapidement depuis
n’importe où (tout le monde n’a pas les droits d’admin sur son PC).







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

Re: [FRnOG] [TECH] Visio & partage d'écran

[Frederic Dumas]

Salut Fabien,

Probablement une réponse plus [BIZ] que [TECH]: whereby.com est une 
solution tout terrain, sur tout navigateur, sans pluggin, audio, video, 
chat et partage d'écran (ou même partage limité à une fenêtre 
d'application seulement). Inconvénient du WebRTC de pair à pair: la 
conf. call est limitée à quatre participants. Une version payante 
passant par un serveur central autorise jusqu'à 12 participants.


Je n'ai aucune affiliation avec eux, je ne fais que citer ce site pour 
l'utiliser depuis longtemps.


Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 10/12/2019 à 12:17, Fabien SEGURA a écrit :

J’aurai besoin d’une solution avec un client qui tourne sur tout type de
bécanne sans avoir besoin d’installer de pluggin, l’idée étant que les
invités puissent accéder aux conférences facilement et rapidement depuis
n’importe où (tout le monde n’a pas les droits d’admin sur son PC).






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

[FRnOG] [TECH] Checkpoint R77.20 - drop de paquets etrangers au LAN en mode bridge

[Frederic Dumas]

Bonjour à tous,

C'est un peu la suite des aventures de cette route statique annoncée en 
option 121 par le DHCP d'un CheckPoint (cf. début novembre ici sur la 
liste). Elle permet aux machines locales d'accéder à celles d'un 
sous-réseau distant à travers une passerelle située sur le LAN, qui 
n'est pas la passerelle par défaut. Au final, tout a bien voulu fonctionner.



On a un peu changé la topologie du LAN:


 - la passerelle en question était jusqu'à présent placée dans le même
   VLAN que les autres postes du LAN, en amont du CheckPoint;

 - elle a été changée de VLAN, pour être isolée sur un port Ethernet
   du CheckPoint, qui lui soit réservé;

 - sur le CheckPoint, un bridge remet ensemble ce port Ethernet dédié à
   la passerelle et le port Ethernet dédié au reste des machines du LAN;

 - cette topologie a pour but de permettre le filtrage sur MAC address
   par le CheckPoint (dispo en mode bridgé seulement).


On observe alors un comportement difficile à expliquer par la théorie:


 - la passerelle est parfaitement accessible à son adresse IP locale;
   depuis le LAN (de l'autre coté du bridge donc), on la pingue, elle
   répond, on se logue sans problème, normal, on est sur un bridge;

 - par contre, toujours depuis le LAN, on a perdu la connectivité avec
   les machines distantes, situées sur le sous-réseau accessible par la
   passerelle ?!?


Après quelques vérifications, il apparait que:


 - les requêtes vers les machines distantes sont bien acheminées par la
   passerelle; elles traversent donc le bridge;

 - les réponses parviennent à la passerelle, qui les émet sur son
   interface, de son coté du bridge;

 - malheureusement, tcpdump est formel: de l'autre coté du bridge, sur
   le reste du LAN, le CheckPoint ne transmet aucun des paquets sortant
   de la passerelle, dès lors que ceux-ci ont des machines
   distantes pour adresse d'origine;

 - pour fermer la porte à une fausse piste, le phénomène se produit
   aussi bien lorsque le filtrage sur MAC address est activé ou
   désactivé sur le CheckPoint;

 - cependant, comme dit plus haut, le CheckPoint transmet bien sur le
   bridge tous les paquets émis par la passerelle, dès lors que ceux-
   ci ont pour adresse d'origine celle de la passerelle elle-même.

Si on essaye de "tirer dans le noir" comme disent les anglo-saxons, ça 
fait penser à une règle d'anti-spoofing qui droperait les paquets de 
retour, car ils ont une adresse d'origine extérieure au LAN. Mais rien 
ne le confirme dans les logs du CheckPoint. Les paquets ont disparus, et 
c'est tout.


Bug ou feature ? Y-a-t-il un moyen de configurer le CheckPoint pour 
contourner ce problème ? Une route à déclarer pour contourner le filtre 
anti-spoofing, pour autant que ce soit lui la cause ?



Merci pour vos conseils ou hypothèses.



--
Frederic Dumas
f.du...@ellis.siteparc.fr






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

Re: [FRnOG] [TECH] [Resolu] Checkpoint R77.20 - route statique par DHCP - RFC3442

[Frederic Dumas]

Merci pour tes explications détaillées Patrick.

Dans l'exemple cité, on comprend que le "12" situé au milieu de la 
valeur de l'option 121 ne désigne pas le nombre d'octets encodant la 
seconde route, comme Michel a pu en faire l'hypothèse, mais désigne le 
masque de la seconde route.


Pour finir, est-ce qu'on comprend aussi que chaque annonce option 121 
permet d'annoncer plusieurs routes accessibles par une même passerelle, 
mais pas plusieurs passerelles ? Pour cela, suffit-il de faire répéter 
au serveur DHCP l'option 121 avec des valeurs différentes dans chaque 
annonce ?


Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 07/11/2019 à 15:51, Michel Py a écrit :


Quand je lis RFC3442, je ne vois pas ou mettre le "12". Dans
Destination 2, il n'y a pas de "Len", pas de "n", ce qui laisserait
supposer que n est la même valeur pour toutes les destinations. Tu
mettrais quoi comme valeur, en se basant sur RFC3442 ?


Le 07/11/2019 à 16:17, Patrick Maigron a écrit :


- 12 172 16 192 168 248 251
La longueur du préfixe est 12, il y a donc 2 octets significatifs pour
le préfixe, donc 172 16 -> 172.16.0.0/12
Destination2 : 12 172 16








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

Re: [FRnOG] [TECH] [Resolu] Checkpoint R77.20 - route statique par DHCP - RFC3442

[Frederic Dumas]

Bonjour Michel,
Bonjour à tous,


Le 06/11/2019 à 20:48, Michel Py a écrit :
Malheureusement je ne connais rien au Checkpoint, mais j'utilise 
cette option (121) et çà marche impec avec des clients Windows.



On tient la solution. Le CheckPoint transmet bien l'option 121 dans sa 
réponse DHCPACK. Par conséquent, la route statique est désormais bien 
acquise par nos stations de travail. Le problème des paquets martiens 
est résolu.



La difficulté était de découvrir la syntaxe à utiliser sur le 
CheckPoint, pour y enregistrer cette route statique au format RFC3442.



Exemple:
route statique 192.168.37.0/24
passerelle 192.168.248.251


D'après la RFC3442, la valeur de l'option 121 doit être codée ainsi:

   24 192 168 37 192 168 248 251


L'interface utilisateur web du CheckPoint semble offrir le choix entre 
deux options, dans la fenêtre "DHCP Custom option":



 - Hex String:

La valeur de l'option 121 doit alors être saisie en hexadecimal ; le 
CheckPoint ne réalise aucune conversion et transmet les 8 octets en 
l'état (moins leurs séparateurs) dans le corps du paquet DHCPACK:


   saisi à la main:
   18:C0:A8:25:C0:A8:F8:FB

   envoyé par le CheckPoint:
   18c0a825c0a8f8fb

Dans la saisie manuelle, le séparateur entre les octets est le 
deux-points, et il n'y a pas de séparateur entre l'adresse de réseau et 
celle de la passerelle.



 - IP Address Array

La valeur de l'option 121 doit alors être saisie en base 10 classique, 
et sera convertie par le CheckPoint en octets dans le corps du paquet 
DHCPACK:


   saisi à la main:
   24.192.168.37,192.168.248.251

   envoyé par le CheckPoint:
   18c0a825c0a8f8fb

Dans la saisie manuelle, le séparateur entre les chiffres est le point 
et le séparateur entre l'adresse de réseau et celle de la passerelle est 
la virgule.



Dans tous les cas, le CheckPoint calcule lui-même la longueur de 
l'option 121 (ici, huit octets, mais ça pourrait différer en fonction du 
masque de réseau et du nombre de passerelles annoncées). Il ne faut pas 
la saisir manuellement.



Comme pour l'oeuf de Christophe Colomb, rien de compliqué une fois qu'on 
sait comment enregistrer ces valeurs dans l'interface du firewall. Le 
problème, c'est le silence complet de la doc CheckPoint à ce sujet. Le 
man de dhcpd-options fut mon ami:


https://linux.die.net/man/5/dhcpd-options



Ci-dessous, le DHCPdump qui confirme la présence de l'option 121 dans 
les paquets DHCPACK émis par le CheckPoint:




OPTION:  57 (  2) Maximum DHCP message size 1500
OPTION:  61 (  7) Client-identifier 01:c8:2a:14:xx:xx:xx
OPTION:  50 (  4) Request IP address192.168.248.64
OPTION:  51 (  4) IP address leasetime  7776000 (12w6d)
OPTION:  12 ( 15) Host name WorkStation
---

  TIME: 2019-11-07 10:12:00.946
IP: 192.168.248.254 (0:1c:7f:xx:xx:xx) > 192.168.248.64 
(c8:2a:14:xx:xx:xx)

OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 5c407f63
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.248.64
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: c8:2a:14:xxx:xx:xx:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
OPTION:  54 (  4) Server identifier 192.168.248.254
OPTION:  51 (  4) IP address leasetime  921600 (1w3d16h)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION: 121 (  8) Classless Static Route18c0a825c0a8f8fb ...%
OPTION:   3 (  4) Routers   192.168.248.254
OPTION:   6 (  4) DNS server192.168.248.254
---



En espérant que ça puisse aider quelqu'un d'autre.


--
Frederic Dumas
f.du...@ellis.siteparc.fr


Frederic Dumas a écrit :

Quelqu'un pourrait-il m'aider à encoder l'annonce d'une route statique
au format RFC3442 dans le "DHCP Custom option" du Checkpoint ?




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

Re: [FRnOG] [TECH] Checkpoint R77.20 - route statique par DHCP - RFC3442

[Frederic Dumas]

Réponse courte:

Quelqu'un pourrait-il m'aider à encoder l'annonce d'une route statique 
au format RFC3442 dans le "DHCP Custom option" du Checkpoint ?



Réponse normale:

Bonjour David,
Bonjour Radu,


Le 06/11/2019 à 12:04, David Ponzone a écrit :
Sinon, si les PC du LAN voit la passerelle en question, le 
Checkpoint la voit aussi, donc pourquoi tu mets juste pas une route

statique dans le Checkpoint vers ce sous-réseau avec la passerelle en
question comme next-hop ?


Oui, c'est ce que nous avions commencé à faire. Grâce aux annonces ICMP 
Redirect émises par le Checkpoint, nos stations de travail dirigent 
effectivement vers la passerelle en question le trafic destiné à ce 
sous-réseau particulier. De l'autre coté de la passerelle, les serveurs 
nous répondent. Tout devrait donc bien aller.


Mais alors...


Le 06/11/2019 à 12:18, Radu-Adrian Feurdean a écrit :


Parce-que routage asymetrique qui interfere avec le statefull firewall.



Le 06/11/2019 à 12:37, David Ponzone a écrit :

Il y a peut-être un moyen de couper le firewall pour le trafic
LAN<—>LAN.


Bien tenté, la vérité est pourtant encore ailleurs, mes chers Sculley et 
Mulder :-)


Nos stations de travail reçoivent les réponses des serveurs situés 
au-delà de la passerelle en question, car elles empruntent le même 
chemin au retour qu'à l'aller. Tout va bien. Mais comme ces paquets 
proviennent d'une passerelle vers laquelle les stations de travail n'ont 
pas de route par défaut, nos stations de travail considèrent alors ces 
paquets entrant comme des paquets martiens et... les droppent.


Le phénomène est identique sur Linux, OS.X et Windows. Ce qu'il faut à 
nos stations de travail, c'est une route statique définie sur chacune 
d'elles, vers la passerelle en question.


D'où l'idée de charger le serveur DHCP du Checkpoint de la tache 
d'annoncer cette route statique.



Je reviens donc à ma question d'origine: quelqu'un pourrait-il m'aider à 
encoder l'annonce d'une route statique au format RFC3442 dans le "DHCP 
Custom option" du Checkpoint ?



En remerciant d'avance les plus chenus d'entre nous.


--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 06/11/2019 à 11:46, Frederic Dumas a écrit :


Bonjour à tous,

Peut-on configurer un Checkpoint 600 (firmware R77.20.80) pour que son 
serveur DHCP annonce à nos stations de travail une route statique vers 
un sous-réseau inaccessible par le Checkpoint, mais accessible par une 
autre passerelle, située sur le même sous-réseau que les stations de 
travail ?


Je n'ai pas vu comment ajouter de routes statiques dans la configuration 
DHCP du Checkpoint; le "DHCP custom option" le permet-il ? Le guide de 
l'admin R77 n'apporte pas de réponse. Est-ce le moyen d'enregistrer une 
route statique au format RFC3442 [1] ? Si oui, quelqu'un peut-il m'aider 
pour la syntaxe exacte à utiliser ?



Merci pour votre aide.

Frédéric.


[1] https://tools.ietf.org/html/rfc3442
--
Frederic Dumas
f.du...@ellis.siteparc.fr








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

[FRnOG] [TECH] Checkpoint R77.20 - route statique par DHCP - RFC3442

[Frederic Dumas]

Bonjour à tous,

Peut-on configurer un Checkpoint 600 (firmware R77.20.80) pour que son 
serveur DHCP annonce à nos stations de travail une route statique vers 
un sous-réseau inaccessible par le Checkpoint, mais accessible par une 
autre passerelle, située sur le même sous-réseau que les stations de 
travail ?


Je n'ai pas vu comment ajouter de routes statiques dans la configuration 
DHCP du Checkpoint; le "DHCP custom option" le permet-il ? Le guide de 
l'admin R77 n'apporte pas de réponse. Est-ce le moyen d'enregistrer une 
route statique au format RFC3442 [1] ? Si oui, quelqu'un peut-il m'aider 
pour la syntaxe exacte à utiliser ?



Merci pour votre aide.

Frédéric.


[1] https://tools.ietf.org/html/rfc3442
--
Frederic Dumas
f.du...@ellis.siteparc.fr



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

Re: [FRnOG] [MISC] Activation internet la plus longue de l'histoire - annul. prelev.

[Frederic Dumas]

Bonjour Eugène,
Bonjour à tous,


Sauf qu'à ma grande surprise je constate un prélèvement de *311,25€* sur
mon compte ce weekend, de la part de Coriolis, je ne comprends rien et ce
matin je viens d'avoir une de leurs agents au téléphone,


[SNIP]


Ayant mon RIB ils se sont servis, tout simplement.


Tu le sais probablement, si tu considères ce prélèvement infondé, tu 
disposes de trois mois pour donner ordre à ta banque de recréditer ton 
compte de la somme prélevée, sans avoir à motiver ta demande. Chez moi, 
la procédure se réduit à un simple bouton "Remboursement" à cliquer dans 
l'interface web. D'expérience, la banque s'exécute sans discussion.


A partir de là, et en attendant le déroulement de ton affaire, le 
système de facturation de Coriolis ne pourra pas faire grand chose 
d'autre que de t'envoyer du papier, que tu pourra probablement ignorer 
en toute sécurité.


Il est préférable de récupérer ton argent et de discuter ensuite, les 
gros ayant tendance à jouer le pourrissement vis-à-vis du petit dès lors 
qu'ils ont encaissé.


Désolé d'ajouter cette info à une discussion déjà ancienne, je rattrape 
du retard en lecture.


Bye.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


Le 02/04/2019 à 11:30, Eugène Ngontang a écrit :

Bonjour,

Toujours dans mes déboires avec Coriolis, j'ai porté plainte depuis un
moment comme je disais, ils ont continué à faire le malin, et donc y a une
assignation qui est partie, et j'attends la convocation du tribunal de
grande instance de Paris.

Ils ont fini par lever la main sur mon dossier là en fin du mois de
février, et ma ligne est active chez K-net depuis la semaine dernière.

Sauf qu'à ma grande surprise je constate un prélèvement de *311,25€* sur
mon compte ce weekend, de la part de Coriolis, je ne comprends rien et ce
matin je viens d'avoir une de leurs agents au téléphone, elle me dit après
avoir vérifié avec l'équipe de déploiement, que (d'après Coriolis) j'ai
résilié ma commande après le déploiement de le fibre par COVAGE, et donc je
dois payer les frais de résiliation. Ayant mon RIB ils se sont servis, tout
simplement.

Je demande le 3 janvier, après plus de trois mois de galère où je me fais
trimballer dans tous les sens, d'arrêter tout et d'annuler la commande,
Coriolis me confirme l'annulation le 7 janvier en m'envoyant l'adresse de
retour du matériel (dont je n'avais jamais ouvert les cartons), je renvoie
le matériel en bonne et due forme avec les frais que ça comporte et accusé
de réception par chronopost, je confirme auprès de K-net que c'est bon,
COVAGE fait le déploiement de ma ligne le 29 janvier avant de constater
lors de l'activation que la commande à leur niveau est encore au nom de
Coriolis... blablabla, et Coriolis me dit que ce jour je devais interdire à
COVAGE de faire le déploiement, car je n'avais pas résilié la commande. Non
ils veulent ma tête les mecs !

Je ne sais pas si c'est moi qui débarque mais je me demande bien si cette
boîte pratique la sorcellerie, je n'ai jamais vu une telle gestion de la
relation "client" (encore qu'au final je n'ai jamais été client) de toute
mon experience.;

Voilà je vous donnais juste des nouvelles, je laisserai la justice faire et
j'ai du temps pour cela (j'en trouverai), je pense que Coriolis n'a pas
encore croisé le chemin d'un particulier qui ne laisse pas marcher dessus.

Bonne journées les guru, et bonne semaine.

Cordialement,
Eugène NG



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

Re: [FRnOG] [MISC] la porte derobee des serveurs Supermicro

[Frederic Dumas]

Continuant la discussion d'octobre sur le "hack chinois" rapporté par 
Bloomberg dont les cartes mères Supermicro auraient été victimes, voici 
une très récente contribution sur la faisabilité technique de la 
contamination du BMC par implant d'un composant actif à la place d'une 
résistance, sur une des lignes entre la mémoire flash et le BMC d'un 
serveur Supermicro.


L'auteur a présenté à Leipzig fin 2018 une preuve de concept sur FPGA, 
lui permettant d'altérer à la volé le code lu par le BMC au démarrage du 
serveur, pour parvenir à afficher quelques caractères sur le port console.




And that is what this proof of concept hardware implant on the BMC SPI
bus does: it replaces one of the empty regions with a new inode that
overwrites the /nv/network/netconfig2 file with its own shell script,
since the /etc/rc.d/55ipmi.sh script will execute it as a subshell.
This PoC doesn't do much, other than print a message to the serial
console to indicate that it has achieved code execution during the boot
process. 


Source: https://trmm.net/Modchips


Le reste de son article présente différentes hypothèses pour tenter de 
distinguer si cette annonce était un fausse ou non. Sa conclusion est 
prudente. Mais la quantité d'hypothèses passées en revue mérite d'être lue.



Du point de vue hardware, la partie la plus intéressante de son article 
est celle où il décrit comment l'implant devrait collecter l'énergie 
nécessaire à son fonctionnement par couplage capacitif, reconstituer le 
signal d'horloge, écouter en permanence pour détecter la transmission, 
etc. Ceci afin de ne pas devoir être connecté à d'autres lignes du PCB 
que celle unique sur laquelle se trouve être normalement implantée la 
résistance.



Normally the SPI bus requires six connections to function, but the
implant has only part of a single one. It doesn't connect to power or 
ground, so it must be parasitically powered by the current flowing 
from the SPI flash to the BMC during normal operation (similar to the 
RFID CPUs that have enough capacitance to run even when they are 
shorting the antenna coil). It doesn't have access to the chip select 
line, so it has to guess when the chip is being read. It doesn't have 
access to the clock line, so it has to guess the clock frequency. It
doesn't have access to the Serial Data In (SI or MOSI), so it has to 
monitor the SO data to try to recognize where in the flash the BMC is 
reading. And, due to the way it is constructed and powered, it can't 
generate arbitrary bit patterns, it can only disconnect the line and
turn 1 bits into 0 bits. A simple matter of engineering to work around 
these, right? 


Souce: idem


--
Frédéric Dumas
f.du...@ellis.siteparc.fr



Le 05/10/2018 à 08:23, Alexandre DERUMIER a écrit :

un article un peu plus technique:

https://www.theregister.co.uk/2018/10/04/supermicro_bloomberg/

"The spy chip could have been placed electrically between the baseboard management 
controller (BMC) and its SPI flash or serial EEPROM storage containing the BMC's 
firmware. Thus, when the BMC fetched and executed its code from this memory, the spy chip 
would intercept the signals and modify the bitstream to inject malicious code into the 
BMC processor, allowing its masters to control the BMC."

Ca serait donc au niveau de la bmc.

Après est-ce que c'est exploitable si la bmc n'est pas accessible sur le net ?
vu la taille du chip, ca semble difficile d'implémenter un exploit ou autre 
autonome.



- Mail original -
De: "Michel Py" 
À: "frnog-misc" 
Envoyé: Vendredi 5 Octobre 2018 00:39:10
Objet: [FRnOG] [MISC] la porte dérobée des serveurs Supermicro

Un troll de luxe pour ce vendredi !

https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

En bref : les carte mères de serveurs Supermicro contiennent un composant conçu 
par les services de renseignements Chinois qui permettrait de prendre le 
contrôle du serveur. Comme un root kit, mais dans le matériel.

Michel.


---
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] [MISC] Nouvelle loi en Australie: les entreprises doivent permettre aux autorités de casser n'importe quel chiffrement

[Frederic Dumas]

Bonjour Barth,
bonjour à tous,


> Je viens de voir passer sur Reddit un thread qui a l'air assez
> impactant niveau sécurité:
> 
https://www.reddit.com/r/programming/comments/a3kk7u/australian_programmers_could_be_fired_by_their/



L'Australie faisant partie des Five Eyes, ce que l'ASD australien voit, 
la NSA américaine le voit vraisemblablement aussi.


On peut penser que l'Australie a été choisie comme tête de pont pour 
légaliser l'accès aux "transmissions" des agences de surveillance, mais 
qu'en réalité, ce sont les Etats-Unis qui sont à la manœuvre et 
souhaitent ces changements législatifs, chez eux et chez leurs satellites.



Entre :

> une loi contraignant les entreprises (snip) à implémenter dans leurs
> produits une possibilité pour les autorités australiennes de
> déchiffrer n'importe quelle communication.

et :

> La loi "n'impose pas" de backdoor,

Il semble y a voir une contradiction. Mettre par exemple une clé tierce 
sous séquestre me semble être une forme de backdoor.



Je me rappelle de l'avocat de Wikileaks qui expliquait :

«… toute entreprise française, participant à un appel d’offre supérieur 
à 250 millions d'euros, n’importe où dans le monde, est systématiquement 
espionnée par la NSA, afin de saboter leur offre. Combien de milliers 
d’emplois ont été détruits à cause de ces dispositifs ? »


Source : https://www.youtube.com/watch?v=uBaAvHxdShw&t=3653


Ce qui est vrai pour une entreprise française l'est pour celle d'un 
autre pays. Là est sans doute une des explications de la direction dans 
laquelle poussent les Etats-Unis.



--
Frédéric Dumas
f.du...@ellis.siteparc.fr



Le 06/12/2018 à 18:52, Barthélémy DELUY a écrit :

Bonjour à tous,

Je viens de voir passer sur Reddit un thread qui a l'air assez impactant
niveau sécurité:
https://www.reddit.com/r/programming/comments/a3kk7u/australian_programmers_could_be_fired_by_their/

Apparemment, les deux chambres du parlement australien ont voté aujourd'hui
une loi contraignant les entreprises (étrangères ou australiennes) faisant
du business avec des entités (privées ou publiques) australiennes à
implémenter dans leurs produits une possibilité pour les autorités
australiennes de déchiffrer n'importe quelle communication. Sont ciblés les
GAFA mais pas seulement, toute société disposant d'un produit utilisant du
chiffrement devra se conformer à cette législation.
La loi "n'impose pas" de backdoor, mais fait risquer plusieurs années de
prison à toute personne physique ou morale qui refuserait de se plier à la
demande des autorités (les commentateurs du thread et les journalistes de
l'article lié indiquent clairement que les autorités vont cibler
individuellement les développeurs pour qu'ils installent des faiblesses à
l'insu de leurs employeurs).

Des risques que ce genre de loi soit véritablement appliquée ?

Il y en a parmi vous qui travaillent avec des sociétés australiennes ou qui
utilisent des produits développés dans ce pays ? Quels risques selon vous
sur votre activité ?
Par exemple, Atlassian (Jira, Bitbucket, sourceTree, Trello) est une
société australienne qui devra se conformer à cette législation...

Barth

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




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

[FRnOG] [Tech] Seagate "hyperscale"

[Frederic Dumas]

Une question destinée aux membres de la liste qui auraient rencontré ces 
disques durs dans leurs baies. Il s'agit des modèles chez Seagate :


ST1NM0086

et

ST1NM0016





La seule différence entre ces deux modèles tiendrait à leur firmware. Le 
premier serait "standard", l'autre "hyperscale"/"ultra-évolutif"). Le 
firmware "hyperscale" offrirait 20% d'IOPS en plus. En contrepartie, 
présente-t-il certains inconvénients ?



Quelqu'un a-t-il en sait-il plus sur le sujet ?


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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

Re: [FRnOG] [MISC] 06 ABPQ - portage vers operateur VoIP ? [Oui c'est possible]

[Frederic Dumas]

Merci Nicolas pour votre réponse précise.

Comme quoi rien de tel que de poser la question à ceux qui en 
connaissent, plutôt que de se persuader que "ça n'est pas possible, 
puisque ça ne s'est jamais fait".


Merci à Richard et Olivier aussi, pour les infos immédiatement 
utilisables que vous m'avez données.


Frédéric.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


Le 25/10/2018 à 09:44, Nicolas Bougues a écrit :

Ce cas n'était pas vraiment prévu par la réglementation jusqu'à maintenant
(même si certains MVNOs notamment avaient des offres plus ou moins
approchantes, cf autres posts), mais c'est chose faite depuis cet été avec
la décision ARCEP 2018-0881 sur les nouvelles règles du plan de
numérotation qui prévoit dorénavant l'existence d'opérateurs mobiles basés
sur VoIP (et donc non sur un PLMN).

Ce genre d'offre devrait donc se développer.

Le mer. 24 oct. 2018 à 18:46, Frederic Dumas  a
écrit :



Bonjour,

En France, la réglementation permet-elle de porter un numéro de
téléphone mobile vers un opérateur VoIP ? Je m'attends à une réponse
négative, mais peut-être existent des cas particuliers ?

Le but serait de réunir sur un seul abonnement 4G data, sans service
voix, différentes lignes mobiles et fixes, toutes terminées en VoIP.



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

[FRnOG] [MISC] 06 ABPQ - portage vers operateur VoIP ?

[Frederic Dumas]

Bonjour,

En France, la réglementation permet-elle de porter un numéro de 
téléphone mobile vers un opérateur VoIP ? Je m'attends à une réponse 
négative, mais peut-être existent des cas particuliers ?


Le but serait de réunir sur un seul abonnement 4G data, sans service 
voix, différentes lignes mobiles et fixes, toutes terminées en VoIP.


Merci.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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

Re: [FRnOG] [TECH] mini serveur domestique

[Frederic Dumas]

Pour un usage NAS/NextCloud à la maison, un peu comme ce que décrit 
Elonga, je voudrais reconvertir un vieux Juniper, conserver son boîtier 
1U, et remplacer sa carte mère FlexATX.


La carte que tu as choisi, Olivier, quel est son format ? Probablement 
au moins mini-ATX vu le nombre de ports que tu décris.


Dans quel format compatible avec la visserie FlexATX j'aurai le plus de 
chance de trouver sur le marché des cartes serveur SOHO de petite taille 
revendues d'occasion ?


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


Le 14/10/2018 à 19:34, Olivier Lange a écrit :

3VM sur un raspberry? Ca devient chaud. Surtout que l'on est pas en x86,
mais en ARM.

De mon coté, j'ai pris une carte mère avec pas mal de bord Sata (j'ai 5
disques de 4To en Raid 5 dessus), sur base AMD (moins cher que de l'intel
et parfait pour de la virtu), 16Go de RAM. Et avec un
proxmox/KVM/VMWare/Xen selon tes préférences, tu monde ce que tu veux.

Mais commencer a vouloir cumuler virtu, stockage, pas cher et resapberry,
il y a 1, voir 2 paramètres qui sautent...

Olivier

Le dim. 14 oct. 2018 à 18:56, elonga bopeto  a
écrit :


Merci pour vos retours.
Après un rapide tour sur le site de synology, il semblerait que seuls
quelques os soient supportés en virtualisation. Pas de fortigate ni vyatta
ni pfsense...

Quand aux raspberry et consorts, il est possible d'y installer un
hyperviseur bare metal afin d'y virtualiser à minima 3 vm?



Le dim. 14 oct. 2018 à 18:37,  a écrit :


Un syno + son gestionnaire de vm (intégré) = solution domestique parfaite
:)


*Kevin LABECOT*
Responsable Infrastructure
Service Informatique

*1001pneus* 
4/6 cours de l'intendance
33000 Bordeaux

*Envoyé depuis mon mobile* *Tel:* 05 35 54 31 10
*Mob:* 06.08.46.96.50
*Fax:* 01.83.64.28.70
*E-mail:* kevin.labe...@1001pneus.fr


Le 14 oct. 2018 à 18:26 +0200, Guillaume Tournat ,
a écrit :

En solution à la maison, j’ai un Synology
Ça permet de faire plein de choses


Le 14 oct. 2018 à 18:10, elonga bopeto  a écrit :

Bonjour la communauté,

Je cherche une solution silencieuse, faible encombrement, faible
consommation électrique et faible coup, afin de faire tourner quelques
services à mon domicile.
Je pense à un NAS pour backuper google drive/photo, un serveur web et un
reverse proxy ainsi qu' un firewall pour sécuriser le tout (VM Fortigate
ou
Vyatta ou pfsense ou d'autres...)
Il me servira également à réaliser mes labs.

Quel solution physique, logicielle et architecture me conseillerez-vous?

Merci pour vos retours

Cordialement,
Elonga

---
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/




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

Re: [FRnOG] [TECH] iperf - resultats invalides ?

[Frederic Dumas]

prise, donc
>> meme infrastructure) me fait tout simplement passer par New York (donc
>> plus 1200 km en plus)
>> Dernier exemple, c'est une petite entreprise qui gère la connexion de
>> mon immeuble. Je sais que je suis _bridé_ à 4Mb/s. C'est très précis,
>> par contre un petit test de débit avec speedtest.net me remonte tout
>> simplement un 14~15Mb/s. Ma conclusion, si tu paye pas le gros tarif,
>> tu te paye un transit de m***, et en plus on te fait croire que.
>> Un iperf ne m'aurait donc donné aucune métriques fiables, sachant que
>> c'est complètement dépendant de mon FAI, et des intermédiaires. Donc
>> c'est même plus pertinent au final pour le commun des mortels. Tout le
>> monde fait sa petite poutine dans son coin, et toi tu reste un peu
>> béat pour comprendre pourquoi ça bloque. Néanmoins, je pense que ca
>> reste pertinent dans le cadre d'un réseau dont on a le contrôle ou que
>> l'on prends des services pro. Pour le reste, laisse tomber, il y'a
>> trop de facteurs variables pour en tirer une quelconque conclusion.
>> En espérant que mon commentaire soit pertinent,
>> Bonne continuation
>> --
>> MrJK
>> Website: http://jeznet.org/
>> Le 19 août 2017 à 05:05, Frederic Dumas  a écrit :
>>> 
>>> Merci.
>>> 
>>> J’ai négligé d’installer la version 3 disponible en package sur le site 
>>> iperf.fr et fait confiance aux repositories officiels dont elle est 
>>> absente. La présence de la version 2 par défaut dans Debian est-elle du à 
>>> une divergence de vues avec les développeurs ?
>>> 
>>> Après quelques tests vers des destinations extra-européennes j’aimerai les 
>>> commentaires de ceux qui ont l’habitude de l'outil. Tous les tests ont été 
>>> effectués depuis une interface Fast Ethernet.
>>> 
>>> 
>>> 
>>>  1 - vis-à-vis du Kazakhstan (iperf.it-north.net)
>>> 
>>> 
>>> 
>>>  1.1 en upload depuis la machine locale, TCP parvient à saturer l'interface
>>> 
>>> 
>>> iperf3 -fm -c iperf.it-north.net -p 5201
>>> Connecting to host iperf.it-north.net, port 5201
>>> [  4] local 192.168.1.252 port 51830 connected to 82.200.209.194 port 5201
>>> [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
>>> [  4]   0.00-1.00   sec  3.52 MBytes  29.5 Mbits/sec0905 KBytes
>>> [  4]   1.00-2.00   sec  11.6 MBytes  97.0 Mbits/sec0   1.52 MBytes
>>> [  4]   2.00-3.00   sec  11.2 MBytes  94.2 Mbits/sec0   1.52 MBytes
>>> [  4]   3.00-4.00   sec  11.2 MBytes  94.3 Mbits/sec0   1.52 MBytes
>>> [  4]   4.00-5.00   sec  11.2 MBytes  94.3 Mbits/sec0   1.52 MBytes
>>> [  4]   5.00-6.00   sec  11.2 MBytes  93.9 Mbits/sec0   1.52 MBytes
>>> [  4]   6.00-7.00   sec  11.2 MBytes  94.3 Mbits/sec0   1.52 MBytes
>>> [  4]   7.00-8.00   sec  11.2 MBytes  93.8 Mbits/sec0   1.52 MBytes
>>> [  4]   8.00-9.00   sec  11.2 MBytes  94.4 Mbits/sec2   1.52 MBytes
>>> [  4]   9.00-10.00  sec  11.2 MBytes  94.4 Mbits/sec0   1.52 MBytes
>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>> [ ID] Interval   Transfer Bandwidth   Retr
>>> [  4]   0.00-10.00  sec   105 MBytes  88.0 Mbits/sec2 sender
>>> [  4]   0.00-10.00  sec   102 MBytes  85.9 Mbits/sec  
>>> receiver
>>> 
>>> iperf Done.
>>> 
>>> 
>>> 
>>>  1.2 en download, TCP est cappé à 2Mbits !
>>> 
>>> 
>>> iperf3 -fm -R -c iperf.it-north.net -p 5201
>>> Connecting to host iperf.it-north.net, port 5201
>>> Reverse mode, remote host iperf.it-north.net is sending
>>> [  4] local 192.168.1.252 port 51826 connected to 82.200.209.194 port 5201
>>> [ ID] Interval   Transfer Bandwidth
>>> [  4]   0.00-1.00   sec   249 KBytes  2.04 Mbits/sec
>>> [  4]   1.00-2.00   sec   277 KBytes  2.27 Mbits/sec
>>> [  4]   2.00-3.00   sec   277 KBytes  2.27 Mbits/sec
>>> [  4]   3.00-4.00   sec   286 KBytes  2.34 Mbits/sec
>>> [  4]   4.00-5.00   sec   283 KBytes  2.32 Mbits/sec
>>> [  4]   5.00-6.00   sec   274 KBytes  2.25 Mbits/sec
>>> [  4]   6.00-7.00   sec   266 KBytes  2.18 Mbits/sec
>>> [  4]   7.00-8.00   sec   286 KBytes  2.34 Mbits/sec
>>> [  4]   8.00-9.00   sec   266 KBytes  2.18 Mbits/sec
>>> [  4]   9.00-10.00  sec   280 KBytes  2.29 Mbits/sec
>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>> [ ID] Interval   Transfe

Re: [FRnOG] [TECH] iperf - resultats invalides ?

[Frederic Dumas]

 Mbits/sec  
[  4]  16.00-17.00  sec  1.08 MBytes  9.03 Mbits/sec  
[  4]  17.00-18.00  sec  2.88 MBytes  24.2 Mbits/sec  
[  4]  18.00-19.00  sec  3.61 MBytes  30.3 Mbits/sec  
[  4]  19.00-20.00  sec  4.93 MBytes  41.4 Mbits/sec  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-20.00  sec   105 MBytes  44.2 Mbits/sec  1268 sender
[  4]   0.00-20.00  sec  99.0 MBytes  41.5 Mbits/sec  receiver

iperf Done.


Le résultat est probablement normal ?



 2.2 Impossible d’obtenir un résultat en download en utilisant UDP


iperf3 -fm -u -b 70M -R -c iperf.he.net -p 5201
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending
[  4] local 192.168.1.252 port 38587 connected to 216.218.227.10 port 5201
iperf3: OUT OF ORDER - incoming packet = 3 and received packet = 0 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 4 and received packet = 0 AND SP = 28
iperf3: OUT OF ORDER - incoming packet = 8 and received packet = 0 AND SP = 28
iperf3: OUT OF ORDER - incoming packet = 6 and received packet = 0 AND SP = 28
iperf3: OUT OF ORDER - incoming packet = 7 and received packet = 0 AND SP = 28



 2.3 en upload depuis la machine locale, j’ai du mal à croire les résultats


iperf3 -fm -c iperf.he.net -p 5201
Connecting to host iperf.he.net, port 5201
[  4] local 192.168.1.252 port 50746 connected to 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[  4]   0.00-1.00   sec  4.12 MBytes  34.6 Mbits/sec0226 KBytes   
[  4]   1.00-2.00   sec  1.74 MBytes  14.6 Mbits/sec7256 KBytes   
[  4]   2.00-3.00   sec  1.24 MBytes  10.4 Mbits/sec   10139 KBytes   
[  4]   3.00-4.00   sec   827 KBytes  6.78 Mbits/sec1110 KBytes   
[  4]   4.00-5.00   sec   509 KBytes  4.17 Mbits/sec2   86.3 KBytes   
[  4]   5.00-6.00   sec   445 KBytes  3.65 Mbits/sec1   69.3 KBytes   
[  4]   6.00-7.00   sec   382 KBytes  3.13 Mbits/sec1   52.3 KBytes   
[  4]   7.00-8.00   sec   382 KBytes  3.13 Mbits/sec1   62.2 KBytes   
[  4]   8.00-9.00   sec   318 KBytes  2.60 Mbits/sec2   39.6 KBytes   
[  4]   9.00-10.00  sec   191 KBytes  1.56 Mbits/sec1   32.5 KBytes   
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec  10.1 MBytes  8.46 Mbits/sec   26 sender
[  4]   0.00-10.00  sec  6.14 MBytes  5.15 Mbits/sec  receiver

iperf Done.


Une règle de shapping semble attaquer le traffic TCP pour le faire tomber à 
1Mbps. Pour quelle raison pourrait-elle être en place sur l'Atlantique ? Notre 
ISP n’aime pas iperf ?



 2.4 tandis que le même upload en UDP montre une autre réalité


iperf3 -fm -u -b 70M -c iperf.he.net -p 5201
Connecting to host iperf.he.net, port 5201
[  4] local 192.168.1.252 port 59511 connected to 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth   Total Datagrams
[  4]   0.00-1.00   sec  7.94 MBytes  66.6 Mbits/sec  1016  
[  4]   1.00-2.00   sec  8.33 MBytes  69.9 Mbits/sec  1066  
[  4]   2.00-3.00   sec  8.65 MBytes  72.5 Mbits/sec  1107  
[  4]   3.00-4.00   sec  8.22 MBytes  68.9 Mbits/sec  1052  
[  4]   4.00-5.00   sec  8.24 MBytes  69.1 Mbits/sec  1055  
[  4]   5.00-6.00   sec  8.67 MBytes  72.7 Mbits/sec  1110  
[  4]   6.00-7.00   sec  7.55 MBytes  63.3 Mbits/sec  966  
[  4]   7.00-8.00   sec  9.06 MBytes  76.0 Mbits/sec  1160  
[  4]   8.00-9.00   sec  8.33 MBytes  69.9 Mbits/sec  1066  
[  4]   9.00-10.00  sec  7.91 MBytes  66.3 Mbits/sec  1012  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  4]   0.00-10.00  sec  82.9 MBytes  69.5 Mbits/sec  0.112 ms  81/10609 
(0.76%)  
[  4] Sent 10609 datagrams

iperf Done.




Merci pour vos commentaires et possible liens vers d’autres outils et documents 
d’intérêt sur le sujet.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr





Le 19 août 2017 à 05:37, lilian coupat  a écrit :

> bonjour,
> 
> utilise iperf3
> 
> lilian
>   Lilian Coupat | Abeille Informatique
> 5 Avenue du Maréchal Leclerc - 63800 Cournon d'Auvergne
> 04 73 145 145 | lil...@abeille.com | www.abeille.com
> 
> 
>> Le 19 août 2017 à 01:48, Frederic Dumas  a écrit :
>> 
>> iperf -fm -c ping.online.net -p 5206
> 



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

[FRnOG] [TECH] iperf - resultats invalides ?

[Frederic Dumas]

Bonjour,

Quel serveur iperf public conseilleriez-vous d’utiliser pour tester le débit de 
l’accès fibre desservant nos locaux ? La liste disponible sur 
 comporte plusieurs serveurs down, mais 
surtout, quelque soit le serveur vers lequel nous lançons le test, nous 
obtenons des résultats apparemment incohérents. 


Exemples sous OS X :


iperf -fm -c ping.online.net -p 5206



Client connecting to ping.online.net, TCP port 5206
TCP window size: 0.13 MByte (default)

[  5] local 192.168.1.121 port 50092 connected with 62.210.18.40 port 5206
[ ID] Interval   Transfer Bandwidth
[  5]  0.0-10.0 sec  17592186044410 MBytes  14755994915045 Mbits/sec




iperf -c iperf.he.net -p 5201



Client connecting to iperf.he.net, TCP port 5201
TCP window size:  129 KByte (default)

[  5] local 192.168.1.121 port 50119 connected with 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth
[  5]  0.0-10.0 sec  18446744073703073792 bits  
4719582677184484421763740882142s/sec




Exemple sous Ubuntu :


iperf -fg -u -c iperf.he.net -p 5201



Client connecting to iperf.he.net, UDP port 5201
Sending 1470 byte datagrams
UDP buffer size: 0.00 GByte (default)

[  3] local 192.168.1.252 port 58470 connected with 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  60.0 GBytes  51.5 Gbits/sec
[  3] Sent 893 datagrams
read failed: Connection refused
[  3] WARNING: did not receive ack of last datagram after 1 tries.



iperf -fm -c iperf.volia.net -p 5201



Client connecting to iperf.volia.net, TCP port 5201
TCP window size: 0.04 MByte (default)

[  3] local 192.168.1.252 port 49752 connected with 82.144.193.18 port 5201
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  2804690943 MBytes  2350702998 Mbits/sec





Est-ce le client iperf 2.0.5 utilisé qui serait boggué ?
Ou l’habituel problème de l’interface entre la chaise et le clavier ?


Merci pour vos conseils.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr



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

[FRnOG] [TECH] SIP sur Wi-Fi

[Frederic Dumas]

Bonjour,

est-ce prudent de se reposer sur des APs wifi pour connecter des combinés SIP à 
l’IPBX ? Qui aurait un retour d’expérience avec les fonctions de type « zero 
handoff » (tous les access points émettent sur le même canal pour éviter que 
les combinés se dissocient des APs en passant de l’un à l’autre) ?

Peut-on trouver des combinés VoIP Wi-Fi travaillant sur 5Ghz, outre des 
smartphones équipés d’un client SIP ? Est-ce pertinent ?

Merci pour vos conseils.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr




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

[FRnOG] [MISC] Trunk SIP - quels providers sur l'Europe ?

[Frederic Dumas]

Bonjour à tous,

quels sont les fournisseurs de trunk SIP à regarder (outre OVH bien connu) pour 
écouler du traffic sortant en Europe (10.000 minutes/mois à la louche) ? 
Chercher un fournisseur par pays pour les premières destinations (c.a.d. les 
mobiles) permet-il d’optimiser franchement les prix ou c’est une illusion ?

La personnalisation du caller ID (ne pas présenter les appels avec un numéro 
letton sous prétexte que le provider serait basé là-bas) est-elle la règle ou 
l'exception ?

En remerciant d’avance les personnes qui ont cette expérience pour leurs 
conseils.

Frédéric.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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