Re: [FRnOG] [MISC] Machine à étiquette pour repèrage cable

[Julien Escario]

Le 21/01/2016 14:57, Cyril Lavier a écrit :
> Bonjour.
> 
> Chez nous, on utilise 2 étiqueteuses Brady.
> 
> Une BMP71, qui est aussi grosse qu'une machine à écrire. Elle est pratique 
> pour les gars de l'informatique interne, mais inutilisable en datacenter (le 
> poids et le fait qu'il faut constament la brancher au secteur). Faut aussi 
> prendre en compte que la gestion des consommables est infâme (le ruban et le 
> support imprimable sont séparés, avec le tambour pouvant servir à plusieurs 
> supports).
> 
> Et pour les sysadmins, on a une BMP41, plus petite, moins complèxe à utiliser 
> et moins complèxe en gestion des consommables (ce sont des cartouches 2 en 1, 
> pas comme sur la BMP71).
> 
> Clairement, les étiqueteuses et étiquettes Brady sont super chères, mais de 
> ce que j'ai vu, c'est de l'argent que je trouve bien dépensé, c'est du gain 
> de temps car les étiquettes ne se décollent pas et elles peuvent même être 
> contrôlées depuis un PC, assez pratiques pour les séquences d'étiquettes 
> depuis un fichier tableur ou une BDD (c'est du vécu). Et quand t'as trouvé 
> les quelques références d'étiquettes que t'as besoin, tu t'en fais un stock 
> sur l'année (ou +), et en bonus, mon commercial Brady n'est pas mauvais et 
> arrive à se débrouiller en cas d'urgence.
> 
> J'ai pu tester la BMP21, et clairement, c'est une bouse, avec un mauvais 
> rapport qualité-prix (pas étonnant qu'elle fume au bout de 2 ans), au point 
> que le commercial a préféré me faire un rabais sur la BMP41 plutôt que je 
> prenne la BMP21

Ah, merci pour le retour. Je veux bien le contact de ton commercial en hors
liste parce que je suis sur le point de balancer ma BMP21 et d'aller voir
ailleurs si les étiquettes collent mieux.
Ce qui serait dommage parce que je pense qu'ils gagnent leur vie en vendant du
consommable, j'imagine.

Julien




smime.p7s
Description: Signature cryptographique S/MIME

[FRnOG] [TECH] DNS TCP & UDP

[Julien Escario]

Bonjour,
Je tombe ce matin sur le cas d'un serveur DNS 'en face' qui ne répond pas en 
TCP.
Je ne suis pas un grand spécialiste mais d'après ce que j'ai pu lire sur la
kb.isc.org, "c'est mal".

Ce que je ne comprends pas, ce que le serveur répond en UDP et qu'il semblerait
que mon résolveur local ne fallback pas tout seul :

# dig @localhost ada.net.tr ANY => SERVFAIL

# dig @ns.ada.net.tr ada.net.tr ANY +tcp => SERVAIL aussi

# dig @ns.ada.net.tr ada.net.tr ANY +notcp => OK, j'ai la zone

Du coup, pourquoi mon Bind local ne tente pas la résolution en UDP ? Ca devrait
d'ailleurs être la première chose qu'il fait non ?

La conf du résolveur est basique : quelques zones qu'il sert de manière
autoritative, un cache qui n'est accessible que depuis localhost. Le reste c'est
stock Debian, rien concernant UDP ou TCP.

Julien




smime.p7s
Description: Signature cryptographique S/MIME

RE: [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

[Stephane COZETTE]

Bonjour,

Est-ce que les connexions DNS en TCP ne sont pas utilisées pour les 
réplications de zones (serveurs/serveur), là où les requêtes en UDP sont plutôt 
réservées aux clients ?
De là à dire que la non réponse en TCP c'est le mal, j'suis pas convaincu. 

J'ai pas le souvenir que "bind" sous Debian par exemple ouvre nativement le TCP 
(ce que ferait j'imagine un serveur DNS Microsoft pour potentiellement 
réplication entre 2 ADs).

Stéphane COZETTE

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Julien Escario
Envoyé : lundi 25 janvier 2016 14:06
À : frnog-t...@frnog.org
Objet : [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

Bonjour,
Je tombe ce matin sur le cas d'un serveur DNS 'en face' qui ne répond pas en 
TCP.
Je ne suis pas un grand spécialiste mais d'après ce que j'ai pu lire sur la
kb.isc.org, "c'est mal".

Ce que je ne comprends pas, ce que le serveur répond en UDP et qu'il semblerait
que mon résolveur local ne fallback pas tout seul :

# dig @localhost ada.net.tr ANY => SERVFAIL

# dig @ns.ada.net.tr ada.net.tr ANY +tcp => SERVAIL aussi

# dig @ns.ada.net.tr ada.net.tr ANY +notcp => OK, j'ai la zone

Du coup, pourquoi mon Bind local ne tente pas la résolution en UDP ? Ca devrait
d'ailleurs être la première chose qu'il fait non ?

La conf du résolveur est basique : quelques zones qu'il sert de manière
autoritative, un cache qui n'est accessible que depuis localhost. Le reste c'est
stock Debian, rien concernant UDP ou TCP.

Julien



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

RE: [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

[Stephane COZETTE]

Autant pour moi : "bind" ouvre nativement le TCP aussi... (bind9/Debian)

Stéphane COZETTE


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Stephane COZETTE
Envoyé : lundi 25 janvier 2016 14:26
À : Julien Escario ; frnog-t...@frnog.org
Objet : RE: [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

Bonjour,

Est-ce que les connexions DNS en TCP ne sont pas utilisées pour les 
réplications de zones (serveurs/serveur), là où les requêtes en UDP sont plutôt 
réservées aux clients ?
De là à dire que la non réponse en TCP c'est le mal, j'suis pas convaincu. 

J'ai pas le souvenir que "bind" sous Debian par exemple ouvre nativement le TCP 
(ce que ferait j'imagine un serveur DNS Microsoft pour potentiellement 
réplication entre 2 ADs).

Stéphane COZETTE

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Julien Escario Envoyé : lundi 25 janvier 2016 14:06 À : frnog-t...@frnog.org 
Objet : [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

Bonjour,
Je tombe ce matin sur le cas d'un serveur DNS 'en face' qui ne répond pas en 
TCP.
Je ne suis pas un grand spécialiste mais d'après ce que j'ai pu lire sur la 
kb.isc.org, "c'est mal".

Ce que je ne comprends pas, ce que le serveur répond en UDP et qu'il semblerait 
que mon résolveur local ne fallback pas tout seul :

# dig @localhost ada.net.tr ANY => SERVFAIL

# dig @ns.ada.net.tr ada.net.tr ANY +tcp => SERVAIL aussi

# dig @ns.ada.net.tr ada.net.tr ANY +notcp => OK, j'ai la zone

Du coup, pourquoi mon Bind local ne tente pas la résolution en UDP ? Ca devrait 
d'ailleurs être la première chose qu'il fait non ?

La conf du résolveur est basique : quelques zones qu'il sert de manière 
autoritative, un cache qui n'est accessible que depuis localhost. Le reste 
c'est stock Debian, rien concernant UDP ou TCP.

Julien



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

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

Re: [FRnOG] [TECH] DNS TCP & UDP

[Alarig Le Lay]

On Mon Jan 25 14:05:42 2016, Julien Escario wrote:
> Bonjour,
> Je tombe ce matin sur le cas d'un serveur DNS 'en face' qui ne répond pas en 
> TCP.
> Je ne suis pas un grand spécialiste mais d'après ce que j'ai pu lire sur la
> kb.isc.org, "c'est mal".
> 
> Ce que je ne comprends pas, ce que le serveur répond en UDP et qu'il 
> semblerait
> que mon résolveur local ne fallback pas tout seul :
> 
> # dig @localhost ada.net.tr ANY => SERVFAIL
> 
> # dig @ns.ada.net.tr ada.net.tr ANY +tcp => SERVAIL aussi
> 
> # dig @ns.ada.net.tr ada.net.tr ANY +notcp => OK, j'ai la zone
> 
> Du coup, pourquoi mon Bind local ne tente pas la résolution en UDP ? Ca 
> devrait
> d'ailleurs être la première chose qu'il fait non ?
> 
> La conf du résolveur est basique : quelques zones qu'il sert de manière
> autoritative, un cache qui n'est accessible que depuis localhost. Le reste 
> c'est
> stock Debian, rien concernant UDP ou TCP.

À mon avis, ce n’est pas spécifique à ton résolveur. J’utilise unbound
et j’ai un résultat similaire :

alarig@drscott:~$ dig ANY ada.net.tr @localhost

; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> ANY ada.net.tr @localhost
;; global options: +cmd
;; connection timed out; no servers could be reached
alarig@drscott:~$ dig +tcp ANY ada.net.tr @ns.ada.net.tr

; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> +tcp ANY ada.net.tr @ns.ada.net.tr
;; global options: +cmd
;; connection timed out; no servers could be reached
alarig@drscott:~$ dig +notcp ANY ada.net.tr @ns.ada.net.tr

; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> +notcp ANY ada.net.tr
@ns.ada.net.tr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44330
blah.

Et pendant ce temps,
`tcpdump -i eth0 host '(ns.ada.com.tr. or ns.ada.net.tr.)' and port 53`
Avec ça, je ne vois rien passer dans le premier cas, que du SYN dans le
deuxième, et du trafic DNS normal dans le troisième.

-- 
alarig


signature.asc
Description: Digital signature

Re: [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

[Alarig Le Lay]

On Mon Jan 25 13:25:59 2016, Stephane COZETTE wrote:
> J'ai pas le souvenir que "bind" sous Debian par exemple ouvre
> nativement le TCP (ce que ferait j'imagine un serveur DNS Microsoft
> pour potentiellement réplication entre 2 ADs).

alarig@alarig-OptiPlex-755 ~ $ telnet nemee.grifon.fr 53
Trying 91.224.149.128...
Connected to nemee.grifon.fr.
Escape character is '^]'.
^]

telnet> quit
Connection closed.

Et c’est de la conf debian de base.

-- 
alarig


signature.asc
Description: Digital signature

Re: [!!Mass Mail][FRnOG] [TECH] DNS TCP & UDP

[Julien Escario]

Le 25/01/2016 14:30, Stephane COZETTE a écrit :
> Autant pour moi : "bind" ouvre nativement le TCP aussi... (bind9/Debian)

Attention, mon propos était : ne PAS répondre en TCP, "c'est mal" (comme dans :
croiser les effluves, c'est mal).

Ce que je ne comprends pas c'est : même si TCP est firewallé, mon résolveur
devrait le tenter en UDP non ? On parle de requêtes basiques de type ANY (qmail
toussa) sans parler de AXFR/IXFR.

Julien




smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [TECH] DNS TCP & UDP

[Julien Escario]

Le 25/01/2016 14:30, Alarig Le Lay a écrit :
> À mon avis, ce n’est pas spécifique à ton résolveur. J’utilise unbound
> et j’ai un résultat similaire :
> 
> alarig@drscott:~$ dig ANY ada.net.tr @localhost
> 
> ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> ANY ada.net.tr @localhost
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> alarig@drscott:~$ dig +tcp ANY ada.net.tr @ns.ada.net.tr
> 
> ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> +tcp ANY ada.net.tr @ns.ada.net.tr
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> alarig@drscott:~$ dig +notcp ANY ada.net.tr @ns.ada.net.tr
> 
> ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> +notcp ANY ada.net.tr
> @ns.ada.net.tr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44330
> blah.
> 
> Et pendant ce temps,
> `tcpdump -i eth0 host '(ns.ada.com.tr. or ns.ada.net.tr.)' and port 53`
> Avec ça, je ne vois rien passer dans le premier cas, que du SYN dans le
> deuxième, et du trafic DNS normal dans le troisième.

Intéressant. Du coup, pourquoi en passant par ton résolveur, ça ne marche pas
(TCP ou UDP) ?
Il ne devrait pas se comporter exactement comme le dernier dig normalement ?
(aka résoudre)

Julien



smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [TECH] DNS TCP & UDP

[David Ponzone]

J’ai eu une réponse moi:

# dig ANY ada.net.tr @localhost

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ANY ada.net.tr @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17635
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ada.net.tr.IN  ANY

;; ANSWER SECTION:
ada.net.tr. 86238   IN  SPF "v=spf1 ip4:213.232.0.0/24 
ip4:195.112.155.0/24 ip4:195.112.155.194 ip4:213.232.28.0/24 -all"
ada.net.tr. 86238   IN  TXT "v=spf1 ip4:213.232.0.0/24 
ip4:195.112.155.0/24 ip4:195.112.155.194 ip4:213.232.28.0/24 -all"
ada.net.tr. 86238   IN  MX  0 mailcheck1.ada.net.tr.
ada.net.tr. 86238   IN  A   195.112.155.131
ada.net.tr. 86238   IN  SOA ns.ada.net.tr. 
root.ns.ada.net.tr. 2013121368 28800 7200 1209600 86400
ada.net.tr. 43028   IN  NS  ns.ada.net.tr.
ada.net.tr. 43028   IN  NS  ns.ada.com.tr.

;; AUTHORITY SECTION:
ada.net.tr. 43028   IN  NS  ns.ada.net.tr.
ada.net.tr. 43028   IN  NS  ns.ada.com.tr.

;; ADDITIONAL SECTION:
ns.ada.com.tr.  43028   IN  A   213.232.0.18
ns.ada.net.tr.  86301   IN  A   195.112.155.130

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 25 14:46:11 2016
;; MSG SIZE  rcvd: 422

Mais je crois que je l’ai eu seulement après avoir fait un:

dig www.ada.net.tr @localhost


> Le 25 janv. 2016 à 14:38, Julien Escario  a écrit :
> 
> Le 25/01/2016 14:30, Alarig Le Lay a écrit :
>> À mon avis, ce n’est pas spécifique à ton résolveur. J’utilise unbound
>> et j’ai un résultat similaire :
>> 
>> alarig@drscott:~$ dig ANY ada.net.tr @localhost
>> 
>> ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> ANY ada.net.tr @localhost
>> ;; global options: +cmd
>> ;; connection timed out; no servers could be reached
>> alarig@drscott:~$ dig +tcp ANY ada.net.tr @ns.ada.net.tr
>> 
>> ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> +tcp ANY ada.net.tr @ns.ada.net.tr
>> ;; global options: +cmd
>> ;; connection timed out; no servers could be reached
>> alarig@drscott:~$ dig +notcp ANY ada.net.tr @ns.ada.net.tr
>> 
>> ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> +notcp ANY ada.net.tr
>> @ns.ada.net.tr
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44330
>> blah.
>> 
>> Et pendant ce temps,
>> `tcpdump -i eth0 host '(ns.ada.com.tr. or ns.ada.net.tr.)' and port 53`
>> Avec ça, je ne vois rien passer dans le premier cas, que du SYN dans le
>> deuxième, et du trafic DNS normal dans le troisième.
> 
> Intéressant. Du coup, pourquoi en passant par ton résolveur, ça ne marche pas
> (TCP ou UDP) ?
> Il ne devrait pas se comporter exactement comme le dernier dig normalement ?
> (aka résoudre)
> 
> Julien
> 


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

[FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[David ALLARD]

 

Bonjour, 

J'aimerais savoir si quelqu'un a déjà eu à comparer un
réseau hertzien fonctionnant avec du matériel Cambium et du matériel
Ubiquiti. C'est pour un réseau fournissant du "haut-débit" dans des
zones blanches. 

On me dit ( :-) ) que le premier c'est du matériel
professionnel qui marchera à tous les coups et le second un truc pas pro
du tout qui va pas marcher du tout. 

J'avoue être un peu paumé donc si
quelqu'un a des pistes merci d'avance 

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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[Phil Regnauld]

David ALLARD (david.allard) writes:
>  
> J'aimerais savoir si quelqu'un a déjà eu à comparer un
> réseau hertzien fonctionnant avec du matériel Cambium et du matériel
> Ubiquiti. C'est pour un réseau fournissant du "haut-débit" dans des
> zones blanches. 
> 
> On me dit ( :-) ) que le premier c'est du matériel
> professionnel qui marchera à tous les coups et le second un truc pas pro
> du tout qui va pas marcher du tout. 

Euh, ça dépend vraiment du type d'application. C'est du backhaul 
point-à-
point ? De l'accès en intérieur ?

J'ai déployé du Ubiquiti dans les deux cas, y compris en afrique sub-
saharienne, et le matériel extérieur fonctionne parfaitement après
deux ans, en p-à-p, avec des débits variant entre 100 et 700 Mbps,
sur des distances allant de 3 à 50 km.

P.


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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[Laurent MARTY]

Bonjour

Nous utilisons de l'ubiquiti en 5ghz et 2,4Gh sur des zones blanches du 
Gard, quelques centaines d'utilisateurs ... Pas de soucis hors 
interférences et orage.


 Mais bon je pense qu'il n'y a pas de bon / mauvais matériel : il y a 
une utilisation conforme ou pas.


A bientôt

Le 25/01/2016 14:57, David ALLARD a écrit :
  


Bonjour,

J'aimerais savoir si quelqu'un a déjà eu à comparer un
réseau hertzien fonctionnant avec du matériel Cambium et du matériel
Ubiquiti. C'est pour un réseau fournissant du "haut-débit" dans des
zones blanches.

On me dit ( :-) ) que le premier c'est du matériel
professionnel qui marchera à tous les coups et le second un truc pas pro
du tout qui va pas marcher du tout.

J'avoue être un peu paumé donc si
quelqu'un a des pistes merci d'avance

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


--
Laurent MARTY
Gérant
lma...@nostre-pais.net
Agence : +33(0)972 13 12 00


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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[David ALLARD]

 

Merci pour ces premières réponses. 

Concernant l'usage, c'est à la
fois pour du PTP pour mailler le réseau et des AP pour que des usagers
se connectent dessus avec des antennes clients (CPE). 

C'est surtout
lorsque je vois la différence de tarif pour ces deux types de matériels
que je me pose des questions. 

Question complémentaire : Quelqu'un
a-t-il déjà géré une migration depuis une solution vers l'autre ?


Cordialement 

David ALLARD 
259 Route Départementale 813 
82400
GOUDOURVILLE 

Le 2016-01-25 15:16, Laurent MARTY a écrit : 

>
Bonjour
> 
> Nous utilisons de l'ubiquiti en 5ghz et 2,4Gh sur des zones
blanches du 
> Gard, quelques centaines d'utilisateurs ... Pas de soucis
hors 
> interférences et orage.
> 
> Mais bon je pense qu'il n'y a pas
de bon / mauvais matériel : il y a 
> une utilisation conforme ou pas.
>

> A bientôt
> 
> Le 25/01/2016 14:57, David ALLARD a écrit :
> 
>>
Bonjour, J'aimerais savoir si quelqu'un a déjà eu à comparer un réseau
hertzien fonctionnant avec du matériel Cambium et du matériel Ubiquiti.
C'est pour un réseau fournissant du "haut-débit" dans des zones
blanches. On me dit ( :-) ) que le premier c'est du matériel
professionnel qui marchera à tous les coups et le second un truc pas pro
du tout qui va pas marcher du tout. J'avoue être un peu paumé donc si
quelqu'un a des pistes merci d'avance David ALLARD
--- Liste de diffusion du FRnOG
http://www.frnog.org/ [1]
 

Links:
--
[1] http://www.frnog.org/

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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[Laurent MARTY]

J'ai eu a utilisé les deux, comme FAI avec 'ex  société Meshnet ... sur 
du motorola...

Comment dire : problèmes d'interférences + problèmes électriques.

En fait pour moi cambium et ubiquiti font le job, par contre quand il 
faut remplacer le matériel suite à panne ... il y a pas photo, un relais 
cambium c'est une facture de 6000 €, un relais ubiquiti c'est 1500 € ... 
c'est donc une question économique


Voili

Le 25/01/2016 15:36, David ALLARD a écrit :
  


Merci pour ces premières réponses.

Concernant l'usage, c'est à la
fois pour du PTP pour mailler le réseau et des AP pour que des usagers
se connectent dessus avec des antennes clients (CPE).

C'est surtout
lorsque je vois la différence de tarif pour ces deux types de matériels
que je me pose des questions.

Question complémentaire : Quelqu'un
a-t-il déjà géré une migration depuis une solution vers l'autre ?


Cordialement

David ALLARD
259 Route Départementale 813
82400
GOUDOURVILLE

Le 2016-01-25 15:16, Laurent MARTY a écrit :

Bonjour

Nous utilisons de l'ubiquiti en 5ghz et 2,4Gh sur des zones

blanches du

Gard, quelques centaines d'utilisateurs ... Pas de soucis

hors

interférences et orage.

Mais bon je pense qu'il n'y a pas

de bon / mauvais matériel : il y a

une utilisation conforme ou pas.

A bientôt

Le 25/01/2016 14:57, David ALLARD a écrit :


Bonjour, J'aimerais savoir si quelqu'un a déjà eu à comparer un réseau
hertzien fonctionnant avec du matériel Cambium et du matériel Ubiquiti.
C'est pour un réseau fournissant du "haut-débit" dans des zones
blanches. On me dit ( :-) ) que le premier c'est du matériel
professionnel qui marchera à tous les coups et le second un truc pas pro
du tout qui va pas marcher du tout. J'avoue être un peu paumé donc si
quelqu'un a des pistes merci d'avance David ALLARD
--- Liste de diffusion du FRnOG
http://www.frnog.org/ [1]
  


Links:
--
[1] http://www.frnog.org/

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


--
Laurent MARTY
Gérant
lma...@nostre-pais.net
Agence : +33(0)972 13 12 00


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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[Raphael Jacquot]

On 01/25/2016 03:36 PM, David ALLARD wrote:



Merci pour ces premières réponses.

Concernant l'usage, c'est à la fois pour du PTP pour mailler le réseau et



des AP pour que des usagers se connectent dessus avec des antennes clients 
(CPE).


c'est deux usages différents.
ubnt a justement les outils pour les 2

d'une part, toute une gamme de gamelles extérieures

d'autre part, des tout petits routeur / gateway / ap pour mettre a 
l'intérieur et faire borne wifi. (les airgateway)


c'est ce type de matériel qu'utilise pclight89


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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[frnog . kapush]

On lundi 25 janvier 2016 14:57:29 CET David ALLARD - david.allard@le-
palantir.com wrote:
> Bonjour,
> 
> J'aimerais savoir si quelqu'un a déjà eu à comparer un
> réseau hertzien fonctionnant avec du matériel Cambium et du matériel
> Ubiquiti. C'est pour un réseau fournissant du "haut-débit" dans des
> zones blanches.
> 
> On me dit ( :-) ) que le premier c'est du matériel
> professionnel qui marchera à tous les coups et le second un truc pas pro
> du tout qui va pas marcher du tout.
> 
> J'avoue être un peu paumé donc si
> quelqu'un a des pistes merci d'avance
> 
> David ALLARD

Bonjour David,

Je n'ai jamais pratiqué Cambium, mais concernant le matos ubiquiti 5GHz, 
contrairement à ce qu'on t'a dit ça fonctionne bien et c'est un prix bien plus 
abordable que la concurrence.

Du moment que les installations sont faites correctement, les performances 
sont au rendez vous. C'est probable que si tu essayes de mettre plusieurs 
centaines de clients simultanément sur le même point d'accès ça marche moins 
bien, il faut que tu vois en fonction de tes besoins.

Il y a quelques limitations, par exemple AirMax la fonction TDMA made in 
ubiquiti est propriétaire et rends impossible d'ajouter du matériel autre 
qu'ubiquiti quand elle est activée. 

Il y a parfois des petits bugs dans les firmwares, on a eu le cas  de DFS qui 
se déclenche inopinément et déconnecte une antenne du réseau, ou d'autres 
blagues de cet ordre mais rien d'insurmontable.

Du point de vue matériel ça fonctionne malgré la pluie, la neige, le vent, la 
glace, le soleil, la chaleur, on a eu une fois un CPE défectueux sur plusieurs 
centaines déployés.

Mon plus gros reproche c'est la communication qui laisse à désirer, les effets 
d'annonce, la manière dont a été géré le développement de leur logiciel de 
monitoring Aircontrol (un cas d'école de ce qu'il ne faut pas faire).

Au final, c'est vraiment moins cher qu'ailleurs, ça marche bien et avec 
l'économie budgétaire tu peux te permettre de prendre du spare en cas de 
panne.


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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[David ALLARD]

 

Oui j'ai vu au cours de mes recherches. 

Ainsi que Tetaneutral.


C'est parce que je trouve assez peu d'information sur Cambium que
j'interroge la liste de diffusion, car pour Ubiquiti on trouve beaucoup
d'exemples sur le Net, pour Cambium c'est plus light pourtant du
matériel professionel comme on me dit. :-) ce que je peux concevoir vu
les prix :-p 

Donc des retours d'expériences ça m'intéresse.


Cordialement 

David ALLARD 

Le 2016-01-25 16:47, Raphael Jacquot a
écrit : 

> On 01/25/2016 03:36 PM, David ALLARD wrote:
> 
>> Merci pour
ces premières réponses. Concernant l'usage, c'est à la fois pour du PTP
pour mailler le réseau et
> 
>> des AP pour que des usagers se
connectent dessus avec des antennes clients (CPE).
> 
> c'est deux
usages différents.
> ubnt a justement les outils pour les 2
> 
> d'une
part, toute une gamme de gamelles extérieures
> 
> d'autre part, des
tout petits routeur / gateway / ap pour mettre a 
> l'intérieur et faire
borne wifi. (les airgateway)
> 
> c'est ce type de matériel qu'utilise
pclight89
> 
> ---
> Liste de diffusion du
FRnOG
> http://www.frnog.org/ [1]
 

Links:
--
[1]
http://www.frnog.org/

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

Re: [FRnOG] [TECH] DNS TCP & UDP

[Alarig Le Lay]

On Mon Jan 25 14:38:35 2016, Julien Escario wrote:
> Intéressant. Du coup, pourquoi en passant par ton résolveur, ça ne marche pas
> (TCP ou UDP) ?

Le dernier résolvait, mais j’ai eu la flemme de copier toute la sortie,
j’ai remplacé par « blah. ».

-- 
alarig


signature.asc
Description: Digital signature

RE: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[Michel Py]

> David ALLARD a écrit :
> J'aimerais savoir si quelqu'un a déjà eu à comparer un réseau hertzien 
> fonctionnant avec du matériel Cambium et du matériel
> Ubiquiti. C'est pour un réseau fournissant du "haut-débit" dans des zones 
> blanches. On me dit ( :-) ) que le premier c'est
> du materiel professionnel qui marchera à tous les coups et le second un truc 
> pas pro du tout qui va pas marcher du tout. 

C'est pas parce que c'est cher que çà marche mieux. Perso je ne fais que de 
l'Ubiquiti, çà marche très bien pour moi.

Michel.


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

Re: [FRnOG] [TECH] DNS TCP & UDP

[Johan Fleury]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bonjour.

Le 25/01/2016 14:47, David Ponzone a écrit :
> J’ai eu une réponse moi:
> 

Je peux me planter, mais les requêtes ANY s’utilisent pour demander au 
résolveur le contenu de son cache : 
.

Lors de la première requête (dig www.ada.net.tr @localhost) le résolveur a 
complété son cache, et il a répondu à la seconde requête (dig ANY ada.net.tr 
@localhost) avec ce qu’il connaissait.

Je viens de valider chez moi :

# dig www.ada.net.tr @localhost
[réponse]

# dig ANY ada.net.tr @localhost
[réponse]

# unbound-control flush_zone ada.net.tr.
ok removed 4 rrsets, 3 messages and 0 key entries

# dig +short ANY www.ada.net.tr @localhost
;; connection timed out; no servers could be reached

Ça ne change rien au fait de ne pas répondre en TCP qui reste un comportement 
non valide (voir ).

- -- 
Johan Fleury
PGP Key ID : 0x7AB0F9C0F52C877B

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWpmFoAAoJEPnQcN/mWI+lIagP/iXHg6Z3w6aULZUDtK9FEUHj
fGVluBmxMDItKEq/wjB1Tfz2s49ZxNk65D8iTHKczhjmeRbB4rRrGIqmQpJn1I0G
N2Uw5wLba8SZySwsYRWKxqlysPes2tE2OF68+AiI8I9sF/QGJmaCi+kDBZXp1KdF
mi75KOm1KhPeceFkLBe+h7abzWciWM6Gc45H6yx49yOIoxDn5TxwNdVEgMXjTYnI
s4ItYnXw2vt6CqfbqFO4dM1hOxTZ4ZE5DKAHJuELk/ExtAPb2aw+HFNeDe7ZfnwG
W+oDDZ9nhLZOAoNz8+JvyDrKVQJwChQ+JBUniP3n1AsCEQ6un4AkOBOaMUg2XiPE
55PVSYrrGQazKGZCwHxbJxgnuBzHyWH9ObX7XAedlc/Yn6+qgk9TslIgZjobNxCk
PiARjp9OHTN1USINjp6g/GlZ7YDmsIHE5B2LnD/Zz9CayEvDOEAgw6/9wp0jh5pU
NQk+AWRxl58W3WIcxJ7VxI6ItHVJ3sP/hiaO6OikLFM7iujIvXssrKfkxFCMqsFD
dIMgdVHwPD1No+C4CHLD44jwWkBVBE6cWcMFKGOkUDpwVWAKbZcLxY0vVEEEGsXj
rmtul0eXRG4mJHwRlo1j2exmmezGqb+21fi9aKaV+fbwhnMfqaYCU+DiuZeVKRq+
LziIOR/qmODyy5Wrkpe+
=3P0V
-END PGP SIGNATURE-


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

Re: [FRnOG] [TECH] DNS TCP & UDP

[David Ponzone]

Oui tu as raison pour ANY, j’aurais du regardé avant.
Et oui, pas de réponse en TCP, plus qu’à faire un mail à hostmas...@ada.net.tr 
:)

