segfault

[TKR-US]

Bonjour,

J'ai sur la dernière version un problème de crash coté serveur pour l'instant. C'est arrivé 2 fois déjà à quelques jours d'intervalle.

Jan 18 07:25:49 vpnssh kernel: mlvpn[4298]: segfault at 738aa02cc000 ip 000064957ca4960f sp 0000738aa02c8c78 error 4 in libsodium.so.13.0.2[64957ca39000+50000] Jan 18 07:25:49 vpnssh kernel: grsec: Segmentation fault occurred at 0000738aa02cc000 in /usr/sbin/mlvpn[mlvpn:4298] uid/euid:1000/1000 gid/egid:100/100, parent /usr/sbin/mlvpn[mlvpn:4282] uid/euid:0/0 gid/egid:0/0

une idée?

[TKR-US]

je vois sur ma console, coté client, ce type de messages: 2015 Jan 18 08:57:31 routeur Can't encrypt packet too long. Received: 1527 Max: 1516 2015 Jan 18 10:35:04 routeur Can't encrypt packet too long. Received: 1497 Max: 1516 2015 Jan 18 11:21:20 routeur Can't encrypt packet too long. Received: 1527 Max: 1516 2015 Jan 18 11:21:20 routeur Can't encrypt packet too long. Received: 1527 Max: 1516 2015 Jan 18 11:39:30 routeur Can't encrypt packet too long. Received: 1497 Max: 1516 2015 Jan 18 12:43:52 routeur Can't encrypt packet too long. Received: 1497 Max: 1516

je ne sais pas si c'est lié, mais au cas ou...

[zehome]

Merci de re-ouvrir si ça reproduit sur la version 2.0.7 ou supérieur

[TKR-US]

J'ai refais un git clone complet de la branche ev pour etre sur.. mais je ne vois pas la différence j'ai toujours ces messages d'erreurs.

Pour info j'ai (avant cette nouvelle install), plusieurs coupures par jour j'ai mis des scripts pour reconnecter automatiquement du coup.

[zehome]

Ok, dans ce cas le mieux serait que je regarde cette installation directement. Si tu peux me fournir les informations pour m'y connecter en SSH par email, je regarderais ça

[TKR-US]

Cette solution n'est pas possible. Dis moi ce que je peux faire pour t'aider, s'il existe un mode verbose particulier, ou me fournir une version spécial verbose... Peut etre un problème de la lib sodium? j'utilise la version 1.0.0

Je souhaite sincèrement avancer sur ce problème, les coupures répétées sont assez contraignantes

[zehome]

ok je vais voir ce que je peux essayer de te faire diag.

[zehome]

bon j'ai trouvé comment reproduire ce problème. C'est un soucis de MTU comme je suspectais, mais je fixer de toute façon afin que cela ne crash plu.

[zehome]

Je viens de commiter quelques patchs qui devraient régler le problème.

[TKR-US]

ok je vais tester, je verrais le resultat assez rapidement.

[TKR-US]

le md5sum de mlvpn est différent, donc la mise a jour s'est bien faite. Après quelques minutes, j'ai déjà les erreurs 2015 Feb 28 09:22:15 routeur Can't encrypt packet too long. Received: 1497 Max: 1516

mlvpn -V mlvpn version ev-6ed2fe1

Après si la correction empeche le crash... cela m'arrange ^^

[zehome]

J'ai trouvé d'autre ennuis dans le système d'authentification et dans la vérification des paquets reçus bien trop laxe. Je suis en train de programmer les correctifs.

[zehome]

bon si tu met a jour la branch ev a nouveau et recompile, tu devrais avoir de jolis messages au lieu de divers crash.

[zehome]

et je viens de pousser la release 2.0.9 avec encore un correctif sur la gestion de la MTU. Regarde bien le script updown fourni dans la documentation pour les explications sur les réglages de la MTU:

https://github.com/zehome/MLVPN/blob/ev/doc/examples/mlvpn_updown.sh.in

En gros, si tu fais du pppoe + chiffrement, il faut mettre 1432 ou moins.

[TKR-US]

hello. Je viens de mettre a jour. J'etais avant a 1400 en raison justement des erreurs / plantages. Je suis passé 1432, on va voir. Du coup j'explose les débits, ce que je n'avais plus depuis un certain temps en raison des 1400 justement.

J'ai fais quelques tests de saturation de lien, et je n'ai pas vu d'erreur. J'ai enlevé mes scripts de detection de crash du process, on va voir ces prochains jours.

Merci en tout cas, ce fut un peu long, mais le résultat est la ^^ bravo!

[TKR-US]

un truc qui manque quand même, c'est l'horodatage des évènements dans le log. ce serait possible de l'avoir dans une prochaine mise à jour?

[zehome]

