Re: [FRnOG] [BIZ] Pire que Cogent, ça existe...
On mercredi 18 octobre 2023 08:57:35 CEST, Stéphane Rivière wrote: Il y a quelques "petits" (Meta, rejoint par Intel, Google, Dell, etc...) qui ont ce projet : Oui... Certains taffent en PHP et JS en disant que ce sont des langages efficaces... Ca dépend de quelle efficacité on parle, en fouillant (beaucoup ?) on doit pouvoir trouver une mesure ou ils sont plus efficaces Mais je ne fais que signaler un projet en rapport avec le sujet, je ne suis pas en mesure de juger. Vu le monde dans le projet, je suppose/espère qu'ils ont des gens pour y réfléchir ... Il y a déjà des produits qui intègrent des morceaux de ce projet (la mezzanine OCP des serveurs), donc c'est quand même du concret, ca n'a pas l'air du projet fantasque d'une startup. On mercredi 18 octobre 2023 09:04:09 CEST, Stéphane Rivière wrote: Ce n'est absolument pas de la distribution en 48V au sein d'un DC. Non, je n'ai jamais dit ca. Je connais l'effet Joule et la conso d'un DC ... C'est, au niveau d'une baie, une mutualisation des alims par une alim proxy qui crache du 12V et 48V. J'ai bien écrit : par rack (ou baie en francais). Un "power shelf" (tiroir a alim) par baie, avec plusieurs alims 220/48V, managable avec un contrôleur de baie. Un peu comme un gros routeur/switch modulaire avec son fond de panier et sa rangée d'alim en fait ... Et là, *ça n'a rien à voir* et c'est pas con, pour plein de raisons... L'idée de faire du Tiers X en rajoutant des batteries dans chaque baie me semble étrange (sic) pour un DC. Par contre, pour quelques baies isolées, ça fait parfaitement sens et on fait déjà ça avec des onduleurs rackés. Ce n'est certainement pas le cas des acteurs en question qui sont plus dans les DC gigantesques. Il doit y avoir d'autres raisons (proximité alim, occupation espace ?), mais ca fait longtemps que j'ai regardé, et j'ai pas le courage/temps de fouiller leurs docs pour les retrouver. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Pire que Cogent, ça existe...
On mardi 17 octobre 2023 17:21:44 CEST, Stéphane Rivière wrote: Le 13/10/2023 à 14:55, Antoine Nivard - O.N via frnog a écrit : Je te confirme que quelques DC offrent du 48V comme Cogent Nantes (actuellement sous utilisé ). Nous sommes plusieurs à regarder des solutions type 48V car tu es en direct à la sortie des batteries de l'onduleur, gros gain en perspective. Les rendements théoriques légèrement supérieurs (on sait quand même faire des alims à découpage sans trop de pertes aujourd'hui) ne sont-ils pas compensés par les sections de câbles d'enfer nécessaires au 48V, la connectique d'enfer qui va avec, plus les pertes en ligne (entre les batteries et les consommateurs), plus le coût des alims 48V, nécessairement équipées de transfos de découpage 'légèrement' plus balèzes (euphémisme). Sans compter le coûts des appareillages en continu, également beaucoup plus coûteux¹ (re-euphémisme). ¹ On peut prendre du chinois toutefois. Il y a quelques "petits" (Meta, rejoint par Intel, Google, Dell, etc...) qui ont ce projet : https://www.opencompute.org/wiki/Open_Rack/SpecsAndDesigns En gros, alim 48V et BBU (optionnel) par rack, alim par busbar sur fond de panier derrière les équipements. Je n'ai pas lu tout le détail (bon courage!) ni vu de stats, mais je suppose qu'il y a des avantages a faire ça ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Convertisseur 10G BiDi vers 10G LR ou SR ou BaseT
Bonjour, On jeudi 24 août 2023 14:15:32 CEST, Fabien H wrote: je recherche un convertisseur qui permette la conversion 10G BiDi vers 10G LR ou SR ou BaseT. Il faudrait un produit bien entendu fiable, à un prix correct, et acceptant des SFP+ du marché. Avez-vous des références commercialisées actuellement ? Est-ce que FS part exemple ferait ça ? Je ne connais pas ces produits, mais 10s de recherche donnent ca : https://www.fs.com/fr/c/fiber-to-fiber-media-converters-1044 https://www.fs.com/fr/c/copper-to-fiber-media-converters-1038 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Vos retours sur StarLink ?
On jeudi 23 février 2023 10:12:27 CET, Nicolas Vuillermet wrote: PS3 : Ah oui, je veux bien aussi un retour si quelqu'un à fait de l'IPsec over IPv6 :} Quel genre de retours ? J'ai des clients en mode roadwarrior (win, lin, mac) sur un strongswan en dual stack/dual wan. Pas de soucis particuliers avec l'IPv6, et une bonne partie des clients l'utilise ... Je n'ai plus de site to site en IPv6 par contre, mais ceux que j'avais ne comptaient pas, je gérais les 2 cotés. Il ont été migrés sur WG depuis. Vincent Le 23/02/2023 à 10:09, Nicolas Vuillermet a écrit : IPsec, c'est quand ton réseau est pas trop mouillé ? La décennie passée, on avait IPsec pour faire du VPN site à site ou client serveur. L'avantage c'est que le bordel avec 3 milliards d'options, et si tu packages pas ça dans un binaire qui sait télécharger la config complète avec un simple user / pass (coucou Cisco Anyco). Bon, ok il y avait des intégrations OS mais paie ton set de configuration limitée, tu dois presque monter un serveur VPN en fonction du client (WTF ?) Hier, on avait les VPN SSL. Alors là, on est pas loin du gros mot qui commence par SD et fini par WAN. Entre les solutions propriétaires et les solutions propriétaires qui ne font que wrapper OpenVPN, c'était pas mieux, à part que commercialement, c'est sexy, SSL c'est mignon, les mec de la sécu sont tout heureux et IPse ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Grosse panne OVH ce matin
On mardi 26 avril 2022 15:53:46 CEST, Vincent Duvernet wrote: Est-ce que d'autres membres de la liste ont reçu ce type de message ? 1 perso, plus 1 sur la liste, tous depuis : Received: from mail.kodekh-telecom.fr (unknown [185.111.52.210]) avec des x-originating-ip depuis chine et pologne. Meme nom, meme email. Ca sent le compte "piraté" avec password123 ... Pas reçu d'autres depuis que j'ai ban l'ip de ce serveur ... Ça renvoie vers un téléchargement d'un fichier .XLSB donc franchement ça pue grave. Donc lien et fichier à ouvrir à vos risques & périls. Je me risquerais pas a l'ouvrir, mais virustotal est bien utile ... Vincent (Je ne suis pas au bureau, donc pas de lab de test cloisonné pour voir ce que ça fait). Vincent -Message d'origine- De : Kamel Moudachirou Envoyé : mardi 26 avril 2022 10:48 À : Vincent Duvernet Objet : Re: [FRnOG] [TECH] Grosse panne OVH ce matin Salut, Après avoir examiné tous ceux-ci, pourquoi ne pas programmer le temps parfait pour discuter: --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Curieux spam post-FRnog
On lundi 28 mars 2022 15:11:10 CEST, Stephane Bortzmeyer wrote: Le 14 décembre dernier, j'envoie un message sur la liste FRnog. Et, là, je reçois un spam de hameçonnage avec un sujet qui est le Re: du message en question, une partie du message dans le corps mais pas de Reply-To:. Quelqu'un se sert des archives de FRnog pour générer du spam ? Dans le but d'augmenter les chances de passer à travers les anti-spams ? Reçu aussi. C'est pas du spam, c'est un virus envoyé depuis une IP russe, et la fausse réponse, c'est plus certainement pour passer a travers les humains que l'anti-spam. Cependant il y tellement d'alarmes qui clignotent dans ce phishing (From:, html, pas de signature de la liste, pas de reply-to:) que c'est de la pêche a la baleine ... Point amusant : pour une fois, un bot qui comprends les emails avec un + dedans ! Le fichier dans le zip: https://www.virustotal.com/gui/file/9225e069e8460b5d813d8b9afac6fb72732f536033d055bf0e380a00897b0ac0 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] notation ipv6
On mardi 23 novembre 2021 17:48:14 CET, Pierre Colombier via frnog wrote: Après avoir saisi une adresse erronée, je viens de me rendre compte sur un mikrotik que quand on met un point dans une ipv6 ça fait des chose bizares... 2001::1.1 devient 2001::100:1 2001::42.17 devient 2001::2a00:11 Est-ce que c'est une étrangeté de la notation qui m'aurait échappé ou bien est-ce qu'il y a un bug ? C'est semi-valide, les ipv4 (donc les .) dans une ipv6 sont autorisées, par exemple pour exprimer une connexion ipv4 sur un socket qui écoute sur les 2 protocoles : :::127.0.0.1 Par contre, la notation avec la moitié d'une ipv4 (ipv2 ?), ca me semble beaucoup moins correct, il n'existe pas a ma connaissance de format compressé pour les ipv4. $ ipv6calc -I ipv6addr -O ipv6addr 2001::42.17 Error in given address expanded to '2001:0:0:0:0:0:42.17' is not valid! $ ipv6calc -I ipv6addr -O ipv6addr 2001::42.0.0.17 2001::2a00:11 $ ipv6calc -I ipv6addr -O ipv6addr 2001::1.1 Error in given address expanded to '2001:0:0:0:0:0:1.1' is not valid! $ ipv6calc -I ipv6addr -O ipv6addr 2001::1.0.0.1 2001::100:1 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [JOBS] Recrute Ingé Sys
Le Sunday 27 June 2021 12:30:28 Vincent Habchi a écrit : > > On 27 Jun 2021, at 12:15, Sébastien Lesimple wrote: > > > > > > J'ai besoin de remettre en marche une équipe IT de production d'une > > boite de la FrenchTech Paris et recrute 3 ingénieurs Systeme. > > > > > > > > Le projet est de remettre au carré le lot SI de production (sur stack > > […] > Remettre « au carré » avec 3 ingés, ça risque d’être un peu bancal. :p Au contraire, avec 3 points d'appui ça ne peut pas être bancal, et ça devrait même être bien stable, à défaut d'être carré ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] John McAfee RIP
On jeudi 24 juin 2021 18:21:56 CEST, Michel Py via frnog wrote: Vincent Habchi a écrit : Bon, il savait peut-être programmer, mais n’empêche. Et encore. L'antivirus du même nom, j'en ai des très mauvais souvenirs. Lui aussi (NSFW !) : https://youtu.be/bKgf5PaBzyg --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Framework Visio compatible France
Bonjour, Le Monday 21 June 2021 14:54:53 x.r...@sipleo.com a écrit : > Avez-vous une idée dun Framework Visio assez proche des techno Zoom ? ... > Javais vu passer un jour une liste avec différents projets conseillés en ce > sens (usage pour service étatique et éducation), et il y avait un projet > Framework sur le sujet. En solution finie : - Jitsi : https://sill.etalab.gouv.fr/fr/software?id=67 - BigBlueButton : https://sill.etalab.gouv.fr/fr/software?id=196 Un peu moins fini (pour la partie web) : - Freeswitch + Verto Communicator DIY : - Kurento Media Server - Janus WebRTC - MediaSoup --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] La "backdoor" de Chrome
Le Tuesday 06 April 2021 21:00:15 Erwan David a écrit : > Le 06/04/2021 à 20:42, Stéphane Rivière a écrit : > > Le 06/04/2021 à 20:19, Oliver varenne a écrit : > >> Oui, google adore petita petit restreindre les possibilités vis-à-vis des > >> certificats... Ce qui est super chiant quand tu développes (car tu > >> bosses généralement avec de l'auto signé)> > > Y'a pas mal de tutos sur le net pour utiliser des certifs LE dans un > > intranet. Mais bon... > > Et tu le déploie sur tes ILO/iDRAC/CIMC (j'ai cité 3 marques c'est OK > pour le CSA) ? Tous les 2 mois et demi... Sinon se créer une CA interne et l'importer dans chrom(e|ium). Pas très compliqué. Ou utiliser firefox ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Client IPsec Linux
Le Thursday 01 April 2021 19:28:47 Vincent Bernat a écrit : > ❦ 1 avril 2021 17:20 +02, Hugo SIMANCAS: > > Avez vous sous la main un client gratuit ou payant pouvant faire de > > l'IPSec nomade avec Linux (ubuntu?) - équivalent à TheGreenbow Windows > > L2TP over IPsec. Beurk. C'est plutot IP over PPP over L2TP over UDP over IPSEC over IP. Il reste encore de la place dans les paquets pour quelques octets de donnée, ou on rajoute une couche ? Et attention aux mélanges de mots de passe entre la couche IPsec (PSK, Xauth, x509, hybrid ?), et la couche PPP (PAP, CHAP, MSCHAPv2 ?). Plus les incompatibilités et les extensions propriétaires de IPsec/IKEv1 > Si tu ne maîtrises pas la solution côté serveur, Network Manager sait > aussi faire de l'IPsec classique avec Xauth (ce qui est courant dans le > monde Cisco). Ne pas maitriser le coté serveur, c'est aussi a peu près la seule raison d'utiliser IPsec/L2TP de nos jours. Sinon il y a la version 2 de IPsec : IKEv2. Intégré dans tous les OS depuis des années (sauf android, mais il y a l'appli strongSwan), authentification certificat coté serveur, login / mot de passe pour le client. Je conseille strongSwan coté client et serveur, mais libreswan le fait aussi. Performances identiques a IPsec pur (sans les surcouches l2tp), la couche data est la même (ESP), c'est la négociation des clés qui a changé. Ou wireguard pour les performances pures. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] OVH : SBG-2 en feu
Le Wednesday 17 March 2021 19:34:36 Philippe ASTIER via frnog a écrit : > Tout le monde savait que SBG2 était constitué de containers en free > cooling. Ettt non ! C'est comme le coup de la triple réplication ceph qui se transforme au fur et a mesure en triple backup, c'est faux. SBG1, SBG4 oui c'est des containers maritimes. SBG2 c'est (ou c'était) une tour avec patio en water/free cooling, mais en dur, pas en containers. SBG3 c'est en dur aussi, mais une autre techno que SBG2. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] OVH : SBG-2 en feu
On mercredi 17 mars 2021 14:42:07 CET, Daniel Caillibaud wrote: Le 17/03/21 à 13:12, Philippe ASTIER via frnog a écrit : Donc, je ne reste pas d’accord, OVH ne fait pas de « merde en boite », et permet d’avoir le niveau de sauvegarde qu’on l’on veut en fonction des risques dont ont veut se protéger, au prix que l’on accepte de payer. Apparemment le pb c'est surtout pour ceux qui avaient pris l'option backup automatique fait par ovh avec triple réplication, qui payaient pour ça leur vps le double, et qui ont perdu toutes leurs données quand même (je retrouve plus la page de description qui parlait de triple réplication sans dire où). Triple réplication ca veut juste dire : le disque est sur un cluster ceph, donc répliqué 3 fois (ce qui ne veut pas dire sur 3 disques / machines, mais bien plus vu le fonctionnement de ceph). Les snapshots pareil, c'est des snapshots ceph, donc sur le même cluster. Les seuls backups contractuels perdus que j'ai vu sont les backups veeam du private cloud, mais je ne crois pas qu'ils soient vendus "triple réplication". Sinon +1 également sur les 2 cents. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] OVH : SBG-2 en feu
Le Thursday 11 March 2021 17:17:55 Laurent Barme a écrit : > Le 11/03/2021 à 16:45, Vincent Tondellier via frnog a écrit : > > Le Thursday 11 March 2021 15:38:41 Mehdi GUIRAUD a écrit : > >> La Faq est en ligne.. > >> https://help.ovhcloud.com/fr/faq/strasbourg-incident/ > > > > Mouais, pas grand chose d'utile dans cette FAQ ... > > Mais si ! Dont les explications pour localiser ses services ; à lire tous > ceux qui posent la question, cela méritait des précisions. Il y a toujours des gens qui ne prennent pas la peine de chercher et ce n'est pas le genre de personne qui va aller lire la faq, donc même ça je ne suis pas sur que ce soit très utile. Le cas ou l'info n'est pas/plus dispo est différent, mais la non plus ce n'est pas la faq qui va apporter le renseignement. > > On trouve plus d'infos sur le twitter d'oles > > Nettement moins lisible quand même. > C'est certes plus concis, mais ca contient nettement plus d'informations > > et sur le blog : > > https://www.ovh.com/fr/news/presse/cpl1785.incendie-notre-site-strasbourg Ca s'adresse aussi a un public différent, bien plus en phase avec le public de frnog que la FAQ > La situation est quand même remarquablement bien gérée par OVH ; je ne > comprends pas ceux qui se permettent de critiquer. Un des points forts chez ovh c'est qu'en général c'est assez transparent et on sait ce qui se passe en termes techniques (mais il faut savoir ou chercher), je préfère ca que "nous constatons une augmentation du taux d'erreurs". Cependant il y a toujours a critiquer, rien n'est parfait. En tant qu'observateur neutre (aucun service affecté, et j'étais en plein audit de mes backups lors de l'annonce), je vois en amont la conception du datacenter, qui, comme plusieurs personnes l'ont souligné, ne semble pas avoir suffisamment pris en compte la lutte anti-incendie, puis, dans la réponse, la communication qui est faite sur plusieurs canaux avec des infos différentes (mais ca c'est pas nouveau et pas spécifique), et aussi le manque de clarté sur ce qui est perdu définitivement, entre les vps, ftpback, etc et leur zones. Et je ne parle pas des gens qui demandent quand leur dédié dans sbg2 va être remis en route (euh ...). C'est les principales récriminations que j'ai pu lire, mais c'est sur que l'état des lieux n'est pas forcément évident vu l'échelle d'ovh et l'ampleur de l'incident, et qu'il faut leur laisser le temps de compiler les infos (d'ici 48h pour ceux qui n'ont pas regardé la vidéo). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] OVH : SBG-2 en feu
Le Thursday 11 March 2021 15:38:41 Mehdi GUIRAUD a écrit : > La Faq est en ligne.. > https://help.ovhcloud.com/fr/faq/strasbourg-incident/ Mouais, pas grand chose d'utile dans cette FAQ ... On trouve plus d'infos sur le twitter d'oles et sur le blog : https://www.ovh.com/fr/news/presse/cpl1785.incendie-notre-site-strasbourg --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 802.1x : FreeRADIUS OpenLDAP
Bonjour,
Le Thursday 07 January 2021 10:31:27 Christian VAN DER ZWAARD a écrit :
> Je suis chargé de mettre en place de l’authentification et du VLAN
> assignment sur le réseau avec un serveur RADIUS et annuaire LDAP. J’ai
> choisi FreeRADIUS et OpenLDAP. L’authentification fonctionne mais je sèche
> au niveau de l’attribution du VLAN.
>
> Je n’arrive pas à créer une nouvelle object class custom dans l’annuaire et
> je ne sais pas comment "dire" au RADIUS où il doit récupérer le numéro de
> VLAN.
La plupart des switchs supportent la RFC3580.
En gros, il faut ajouter Tunnel-Type, Tunnel-Medium-Type et Tunnel-Private-
Group-ID dans la réponse.
Exemple rapide en utilisant le schema dans les sources de freeradius :
doc/schemas/ldap/openldap/freeradius.schema
Avec ce LDIF minimal :
#
dn: ou=radius,dc=example,dc=com
objectClass: organizationalUnit
dn: ou=users,ou=radius,dc=example,dc=com
objectClass: organizationalUnit
dn: ou=profiles,ou=radius,dc=example,dc=com
objectClass: organizationalUnit
dn: cn=phone,ou=users,ou=radius,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: radiusprofile
objectClass: organizationalRole
userPassword: {CLEAR}clearpassword
radiusTunnelPrivateGroupId: 2
radiusReplyAttribute: Cisco-AVPair = "device-traffic-class=voice"
dn: cn=vlan18,ou=users,ou=radius,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: radiusprofile
objectClass: organizationalRole
userPassword: {CLEAR}clearpassword18
radiusTunnelPrivateGroupId: 18
dn: cn=default-vlan,ou=profiles,ou=radius,dc=example,dc=com
objectClass: radiusObjectProfile
objectClass: radiusprofile
radiusTunnelType: VLAN
radiusTunnelMediumType: IEEE-802
#
Et cette configuration de freeradius (voir la conf par défaut pour les
commentaires) :
#
ldap ldap-8021x {
server = "ldaps://ldap.example.com"
base_dn = 'dc=example,dc=com'
valuepair_attribute = 'radiusAttribute'
update {
control:Password-With-Header += 'userPassword'
reply:Tunnel-Type := 'radiusTunnelType'
reply:Tunnel-Medium-Type := 'radiusTunnelMediumType'
reply:Tunnel-Private-Group-ID := 'radiusTunnelPrivategroupId'
control: += 'radiusControlAttribute'
request: += 'radiusRequestAttribute'
reply:+= 'radiusReplyAttribute'
}
user {
base_dn = "ou=users,ou=radius,${..base_dn}"
filter = "(&(objectClass=simpleSecurityObject)(cn=%{%{Stripped-User-
Name}:-%{User-Name}}))"
}
profile {
filter = '(objectclass=radiusprofile)'
default = "cn=default-vlan,ou=profiles,ou=radius,${..base_dn}"
}
}
#
Attention, si on utilise un EAP "tunnel" comme PEAP ou TTLS, il faut aussi
décommenter les sections update dans la section post-auth du site inner-tunnel
afin de copier les attributs dans la réponse envoyée au client.
Testé et validé pour du HPe/aruba (2530), Cisco (2960G), et dell (N1500/os9).
Pour avoir en plus des vlans taggés (mode general / trunk / switch), c'est
plus complexe (RFC4675) et beaucoup moins bien supporté, ca dépend du
constructeur ...
> Je suis preneur si vous avez des liens intéressants à ce sujet.
Je n'ai rien trouvé de très utile avec ldap, mais pour les vlans :
https://wiki.freeradius.org/vendor/HP#procurve-port-authentication-special-features_dynamic-vlan-assignment
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] serveurs de console (aka "terminal servers")
Le Monday 05 October 2020 17:31:23 Michel Py a écrit : > >> Philippe Apéry a écrit : > >> Auriez-vous des conseils ou des retours d'expériences pour des serveurs > >> de console (aka "terminal servers") avec ~16 ports.> > > Vincent Tondellier a écrit : > > https://www.mail-archive.com/frnog@frnog.org/msg57719.html > > Avec un peu moins de ports, il y aussi Airconsole : > https://www.get-console.com/shop/en/device-servers/93-airconsole-ts-4-port.h > tml Il y a ca aussi, mais c'est pas donné : https://www.lantronix.com/products/lantronix-slc-8000/ https://www.lantronix.com/products/lantronix-slb/ https://www.lantronix.com/products-class/device-servers/ Aucune idée de ce que valent ces produits la, mais j'ai déja utilisé des MSS100 mono port de la même marque. C'était cher aussi mais ca fonctionnait sans problème. Et ca fait pas POE non plus (sur le RPi, ca se justifie, ils cherchent a minimiser le prix donc a mettre le moins de composants possible, et le datacenter, c'est pas la cible initiale). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] serveurs de console (aka "terminal servers")
Le Monday 05 October 2020 16:15:55 Philippe Apéry a écrit : > Bonjour la liste, > > Auriez-vous des conseils ou des retours d'expériences pour des serveurs de > console (aka "terminal servers") avec ~16 ports. https://www.mail-archive.com/frnog@frnog.org/msg57719.html --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] ICMP partiellement bloqué en IPv6 entre Free et OVH ?
On jeudi 1 octobre 2020 12:29:52 CEST, Daniel via frnog wrote: Bonjour Le 01/10/2020 à 11:58, Vincent Tondellier via frnog a écrit : On jeudi 1 octobre 2020 11:49:12 CEST, Grégoire G wrote: Pour ma part, j'ai un compte SIP chez OVH, configuré sur mon smartphone. - Depuis une connexion Free fibre, l'authentification n’aboutit jamais. - Depuis une connexion data 3G ou 4G, chez Free mobile, ça passe. Ca a mon avis ca ressemble plus au 1/4 d'IPv4 de chez free. Ca fout la merde partout ce truc, c'est pire que le CGNAT. [...] Par curiosité, quel pourrait être le problème ? S'il sort par l'un de ses ports de son 1/4 d'ipv4 le serveur répondra à ce port, peu importe lequel aura été choisi. Pas de problème d'identification puisqu'il arrive bien sur le 5060 d'OVH. A condition que le client n'ait pas choisi le port de réponse lui même, c'est par exemple souvent le cas pour de l'ipsec (4500 fixe). Si ce port ne fait pas partie de la plage allouée au client, paf. Ce n'est pas impossible que suivant le client SIP (et sa configuration) il y ait le même soucis, et on est ici aussi en protocole udp. De ce que j'ai compris de ce truc, ce n'est pas du NAT classique. En cas de problème avec une connexion free en ipv4, je ne cherche pas a comprendre ce qui marche ou pas : étape 1, désactiver leur bidouille. Ensuite, si le problème persiste, on cherche a comprendre. Après ce n'est qu'une des possibilités, mais avec une probabilité assez forte. (peut être est il en ipv6 dans ce cas le problème ne se pose même pas) Il n'y a pas d'ipv6 activé sur le serveur sip ovh --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] ICMP partiellement bloqué en IPv6 entre Free et OVH ?
On jeudi 1 octobre 2020 11:49:12 CEST, Grégoire G wrote: Pour ma part, j'ai un compte SIP chez OVH, configuré sur mon smartphone. - Depuis une connexion Free fibre, l'authentification n’aboutit jamais. - Depuis une connexion data 3G ou 4G, chez Free mobile, ça passe. Ca a mon avis ca ressemble plus au 1/4 d'IPv4 de chez free. Ca fout la merde partout ce truc, c'est pire que le CGNAT. Demander une IP full stack, ca devrait être mieux --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] FREE - Portabilité d'un numéro RTC si déjà client
Le Tuesday 29 September 2020 23:32:11 Varicap a écrit : > >Attention cependant, si le lecteur de CB >et de carte vitale sont > >directement sur du RTC, il est fort probable que ce >soient des modems qui > >vont avoir du mal a fonctionner sur de la VOIP. > > Pour connaître un peu le sujet des modems et les problèmes de compression en > voip et en 2G c’est juste une modulation FSK. Si le modem n’arrive pas à se > connecter via un boîtier ATA il faudra tester du G711. Pour une box GP > aucun espoir de jouer sur le codec. > Par contre il suffit de demander au support qui gère votre TPE si il est > possible de descendre la vitesse du modem sur des vitesses de transmission > genre à 2400bds. Mais dans ce cas bon courages pour trouver le gars du > support qui aura cette information Moui, mais ca restera de la bidouille, il suffit d'avoir un peu de gigue sur la connexion IP pour perdre la connexion modem. Les normes UIT-T V.n comme le V.32/V.90 ont été conçues pour des médias synchrones/temps réel, pas pour de l'IP complètement asynchrone, les timings sont trop serrés. > Autre cas particulier les pabx avec du T0/T2 et les problèmes de > synchronisation TDM qui viendront perturber le signal. On avait plusieurs modems data pour télémaintenance qui ont servi quasi tous les jours pendant plus de 15 ans et on a toujours un fax (le tout analogique/modem, pas RNIS natif) sur un pabx connecté en T0 au réseau public, aucun problème de compatibilité a signaler. Peut être que c'est de la chance. > Juste pour illustrer mes propos dans les années 2000 je concevais une > passerelle voix vers GSM et sur un forfait SWEG j envoyais des faxs entre > 2400 et 4800bds dans le flux audio en 2G Le taux de réussite n était pas de > 100% mais il y avait de bon résultat sur des burns tests. G711, < 9600 bauds, c'est comme les fax analogiques en VOIP (hors T.38). Sur une connexion dédiée, sans gigue, ca passe a peu près la plupart du temps, lentement. Mais de manière générale c'est quand même pas fiable, donc méfiance. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] FREE - Portabilité d'un numéro RTC si déjà client
Le Tuesday 29 September 2020 23:19:10 Quentin Leconte, SHPV a écrit : > > 5 ans a l'avance, et les premières fermetures sont pour fin 2021 > > (finistère, zone de test), puis 2023 et 2024 (ex. autour de Colmar). Rien > > en 2022. > A priori, rien de nouveau d’annoncé depuis, donc aucune fermeture prévues > pour 2025 ? Prochain pas en 2026, peut-être... On a le temps. Aucune idée, je ne fais que répéter des infos publiques. Si orange dit vrai et que c'est vraiment un problème de maintenance, il doit être possible de prévoir les vagues de fermeture en trouvant la génération du central : https://fr.wikipedia.org/wiki/Commutateur_t%C3%A9l%C3%A9phonique#Les_commutateurs_%C3%A9lectroniques_de_type_temporel[2] Mais je ne sais pas si cette info est publique et ou la trouver > Par contre, il y a un vrai enjeux pour ceux qui ont besoin de faire évoluer > leur système legacy. Soit de la bricole à base de VoIP + gateway > analog/T0-2, soit un passage en full ip. C'est bien pour ca que les PME reçoivent tant de mails et d'appels de commerciaux tentant de vendre leur solution fibre+voip. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] FREE - Portabilité d'un numéro RTC si déjà client
Le Tuesday 29 September 2020 22:24:39 Daniel via frnog a écrit : > Le 29/09/2020 à 22:18, David Ponzone a écrit : > >> Le 29 sept. 2020 à 22:08, Daniel via frnog a écrit : > >> un prospect -cabinet dentaire- équipé d'une FB v6 et d'une ligne RTC pour > >> les appels, lecteur CB et lecteur carte vitale, doit tout passer en IP > >> suite à la fin du RTC annoncé par Orange.> > > Oui enfin, il a au moins 5 ans devant lui, calmes :) > > Ce n'est pas moi qui le stresse, c'est Orange ! De plus ils ont annoncé > 2022 ... Si on écoute les -casse-pieds-^H commerciaux pardon qui appellent tous les jours pour vendre leur solution, le RTC est arrêté depuis 2018. En général c'est pas orange mais un "partenaire" qui colle le logo orange dans ses mails qui prétend ca pour essayer de vendre en faisant peur (vite ca va fermer !!!). Sauf que dans la réalité c'est juste la construction de nouvelles lignes RTC ou RNIS qui n'est plus possible pour l'instant, la fermeture est annoncée plaque par plaque 5 ans a l'avance, et les premières fermetures sont pour fin 2021 (finistère, zone de test), puis 2023 et 2024 (ex. autour de Colmar). Rien en 2022. Voir https://www.arcep.fr/demarches-et-services/utilisateurs/consommateurs-arret-rtc.html pour la carte et les infos > Bref, tant qu'à faire, autant faire le saut. Attention cependant, si le lecteur de CB et de carte vitale sont directement sur du RTC, il est fort probable que ce soient des modems qui vont avoir du mal a fonctionner sur de la VOIP. Pour la question initiale sur la portabilité, aucune idée pour les opérateurs GP, mais chez les fournisseurs VOIP c'est faisable --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Souci chez Gigaset ?
Le Wednesday 23 September 2020 21:35:19 David Ponzone a écrit : > Oui je crois que c’est du RTX en OEM maintenant. En effet ca ressemble beaucoup a du RTX, ou alors c'est vachement bien imité. Le snom M700 c'est RTX8660, le M900 RTX8663, et on retrouve également toute la gamme des handset. Reste a savoir ce que ca vaut a l'usage > Y a même un distributeur de RTX sur la liste, je suis sûr qu’il va réagir :) > > Le 23 sept. 2020 à 21:31, Daniel via frnog a écrit : > > > > Bonsoir > > > > Le 23/09/2020 à 21:25, Vincent Tondellier via frnog a écrit : > >> Bonsoir, > >> > >> Il y a aussi les snom M900 qui ont l'air intéressantes sur le papier > >> (multi- cell avec base/contrôleur hybride qui évite d'avoir un > >> contrôleur dédié). > >> > >> Quelqu'un a déjà testé ? > > > > J'avais installé la 1ère série de SNOM Mx, une catastrophe. Peut être cela > > a évolué. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Souci chez Gigaset ?
Bonsoir, Il y a aussi les snom M900 qui ont l'air intéressantes sur le papier (multi- cell avec base/contrôleur hybride qui évite d'avoir un contrôleur dédié). Quelqu'un a déjà testé ? Vincent Le Wednesday 23 September 2020 05:31:57 Arthur Rodriguez via frnog a écrit : > Oui j’ai quelques client en w80 > Pour le moment tout ce passe bien j’en entends pas parler . > Avec des w53h et w59r . > Après c’est le début , on en déploie d’autre le mois prochain a suivre . > N720 on en a une centaine en parc globalement ça va mais parfois j’ai des > phénomènes inexpliqué . N870 deux très gros client dessus ok et deux moyen > ou ça mèrde . > > > > Le 23 sept. 2020 à 00:09, Wolf a écrit : > > > > > > N720, ça marche, tu touches plus. > > > > ça marche pas... bon chance. > > > > Arthur, tu as déjà testé les W80 ? ( ou quelqu'un d'autre ) > > > > Si il y a un produit non-spectralink qui fait bien le café, ce serait > > plaisant.> > >> Le mar. 22 sept. 2020 à 18:54, Arthur Rodriguez via frnog > >> a écrit : Bonjour > >> Effectivement gigaset c’est pas fou mais les nouvelles versions sont > >> encore pire On a des busy incohérent des bugs de codecs des tels qui ne > >> décroche pas . C’est un peux la foire gigaset > >> Yealink avec la w80 et le w59r va leur faire très mal si il ne réagisse > >> pas . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [TECH] THD sur maison isolé (LTE ?)
Le Tuesday 08 September 2020 20:37:07 Stéphane Rivière a écrit : > > Hein ? > > Ah, y a pas de PoE Gigabit ? Ils font comment mes téléphones Yealinks, > > mes NVR Ubiquiti, etc, etc…. :) > > Tu vois, je savais même pas (mouarf). J'en étais resté au 100 Mbps sur 2 > paires et 2 paires pour les 48V... C'est le cas pour le POE passif (certains constructeurs ne supportent que ca). Et parfois c'est pas du 48V en passif ... > Par contre, ça veux dire que le continu est présent sur les paires de > données je suppose... techniquement c'est une soluce vieille comme le > monde... Ca existe depuis très longtemps pour les microphones (alim phantom), oui. C'est injecté sur le point milieu du transfo, entre 2 paires de signaux différentiels (PoE/PoE+ / IEEE 802.3af/at) ou même les 4 paires (PoE++ / IEEE 802.3bt) jusqu'a 70W, avec un découpage en classes de puissances, le tout négocié a la connexion, donc actif. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] problème de flash avec ubiquity ES16-XG
Le Thursday 23 July 2020 19:18:24 Stéphane Rivière a écrit : Typique des pions FT232 de FTDI (de mémoire). ... Oui, ils avaient même été jusqu'a bricker "sans le faire exprès" les chips en question : https://hardware.slashdot.org/story/14/10/22/185244/ftdi-bricking Ca avait fait scandale a l'époque, vu qu'ils s'en prenaient de manière destructive aux utilisateurs finaux qui étaient pourtant autant victimes qu'eux. Du coup ils sont a moitié revenu en arrière, et aux dernières nouvelles le driver windows envoyait "NON GENUINE DEVICE FOUND!" sur le port série. Je ne peux pas confirmer, n'ayant pas de windows, et ayant évité d'acheter du ftdi depuis ... Et c'est juste le marquage qui était contrefait, le contenu n'a rien a voir : https://zeptobars.com/en/read/FTDI-FT232RL-real-vs-fake-supereal même les plus pourris, genre les "Prolific Technology", gazent bien). Ils ont pas l'air d'avoir fait beaucoup mieux chez prolific : http://www.ifamilysoftware.com/Prolific_PL-2303_Code_10_Fix.html Ils n'ont pas brické les contrefaits, mais ils ont quand même supprimé le driver, y compris pour leurs propres anciens produits. Cela dit, j'en ai un sur mon bureau (a priori le modèle en question, je ne sais pas si c'est un contrefait ou pas), et je n'ai jamais eu de problèmes avec sous linux. Vive les drivers libres ! Et tout ça alors qu'il ne devrait pas y avoir besoin de drivers spécifiques vu qu'il y a un protocole normalisé usb (comme HID pour les claviers/souris) spécialement pour ces adaptateurs : CDC --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Parefeu NGN pour besoin personnel
Le Tuesday 02 June 2020 12:14:12 Toussaint OTTAVI a écrit : > Le 30/05/2020 à 19:20, Vincent Tondellier via frnog a écrit : > >> Trouve m'en un qui fait routeur avec 4 interfaces Ethernet minimum, sans > >> WiFi, avec un form-factor qui ne ressemble pas à une navette spatiale, > >> et disponible dans nos contrées. Je le prends de suite :-) > > > > Le premier qui me passe par la tête : > > > > https://openwrt.org/toh/start?dataflt%5BModel*%7E%5D=apu > > > > https://www.pcengines.ch/apu2.htm > > Ce sont des machines x64, qui peuvent faire tourner des versions > complètes de Linux. Oui, aussi. Mais c'est des x86 embarqué, comme les geode ou atom. > Je ne les incluais donc pas dans les plateformes > OpenWRT (qui, à la base, est une version réduite de Linux pour systèmes > avec peu de ressources). Je sais, ca fait 15 ans que mon routeur perso est sous Openwrt (j'ai encore mon WRT54G dans un placard). Openwrt fonctionne sur pas mal d'architectures, du mips au x86_64 en passant par arm. Ca reste un Linux, il faut juste compiler pour la bonne plateforme. Mais avec la contrainte "4 interfaces ethernet" (je suppose que ca veut bien dire 4 interfaces, pas juste 4 prises), le matériel GP devient plus dur a trouver. Certains modèles ont 2 interfaces ethernet (une wan, une switch), mais rarement plus. Avec la fibre, on commence a voir apparaitre des modèles avec une interface 2.5Gb vers le switch interne, mais ca reste peu courant. Et sans wifi, ca devient très rare ... Les apu ont des interfaces complètes, pas un switch interne, sont dans la gamme de prix des routeurs GP, le wifi est optionnel, ils fonctionnent avec openwrt, et le design est on ne peut plus sobre (un bout d'alu plié et anodisé), donc pour moi ca répond au cahier des charges. > Il n'en demeure pas moins qu'installer OpenWRT > au lieu de Linux sur une APU peut s'avérer pertinent. Si on veut une interface web et/ou un truc tout fait, oui c'est bien pratique. > C'est ce semble faire OVH sur son modèle "OverTheBox IT". Sur aliexpress, on trouve même des constructeurs qui se contentent de changer le logo et de vendre un openwrt comme firmware de base avec leur matériel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Parefeu NGN pour besoin personnel
Le Saturday 30 May 2020 19:10:07 Toussaint OTTAVI a écrit : > > C'est inexact : OpenWRT est supporté sur de très nombreux devices pas > > seulement de l'AP/Router d'entrée de gamme => 1507 modèles d'après la > > liste courante https://openwrt.org/toh/start > > Trouve m'en un qui fait routeur avec 4 interfaces Ethernet minimum, sans > WiFi, avec un form-factor qui ne ressemble pas à une navette spatiale, > et disponible dans nos contrées. Je le prends de suite :-) Le premier qui me passe par la tête : https://openwrt.org/toh/start?dataflt%5BModel*%7E%5D=apu https://www.pcengines.ch/apu2.htm --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Plus que 0.12 Mb/s en upload !
Le Tuesday 26 May 2020 17:44:34 Laurent Barme a écrit : > Cela dit, je suis pas ici pur râler mais pour en savoir plus sur ce > phénomène inédit pour moi : comment peut-on avoir une synchro conforme et > juste l'upload foireux ? La synchro ca ne va que jusqu'au NRA. Il peut aussi y avoir des problèmes sur les différents réseaux, entre le nra et la porte de collecte, et entre la porte de collecte et la destination ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Fwd: Message important concernant les élections du RIPE
Bonsoir, Le Friday 08 May 2020 19:24:06 Bruno LEAL DE SOUSA a écrit : > Je ne connais pas ce fameux candidat Il suffit de chercher son nom suivi de afrinic ou de netstyle (le nom de son entreprise) pour avoir son historique. Et aussi lire les threads des "solutions" qu'il propose en suivant les liens de son mail pour voir leur valeur technique ... > mais au vu de la complexité d'adoption > de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est > intelligent et encourageant ! A condition que se soit techniquement réalisable et adoptable. Ce n'est ni l'un ni l'autre : de ce qu'on peut comprendre de sa "solution" il faut changer tout les routeurs backbone, le protocole bgp, et tous les os. Et pour pousser a l'adoption, il "offre" des ipv4+ sans valeur vu qu'inutilisable. A ma connaissance, les blocs ipv6 sont gratuits pour les LIR ... Bref, c'est juste un énorme troll, mais il a réussi ce qu'il voulait : on parle de lui ... > Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS a écrit : > > Bonjour, > > > > Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel > > est votre avis ? > > A bon entendeur. > > Christophe > > > > De : Elad Cohen > > Envoyé : vendredi 8 mai 2020 00:06 > > À : contact > > Objet : Message important concernant les élections du RIPE > > > > Bonjour, > > > > Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du > > RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois. > > > > J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967 > > 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le > > RIPE, vous pouvez en savoir plus à ce sujet ici : > > > > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676. > > html > > > > Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre > > RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu. > > Personne d'autre ne mettra en œuvre ma solution technique, je vous demande > > votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée > > générale du RIPE, ma solution technique ci-dessus ne sera pas mise en > > œuvre. > > > > Veuillez vous inscrire au vote en ligne pour les élections du RIPE en > > utilisant le lien suivant : > > https://www.ripe.net/s/gm-registration-may-2020 > > > > Si vous rencontrez un problème pour vous inscrire au vote en ligne, > > veuillez envoyer un courrier électronique à a...@ripe.net > a...@ripe.net> > > > > --- > > > > Outre la solution technique susmentionnée au problème de « l'épuisement de > > l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai > > de > > mettre en œuvre si j'ai l'honneur d'être élu : > > > > > > Une solution technique au problème mondial du spam par courrier > > électronique : > > > > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778. > > html > > > > Une solution technique au problème mondial de l'amplification de > > l'usurpation du DDoS : > > > > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902. > > html > > > > --- > > > > Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE > > devienne : > > > > - Une organisation 100% transparente. > > > > - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour > > chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer > > la > > qualité du service reçu et marquer si la demande d'assistance a été > > résolue > > ou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra > > automatiquement la demande d'assistance). Chaque aspect du RIPE changera > > pour être centré sur le LIR et non sur la bureaucratie. > > > > Une organisation efficace en termes de dépenses de RIPE, je veillerai > > personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE > > soit une organisation efficace. Lorsque RIPE soit devenue une organisation > > efficace, les cotisations annuelles des membres de RIPE seront > > considérablement réduites. > > > > Je vous demande de vous inscrire pour le vote en ligne en utilisant le > > lien suivant : > > https://www.ripe.net/s/gm-registration-may-2020 > > > > --- > > > > Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts, > > vous pouvez en voir l'exemple à travers les deux liens suivants : > > > > > > https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692. > > html > > > > Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration > > du RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de > > l'actuel président du conseil d'administration du RIPE, Christian > > Kaufmann, > > candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du > > candidat : » vous pouvez voir que la ligne « Raison de la nomination du > > candidat: » apparaît deux fois. Il y a une deuxième ligne « Raison de la > > nomination du
Re: [FRnOG] [TECH] comportement etrange smtp orange et starttls
Bonsoir, Le Friday 17 April 2020 01:16:09 Juan Isoza a écrit : > j'essaye avec plusieurs OS (essentiellement des variantes de linux) > > openssl s_client -starttls smtp -connect smtp-in.orange.fr:25 ha orange ... Il n'y aurait pas un gros message "SSL routines:ssl_choose_client_version:unsupported protocol" ? Ca donne quoi avec l'option -tls1 ? > avec une collection de openssl 1.1.0 ou 1.1.1 > > la moitier connectent, > l'autre pas... Cette moitié, c'est pas Debian et dérivés, par hasard ? orange ne supporte QUE TLSv1 (oui, en 2020), mais Debian a désactivé par défaut ce vieux protocole, obsolète, qui ne devrait plus être utilisé et "en danger critique d'extinction" vu que les navigateurs web l'ont (ou vont) le supprimer. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] softphone client SIP qui marchent au travers d'un VPN
Le Thursday 02 April 2020 19:16:41 Jean-Philippe Camguilhem a écrit : > On 02/04/2020 18:50, Vincent Tondellier via frnog wrote: > > Le Thursday 02 April 2020 16:36:17 Jérémie a écrit : > >> Un softphone en ncurse, voir CLI ca existe? > > > > http://www.creytiv.com/baresip.html > > > > Pas super stable non plus, et faut réussir a le configurer ... > > Donc si on résume les critères invoqués ici : > > + softphone client SIP > > + qui fonctionne nickel au travers d'un VPN (ie OpenVPN) > > + stable et facile à configurer > > + en mode CLI > > Je recommande vivement pjsua (https://www.pjsip.org/pjsua.htm) dont je > suis très satisfait depuis le début du confinement, sous OpenBSD. Les libs sont dans les dépots debian, pas le binaire ... Je vais essayer en compilant. En voyant les rdepends (asterisk), ca me fait penser que freeswitch peut aussi servir en mode UA, mais je n'ai jamais testé. > Pour l'aspect ergonomie et ou "user friendly" c' est par définition > totalement subjectif, et du coup ici encore plus biaisé par le fait de > vouloir un mode CLI. Certainement. J'ai déjà croisé pas mal de cli, de gui et de configs étranges durant ma carrière (et mon éditeur principal est vim ...), mais pour baresip il faut aller éditer les fichiers de conf sans doc autre qu'un wiki minimaliste avant de pouvoir en faire quelque chose. Ca place quand même la barre assez haut. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] softphone client SIP qui marchent au travers d'un VPN
Le Thursday 02 April 2020 16:36:17 Jérémie a écrit : > Sur PC, je cherches un softphone léger et stable, facile à utiliser (et > a configurer). J’aimais bien SFLPhone, mais maintenant c'est RING, c'est > bien plus lourd et pas stable. C'est jami maintenant, plus ring ... Même expérience avec (version Linux). Le codec opus est buggé (pas de son), les autres codecs ça "craque" (pas de pb avec d'autres logiciels), ça appelle le mauvais numéro juste après un ajout de contact, ergonomie bof, pas de logs pour debug ... > Un softphone en ncurse, voir CLI ca existe? http://www.creytiv.com/baresip.html Pas super stable non plus, et faut réussir a le configurer ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] OVH down
Le Monday 30 March 2020 17:28:45 Aymeric a écrit : > Bonjour, > > Il semble que tout le réseau OVH (AS16276) soit inaccessible. Pas tout, non, quelques ips résistent encore. C'est principalement roubaix qui est down de ce que vois http://travaux.ovh.net/?do=details=43793 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Covid-19
Le Friday 20 March 2020 15:01:22 cont...@doriangaliana.fr a écrit : > Je confirme pour BBB Ca fonctionne aussi, mais jitsi est bien plus simple > Assez complet et pas compliqué d'utilisation > 2 bémols pour moi : > Ubuntu 16.04Lts Obligatoire si vous voulez passer par le script > et le transcodage effectué en local comme sur Jitsi A 2 en p2p, non pas de transcodage. Mais en conf, oui, évidemment tout passe par le serveur. > Néanmoins il semble moins gourmand. Houla, non non non. Pas en RAM en tout cas. Jitsi c'est 2 services en java, un prosody et un nginx qui prennent rien, 1.5 Go de ram a tout casser. BBB c'est plusieurs trucs en java, un redis, un freeswitch, un mongodb, un nodejs, un ruby on rails, un libreoffice ... Pas sur que ca passe dans 4G. Bien sur, c'est plus complet. Aussi beaucoup plus complexe. Mais clairement pas plus léger. (et oui, ca en fait des langages de prog différents) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Covid-19
Salut, Le Friday 20 March 2020 12:43:47 SIMANCAS Hugo a écrit : > Tu l'administres comment ton serveur ? https://framacloud.org/fr/cultiver-son-jardin/jitsi-meet#4---regarder-pousser et /etc/jitsi/meet/*-config.js Ca se veut simple, il n'y a pas grand chose a administrer > On vient d'en monter un comme beaucoup ... > mais elle est où l'interface de customisation ? /usr/bin/vim ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Réduction du bitrate de Netflix
Le Friday 20 March 2020 07:08:46 Philippe Bourcier a écrit : > Et surtout : pourquoi pas YouTube... ? Done : https://www.numerama.com/tech/612838-coronavirus-youtube-baisse-la-qualite-par-defaut-des-videos-par-crainte-dune-saturation-des-reseaux.html --- Liste de diffusion du FRnOG http://www.frnog.org/