> Le 25 janv. 2016 à 18:54, Johan Fleury  a écrit :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Bonjour.
> 
> Le 25/01/2016 14:47, David Ponzone a écrit :
>> J’ai eu une réponse moi:
>> 
> 
> Je peux me planter, mais les requêtes ANY s’utilisent pour demander au 
> résolveur le contenu de son cache : 
> .
> 
> Lors de la première requête (dig www.ada.net.tr @localhost) le résolveur a 
> complété son cache, et il a répondu à la seconde requête (dig ANY ada.net.tr 
> @localhost) avec ce qu’il connaissait.
> 
> Je viens de valider chez moi :
> 
> # dig www.ada.net.tr @localhost
> [réponse]
> 
> # dig ANY ada.net.tr @localhost
> [réponse]
> 
> # unbound-control flush_zone ada.net.tr.
> ok removed 4 rrsets, 3 messages and 0 key entries
> 
> # dig +short ANY www.ada.net.tr @localhost
> ;; connection timed out; no servers could be reached
> 
> Ça ne change rien au fait de ne pas répondre en TCP qui reste un comportement 
> non valide (voir ).
> 
> - -- 
> Johan Fleury
> PGP Key ID : 0x7AB0F9C0F52C877B
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWpmFoAAoJEPnQcN/mWI+lIagP/iXHg6Z3w6aULZUDtK9FEUHj
> fGVluBmxMDItKEq/wjB1Tfz2s49ZxNk65D8iTHKczhjmeRbB4rRrGIqmQpJn1I0G
> N2Uw5wLba8SZySwsYRWKxqlysPes2tE2OF68+AiI8I9sF/QGJmaCi+kDBZXp1KdF
> mi75KOm1KhPeceFkLBe+h7abzWciWM6Gc45H6yx49yOIoxDn5TxwNdVEgMXjTYnI
> s4ItYnXw2vt6CqfbqFO4dM1hOxTZ4ZE5DKAHJuELk/ExtAPb2aw+HFNeDe7ZfnwG
> W+oDDZ9nhLZOAoNz8+JvyDrKVQJwChQ+JBUniP3n1AsCEQ6un4AkOBOaMUg2XiPE
> 55PVSYrrGQazKGZCwHxbJxgnuBzHyWH9ObX7XAedlc/Yn6+qgk9TslIgZjobNxCk
> PiARjp9OHTN1USINjp6g/GlZ7YDmsIHE5B2LnD/Zz9CayEvDOEAgw6/9wp0jh5pU
> NQk+AWRxl58W3WIcxJ7VxI6ItHVJ3sP/hiaO6OikLFM7iujIvXssrKfkxFCMqsFD
> dIMgdVHwPD1No+C4CHLD44jwWkBVBE6cWcMFKGOkUDpwVWAKbZcLxY0vVEEEGsXj
> rmtul0eXRG4mJHwRlo1j2exmmezGqb+21fi9aKaV+fbwhnMfqaYCU+DiuZeVKRq+
> LziIOR/qmODyy5Wrkpe+
> =3P0V
> -END PGP SIGNATURE-
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] DNS TCP & UDP