le log est réalisé fait via syslog, qui horodate. le log "console" est horodaté aussi depuis la version 2.0.9.

Peut être tu parle du log du script updown.sh ? dans ce cas un bête "date" juste avant de lancer les commandes devrait suffir?

[TKR-US]

je parle du log /var/log/mlvpn_commands.log afin de savoir quand une connexion est tombée, et au bout de combien de temps elle est remontée

[zehome]

oui ok dans ce cas rajoute juste la commande "date" après la première parenthèse ouvrante

[TKR-US]

donc oui :)

[TKR-US]

je soupçonne un soucis, il indique quand je suis en pleine charge des pertes des ADSL (1 et / ou 2) toutes les 5/10 minutes alors que mes connections sont bien up. Du coup la connexion est assez instable à cause de ces coupures. As tu vu quelque chose de semblable?

[zehome]

non, mais je vais regarder

[zehome]

Juste comme ça, ton timeout est réglé sur quelle valeur?

[TKR-US]

il n'y a pas de timeout de reglé, donc c'est la valeur par defaut du programme..

connection hyper instable :( lundi 2 mars 2015, 13:35:26 (UTC+0100) MLVPN informed me rtun [adsl1] is up lundi 2 mars 2015, 13:35:57 (UTC+0100) MLVPN informed me rtun [adsl1] is down. lundi 2 mars 2015, 13:35:59 (UTC+0100) MLVPN informed me rtun [adsl1] is up lundi 2 mars 2015, 13:45:25 (UTC+0100) MLVPN informed me rtun [adsl2] is down. lundi 2 mars 2015, 13:45:26 (UTC+0100) MLVPN informed me rtun [adsl2] is up lundi 2 mars 2015, 13:45:57 (UTC+0100) MLVPN informed me rtun [adsl2] is down. lundi 2 mars 2015, 13:45:59 (UTC+0100) MLVPN informed me rtun [adsl2] is up lundi 2 mars 2015, 13:51:29 (UTC+0100) MLVPN informed me rtun [adsl2] is down. lundi 2 mars 2015, 13:51:30 (UTC+0100) MLVPN informed me rtun [adsl2] is up lundi 2 mars 2015, 13:52:01 (UTC+0100) MLVPN informed me rtun [adsl2] is down. lundi 2 mars 2015, 13:52:03 (UTC+0100) MLVPN informed me rtun [adsl2] is up lundi 2 mars 2015, 14:15:10 (UTC+0100) MLVPN informed me rtun [adsl1] is down. lundi 2 mars 2015, 14:15:11 (UTC+0100) MLVPN informed me rtun [adsl1] is up lundi 2 mars 2015, 14:15:42 (UTC+0100) MLVPN informed me rtun [adsl1] is down. lundi 2 mars 2015, 14:15:44 (UTC+0100) MLVPN informed me rtun [adsl1] is up

[TKR-US]

pardon... je viens de voir, coté serveur ADSL, il est de 30 secondes. Aggregation très instable en ce moment en raison d'une utilisation de la bande passante non negligeable

[zehome]

Ok, je viens de trouver quelque erreurs, j'ai aussi fais quelque améliorations dans le script de commandes (mlvpn_updown.sh) pour l'horodatage, ainsi que l'ajout de routes par exemple.

J'ai modifié le protocole pour l'envoi de keepalive toute les 2 secondes, quelque soit le timeout

[zehome]

je t'invite donc a tester le tag 2.0.10

[TKR-US]

c'est installé.

J'ai remarqué que mon upload était à 99ko, soit la valeur environ de 1 ADSL full.. et une horreur pour le reste, ping pourri, impossible de faire quoique ce soit.. j'attends les premiers résultats pour te dire

[TKR-US]

pour l'horodatage, moi j'ai juste mis: DATE=date echo -n $DATE

:p

[TKR-US]

avec les "``"

[TKR-US]

question qui n'a rien a voir.. tu dev avec quoi comme soft en C ?

[zehome]

vim, et sublime text de temps en temps

[zehome]

si tu veux discuter hésite pas a venir sur IRC, freenode je suis "ed"

[TKR-US]

Bilan de la nuit: pas de coupure, c'est quand même bien mieux ^^

Je vais essayer de me pencher sur les montées en charge ces prochains jours

Merci!

[TKR-US]

hello,

je voudrais que tu testes de ton coté quelque chose, a voir si tu as le meme constat, et si tu penses qu'une amélioration est possible.

Les débits sont très performants quand tu prends 1 machine sur 1 fichier. Par contre quand tu as plusieurs machines qui requêtent, le débit tombe complètement. Pour moi le débit est divisé par au moins 2, au minimum. Un avis?

[zehome]

non je suis désolé je ne sais pas dutout. Je n'ai pas ce problème