GuiGui's Show - Liens
Chez Numericable, avec un modem/routeur Netgear de 2011 (donc probablement le Netgear CG3100L), il est possible de s'enregistrer sur un serveur/proxy SIP externe perso avec Jitsi/Linphone (Ekiga peine parfois : il s'enregistre sans problème et se désinscrit aussitôt de sa propre volonté (« Erreur de transfert »...). Il est tout aussi possible d'émettre des appels. Tout ça fonctionne en WiFi et en filaire.

En revanche, au moindre appel entrant, BOOOM, la box reboot. Le reboot se produit pile-poil à la réception du message SIP INVITE. On remarque que le reboot désactive parfois le WiFi ou fait perdre la clé WPA2. Priceless. Attention, pour que cela se produise, il faut d'abord passer le NAT donc être un paquet d'une connexion existante (même IP source, même port source, même IP dest, même port dest), ça limite les dégâts possibles. ;)

On remarque que :
   * Ce comportement se produit uniquement si le serveur/proxy SIP écoute sur 5060, ce qui fait qu'il envoie des paquets UDP SIP avec sport=5060 ;

   * Ce comportement se produit uniquement avec SIPoUDP. Aucun problème avec SIPoTCP, même si le serveur/proxy écoute sur 5060 ;

   * La box ne répond pas à l'INVITE donc c'est vraiment l'INVITE entrant la cause du problème.

   * On remarque que ça concerne tout paquet arrivant avec sport=5060, peu importe son contenu. Même un paquet de bourrage fait planter la box. La seule condition est que ce paquet dépasse 1645 octets. Rien à voir avec la fragmentation puisque le paquet est fragmenté bien avant ce seuil. Ça sent le buffer overflow des familles.

Une recherche sur le web montre que c't'un problème connu : http://www.justneuf.com/forum/topic/126269-r%C3%A9gl%C3%A9-v%C3%A9rrouillage-de-certains-ports/ , http://www.netgear-forum.com/forum/index.php?showtopic=62375 , http://cablebox-news.com/forums/ne-peux-plus-recevoir-des-appels-voip-sur-un-client-sip-sur-pc-t1605.html , entre autres.

Cela vient de la SIP ALG du modem/routeur Netgear. En cherchant sur le web, on trouve des tonnes d’occurrences... Et Netgear est loin d'être le seul constructeur à avoir une SIP ALG défectueuse (voir http://www.voip-info.org/wiki/view/Routers+SIP+ALG )... C'quoi une SIP ALG, d'abord ? Sous Netfilter, on nomme ça un nat helper (ou juste helper) : ça inspecte un protocole donné connu pour avoir des problèmes avec le NAT car faisant transiter des informations de couche 3/4 en couche 7 (FTP, SIP, IRC,...) afin d'y récupérer les ports sur lesquels la communication va continuer/avoir lieu et ainsi de pouvoir laisser passer les nouvelles connexions qui auront lieu sur ces ports en les considérant relatives à une connexion principale déjà ouverte.

Aucune option dans la NCBox permet de virer la SIP ALG de Netgear donc pour avoir de la VOIP en état de marche, il reste : VPN ou changer le port d'écoute du serveur/proxy SIP ou passer en TCP ou, solution intéressante : restreindre la liste des codecs afin que l'offre SDP ne fasse pas exploser la taille du paquet SIP INVITE au-delà de 1645 octets.

Ce dernier point se fait côté serveur SIP. Exemple avec Asterisk : il faut ajouter ce qui suit dans sip.conf, section « general » (ou sur un peer SIP donné concerné par le problème) :
« disallow=all
allow=speex32
allow=speex16
allow=alaw
allow=ulaw »

Pour mettre ce problème amusant en évidence, il faut un compte SIP sur un serveur/proxy externe et on peut utiliser mon bout de Python pour générer des faux INVITE SIP : http://www.guiguishow.info/wp-content/uploads/2015/11/sipFakeINVITE.py
(Permalink)