[Romain De Rasse]

Bonjour,

D'ailleurs en cas d'absence de réponse après envois à l'adresse
hostmaster, y a-t-il d'autres choses qu'on puisse tenter ? Un soucis
avec free.fr / proxad.net depuis un préfixe en particulier.

[XXX]/(): dig +short ns proxad.net
ns1.proxad.net.
ns0.proxad.net.

[XXX]/(): dig +short ns0.proxad.net.
212.27.32.2

[XXX]/(): dig +short @212.27.32.2 ns1.proxad.net.
;; connection timed out; no servers could be reached

[XXX]/(): dig +short +tcp @212.27.32.2 ns1.proxad.net.
212.27.32.130

Romain

Le 25/01/2016 19:03, David Ponzone a écrit :
> Oui tu as raison pour ANY, j’aurais du regardé avant. > Et oui, pas de 
> réponse en TCP, plus qu’à faire un mail à
hostmas...@ada.net.tr :) > >> Le 25 janv. 2016 à 18:54, Johan Fleury
 a écrit : >>
> Bonjour.
>
> Le 25/01/2016 14:47, David Ponzone a écrit :
> >>> J’ai eu une réponse moi:
> >>>
>
> Je peux me planter, mais les requêtes ANY s’utilisent pour demander au
> résolveur le contenu de son cache :
> .
>
> Lors de la première requête (dig www.ada.net.tr @localhost) le
> résolveur a complété son cache, et il a répondu à la seconde requête
> (dig ANY ada.net.tr @localhost) avec ce qu’il connaissait.
>
> Je viens de valider chez moi :
>
> # dig www.ada.net.tr @localhost
> [réponse]
>
> # dig ANY ada.net.tr @localhost
> [réponse]
>
> # unbound-control flush_zone ada.net.tr.
> ok removed 4 rrsets, 3 messages and 0 key entries
>
> # dig +short ANY www.ada.net.tr @localhost
> ;; connection timed out; no servers could be reached
>
> Ça ne change rien au fait de ne pas répondre en TCP qui reste un
> comportement non valide (voir
> ).
>
>> >> >> --- >> 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] Questionnement sur du matériel radio 5GHz

[Bensay 1]

> on a eu le cas  de DFS qui 
> se déclenche inopinément et déconnecte une antenne du réseau, ou d'autres 
> blagues de cet ordre mais rien d'insurmontable.

Une certitude que c'était bien inopiné et non sur détection d'un radar ? 

Benjamin L

> Le 25 janv. 2016 à 17:00, frnog.kap...@antichef.net a écrit :
> 
> On lundi 25 janvier 2016 14:57:29 CET David ALLARD - david.allard@le-
> palantir.com wrote:
>> Bonjour,
>> 
>> J'aimerais savoir si quelqu'un a déjà eu à comparer un
>> réseau hertzien fonctionnant avec du matériel Cambium et du matériel
>> Ubiquiti. C'est pour un réseau fournissant du "haut-débit" dans des
>> zones blanches.
>> 
>> On me dit ( :-) ) que le premier c'est du matériel
>> professionnel qui marchera à tous les coups et le second un truc pas pro
>> du tout qui va pas marcher du tout.
>> 
>> J'avoue être un peu paumé donc si
>> quelqu'un a des pistes merci d'avance
>> 
>> David ALLARD
> 
> Bonjour David,
> 
> Je n'ai jamais pratiqué Cambium, mais concernant le matos ubiquiti 5GHz, 
> contrairement à ce qu'on t'a dit ça fonctionne bien et c'est un prix bien 
> plus 
> abordable que la concurrence.
> 
> Du moment que les installations sont faites correctement, les performances 
> sont au rendez vous. C'est probable que si tu essayes de mettre plusieurs 
> centaines de clients simultanément sur le même point d'accès ça marche moins 
> bien, il faut que tu vois en fonction de tes besoins.
> 
> Il y a quelques limitations, par exemple AirMax la fonction TDMA made in 
> ubiquiti est propriétaire et rends impossible d'ajouter du matériel autre 
> qu'ubiquiti quand elle est activée. 
> 
> Il y a parfois des petits bugs dans les firmwares, on a eu le cas  de DFS qui 
> se déclenche inopinément et déconnecte une antenne du réseau, ou d'autres 
> blagues de cet ordre mais rien d'insurmontable.
> 
> Du point de vue matériel ça fonctionne malgré la pluie, la neige, le vent, la 
> glace, le soleil, la chaleur, on a eu une fois un CPE défectueux sur 
> plusieurs 
> centaines déployés.
> 
> Mon plus gros reproche c'est la communication qui laisse à désirer, les 
> effets 
> d'annonce, la manière dont a été géré le développement de leur logiciel de 
> monitoring Aircontrol (un cas d'école de ce qu'il ne faut pas faire).
> 
> Au final, c'est vraiment moins cher qu'ailleurs, ça marche bien et avec 
> l'économie budgétaire tu peux te permettre de prendre du spare en cas de 
> panne.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [FRnOG] [TECH] Questionnement sur du matériel radio 5GHz