GuiGui's Show - Liens
C'pas un scoop que tous les softs (parfois même le hardware, comme chez Cisco) de VOIP ont des soucis : segfault aléatoires (ekiga/jitsi), support IPv6 soit absent soit défaillant (linphone/jitsi), négociation des codecs qui donne parfois des résultats surprenants, les techniques pour contournement sont plus ou moins nombreuses (jitsi en implémente le plus, linphone se débrouille, ekiga est à la ramasse), sonneries/sons insupportables (la palme revient à linphone...), quand on refuse un appel avec ekiga, il en informe le correspondant mais continue de sonner...

Si je devais conseiller des logiciels :
   * CSipSimple (https://f-droid.org/repository/browse/?fdfilter=csipsimple&fdid=com.csipsimple) sur les ordiphones ;
   * Sur un desk/laptop sans NAT contraignant : Linphone > Jitsi > Ekiga. Sur des réseaux plein de NAT & co, Jitsi prend l'avantage. Même chose si vous voulez de la sécurité (SIPS (SIPoTLS) et ZRTP (chiffrement de bout en bout, comme OpenPGP pour les mails, d'ailleurs, c'est le même auteur derrière :P )).

Il y a un truc drôle à faire : forger des paquets SIP INVITE pour faire sonner, à tort, les softphones. Bon, s'ils sont planqués derrière un NAPT, ça va être limite impossible car, pour passer le NAPT, il vous faudra l'IP de leur serveur/proxy SIP + le port du serveur même si le port est standard (5060) et que le serveur peut se deviner vu la concentration des acteurs sur ce secteur mais ça augmente de beaucoup le nombre de combinaisons.

Dans ce domaine : le plus simple à berner est linphone, suivi d'ekiga puis jitsi.
   * Ekiga ne vérifie pas que l'INVITE est envoyé par le serveur/proxy SIP sur lequel on s'est enregistré (SIP fonctionne en UDP, par défaut donc on peut générer des paquets avec une IP source qui n'est pas la nôtre), ni qu'il y a une offre SDP (je vois mal comment un appel SIP peut avoir lieu sans s'échanger les infos (codecs, IP) qui permettront de setup les flux médias), ni l'id/domain de destination (si je m'enregistre toto@guiguishow.info, pourquoi un appel bidule@lala.exemple ou même bidule@guiguishow.info me serait destiné ?). Par contre, si une offre SDP est présente, les attributs doivent être conformes et la taille annoncée dans « Content-Length » doit être correcte.

   * Linphone ne vérifie pas que l'INVITE est envoyé par le serveur/proxy SIP sur lequel on s'est enregistré, ni qu'il y a une offre SDP ni l'id/domain de destination. S'il y a une offre SDP avec un « Content-Length: 0 », Linphone segfaulte ce qui laisse penser à un buffer overflow. La conformité des attributs SDP n'est pas vérifiée non plus.

   * Jitsi vérifie que le paquet provient bien du serveur/proxy SIP (IP/sport) \o/. Il ne vérifie ni qu'il y a une offre SDP, ni l'id/domain de destination (mais la vérification de la source suffit à éviter toutes les attaques passives et un attaquant actif aura mieux à faire qu'un fake call). S'il y a une offre SDP, la taille annoncée dans « Content-Length » doit être correcte mais les attributs ne sont pas vérifiés à ce stade. Jitsi vérifie la concordance du Call-ID et du paramètre « branch » (qui sert à marquer l'unicité d'une transaction SIP) de l'attribut « Via » pour détecter les boucles conformément aux RFC (si le Call-ID est repris dans le Via -> boucle).

   * Ces trois softphones "vérifient" le paramètre branch dont je viens de parler donc il faudra attendre (le temps que le softphone termine de décliner l'appel, on voit ça avec une capture réseau) entre deux rejeux... ou jouer des branch différents à chaque fois.

J'ai du mal à comprendre pourquoi 2/3 des softphones testés ne vérifient ni le « to » ni l'IP source du message, ce qui permet de se faire emmerder par des bots si l'on n'a pas de NAPT ni de firewall, ce qui est une grosse connerie, il est vrai...

Pour ceux que ça intéresse : mon bout de Python pour générer des faux INVITE SIP : http://www.guiguishow.info/wp-content/uploads/2015/11/sipFakeINVITE.py . Oui, des bouts de code aussi bancals, y'en a d'autres sur le net mais ceux que j'ai testé n'étaient pas KISS, ils avaient des erreurs de programmation empêchant leur exécution et ils ne permettaient pas de berner l'intégralité des 3 softphones sus-cités.
(Permalink)

GuiGui's Show - Liens
Une recherche sur le web met en évidence qu'on peut utiliser une ligne SIP sur un forfait Free Mobile... Sauf que ça marche pas chez moi.

Sur le forfait à 2€, en 4G, avec CSipSimple : la signalisation (SIP) fonctionne, le flux media sortant aussi (mon correspondant m'entend) mais le flux entrant ne passe pas (je n'entends pas mon correspondant). En regardant les détails, on voit que le correspondant récupère bien mon IP publique donc le problème vient d'un NAT ou d'un firewall.

Sur le forfait à 20€, en 4G, avec CSipSimple : tout fonctionne : signalisation et les deux flux medias.

Même serveur SIP dans les deux cas.

Il n'y a pas de double NAT sur le forfait à 2€ donc je penche pour un pare-feu qui bloque les flux RTP ou autre...
(Permalink)

Nekoblog.org :: Marque-pages
« Je savais que Jackson finirait par admettre regretter d'avoir fait le Hobbit. Mais si tôt, je ne m'y attendais pas » (https://twitter.com/FrancoisTheurel/status/667493703150346241)

Et http://www.theverge.com/2015/11/19/9764016/peter-jackson-the-hobbit-movies-terrible-explanation (via http://www.f.0x2501.org/s/?bdY61w)
(Permalink)

Nekoblog.org :: Marque-pages
(Permalink)

@jeekajoo links
Voilaaaaa la désobéissance s'organise de manière plus officielle.. pour faire face à cet état d’urgence climatique.

Venez nombreux.
(Permalink) (Profil)

Red Beard
L’association Net-Litiges.fr a pour objet d’informer les internautes sur la consommation en général et sur le net en particulier. Notre souhait est que chacun puisse trouver ici réponse à ses questions, mais aussi que les professionnels concernés puissent s’exprimer également.'
(Permalink) (Profil)

Red Beard
(Permalink) (Profil)

Les liens du Lapin Masqué
Parce qu'on a quand même des droits, et que ça serait bête de ne pas les utiliser...
(Permalink) (Profil)

Oros links
(Permalink) (Profil)

Les liens de Jim
WAOW! Randall Munroe (XKCD) nous refait un strip, qui se présente comme un petit jeu, mais est un OVNI bédé-esque. J'adore!

Edit: <3 Qu'on donne une médaille à ce type, qu'on lui érige des statues!

Et je remarque pour la première fois ce message dans le footer:

BTC 1FhCLQK2ZXtCUQDtG98p6fVH7S6mxAsEey

"""
We did not invent the algorithm. The algorithm consistently finds Jesus. The algorithm killed Jeeves.
The algorithm is banned in China. The algorithm is from Jersey. The algorithm constantly finds Jesus.
This is not the algorithm. This is close.
"""
(Permalink)

Nekoblog.org :: Marque-pages
C'est aussi ce que je me suis dit.
En tout cas, ils ont été traduit en français > http://www.kana.fr/produit/me-and-the-devil-blues/ (4 tomes, série terminée)
(Permalink)

Oros links
Translations of Chinese martial arts manuals
(Permalink) (Profil)

Riff's Links
(Permalink) (Profil)

Nekoblog.org :: Marque-pages
Une sauvegarde de l'article > https://justpaste.it/p7cv (via http://www.seven-ash-street.fr/links/?Hb3TaA)
(Permalink)

Nekoblog.org :: Marque-pages
Dommage qu'il n'y ait pas de sources pour les chiffres. Mais c'est tjrs intéressant à garder sous le coude.
(Permalink)

Nekoblog.org :: Marque-pages
(Permalink)

Veille technique
Awesome!
(Permalink)

Riff's Links
(Permalink) (Profil)

Shaarli de Marc
Juste une photo pour se rendre compte...
Le PLAYM-ART est le "tuning pour Playmobil", où les gens "modifient" foncièrement ces jouets, pour créer des "nouveaux modèles".

Des heures de travail pour une passion.

Voir donc ici : http://www.uchronys.com/galery/#page=albums/
et ici : http://www.bories.eu/playmofamily19/
(Permalink) (Profil)