[frnog . kapush]

On lundi 25 janvier 2016 20:49:08 CET you wrote:
> > on a eu le cas  de DFS qui 
> > se déclenche inopinément et déconnecte une antenne du réseau, ou d'autres
> > 
> > blagues de cet ordre mais rien d'insurmontable.
> 
> 
> Une certitude que c'était bien inopiné et non sur détection d'un radar ? 
> 
> Benjamin L

En cas de doute, il suffit de lire le changelog du firmware d'après:

Version 5.5.2-Service Release (August 17, 2012)
--
*snip*
- Fix: Reduce false positives and misclassifications of invalid DFS radar 
events
*snip*




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

Re: [FRnOG] [MISC] test, pas de mail reçu depuis trop longtemps

[Bensay 1]

Plus sérieusement :

001
   (BLU004-MC1F17) Unfortunately, messages from 188.165.44.15 weren't sent.
   Please contact your Internet service provider since part of their network
   is on our block list. You can also refer your provider to
   http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL
   FROM command)

> Le 23 janv. 2016 à 07:10, jfollenf...@gmail.com a écrit :
> 
> Ca nous faisait des vacances
> 
> Envoyé de mon iPhone
> 
>> Le 23 janv. 2016 à 07:04, Tristan Mahé  a écrit :
>> 
>> Salut,
>> 
>> Petit test car je ne reçois plus les mails de la ML depuis 2jours...
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [FRnOG] [MISC] test, pas de mail reçu depuis trop longtemps

[Tristan Mahé]

De mon côté c'est résolu depuis ce matin ( PDT ), je pouvais émettre
vers la ML mais plus recevoir, rien dans les traces réseau sur le
firewall pendant 3jours...

Philippe, tu as relancé Sympa ? ;)

On 01/25/2016 01:35 PM, Bensay 1 wrote:
> Plus sérieusement :
>
> 001
>(BLU004-MC1F17) Unfortunately, messages from 188.165.44.15 weren't
> sent.
>Please contact your Internet service provider since part of their
> network
>is on our block list. You can also refer your provider to
>http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to
> MAIL
>FROM command)
>
> Le 23 janv. 2016 à 07:10, jfollenf...@gmail.com
>  a écrit :
>
>> Ca nous faisait des vacances
>>
>> Envoyé de mon iPhone
>>
>>> Le 23 janv. 2016 à 07:04, Tristan Mahé >> > a écrit :
>>>
>>> Salut,
>>>
>>> Petit test car je ne reçois plus les mails de la ML depuis 2jours...
>>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/



signature.asc
Description: OpenPGP digital signature