SendTo : Permission denied

**kyrillos52** · 06/06/2011, 10h45

Bonjour,

J'ai développé un petit programme en C++ sur un système Linux embarqué et j'ai le message d'erreur suivant lors de l'exécution : sendto(): Permission denied et je n'arrive pas à comprendre pourquoi

Voici une partie du code source avec le sendto :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
void sendUDPBroadcast(char * command) {
	SOCKET			maSocket;
	SOCKADDR_IN		serverAddr;
	int				sent;
	bool			tmpBool;
	BYTE			*sendBuffer;
	//char			*stringBuffer;
	USHORT			bufferSize;
	SOCKET csock;
	socklen_t recsize = sizeof(serverAddr);
	int sock_err;
 
	maSocket=socket(AF_INET, SOCK_DGRAM, 0);
	if (maSocket == INVALID_SOCKET) {
		goto EndFunction;
	}
 
	if(bind(maSocket, (SOCKADDR *) &serverAddr, sizeof serverAddr) == SOCKET_ERROR)
	{
		perror("socket()");
		exit(errno);
	}
 
	serverAddr.sin_family = AF_INET;   // famille INET (internet)
	serverAddr.sin_addr.s_addr = inet_addr("255.255.255.255"); // on broadcaste à tout le monde
	serverAddr.sin_port = htons(2152);	// numero du port du PC SERVEUR, htons convertit
 
	tmpBool=true;
	setsockopt(maSocket, SOL_SOCKET, SO_BROADCAST, (const char *)&tmpBool, sizeof(tmpBool));
 
	encryptString(command, &sendBuffer, &bufferSize);
 
	decryptString(sendBuffer, &test);
 
	if (sendto(maSocket, (const char *)sendBuffer, bufferSize, 0, (SOCKADDR*)&serverAddr, sizeof(serverAddr)) < 0)
	{
		perror("sendto()");
		exit(errno);
	}
 
	free(sendBuffer);
	closesocket(maSocket);
 
 
	EndFunction:;
}

J'espère que vous aurez des pistes pour résoudre ce problème

**ram-0000** · 06/06/2011, 11h16

En lisant le man de sendto(), il renvoie le nombre de caractères émis, ou -1 s'il échoue, auquel cas errno contient le code d'erreur.

J'ai peut que ton test ne soit mauvais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (sendto(maSocket, (const char *)sendBuffer, bufferSize, 0, (SOCKADDR*)&serverAddr, sizeof(serverAddr)) != bufferSize)
{
	perror("sendto()");
	exit(errno);
}

**kyrillos52** · 06/06/2011, 13h35

Envoyé par ram-0000

En lisant le man de sendto(), il renvoie le nombre de caractères émis, ou -1 s'il échoue, auquel cas errno contient le code d'erreur.

J'ai peut que ton test ne soit mauvais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (sendto(maSocket, (const char *)sendBuffer, bufferSize, 0, (SOCKADDR*)&serverAddr, sizeof(serverAddr)) != bufferSize)
{
	perror("sendto()");
	exit(errno);
}

Merci de ta réponse, j'ai remplacé ta portion de code par le suivant mais l'erreur reste la même malheureusement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
if (sendto(maSocket, (const char *)sendBuffer, bufferSize, 0, (SOCKADDR*)&serverAddr, sizeof(serverAddr)) < 0)
	{
		perror("sendto()");
		exit(errno);
	}

**gangsoleil** · 07/06/2011, 15h23

Bonjour,

Ca ne serait pas un simple probleme de droit Unix ? Que se passe-t-il si tu executes ton programme en root ?

**kyrillos52** · 14/06/2011, 15h42

Envoyé par gangsoleil

Bonjour,

Ca ne serait pas un simple probleme de droit Unix ? Que se passe-t-il si tu executes ton programme en root ?

J'ai pensé à ce problème. Malheureusement, même en root, le problème reste identique.

**Obsidian** · 14/06/2011, 20h05

C'est très subtil mais si, à la ligne 6, tu remplaces « bool tmpBool » par « int tmpBool », ça marchera mieux. Tu risques de rencontrer une autre erreur (comme Bad Adress) mais tu auras résolu, en principe, le problème qui nous occupe ici.

**skeud** · 15/06/2011, 07h52

ça peut paraitre con ce que je vais dire mais le probleme ne viendrait pas de l'addresse? (255.255.255.255) normalement l'addresse de broadcast en local c'est pas 192.168.0.255? (192.168.0 dépend de la configuration réseaux bien sur), si je me souviens bien de mes cours, pour l'addresse de broadcast c'est juste le hostid qu'on met a 255, pas le reste?

**ram-0000** · 15/06/2011, 08h34

C'est par forcément idiot.

Il existe 2 broadcast :

Le broadcast local (avec les bit du HostId à 1 ==> 192.168.0.255 par exemple). Ce broadcast est diffusé sur le réseau local et ne va pas plus loin.
Le broadcast que j’appellerais général (tous les bits à 1 ==> 255.255.255.255). Normalement, ce broadcast général n'est pas routé et ne devrait pas franchir le premier routeur sauf configuration explicite (UN DHCP request est envoyé à 255.255.255.255 et si le serveur DHCP est sur un autre réseau, il faut bien qu'il soit acheminé par un routeur).

Peut être que ta pile IP refuse d'envoyer un paquet @255.255.255.255 pour ne pas flooder le réseau avec le message d'erreur "permission denied"

**fregolo52** · 15/06/2011, 08h48

Je connais mal Linux et ce n'est pas moi qui avait configuré le système. Je me souviens qu'il fallait faire des choses sous Linux pour autoriser le multicast, c'est peut-être pareil pour le broadcast ?

**skeud** · 15/06/2011, 08h52

Pour le broadcast general je trouve sa un peu bizarre, en gros sa serait un paquet qui part d'une machine, traverse le premier routeur du reseaux puis se demultiplie a chaque reseaux pour aller sur tout les routeur et toutes les machine, en gros sa serait un super paquet qui parcourerait la terre entiere

Je trouve sa un peu gros pour que sa soit autoriser

Je pense qu'il faudrait revoir l'utilité d'envoyer un paquet a tout le monde (sauf pour envoyer un super virus qui irait sur toute la terre entière

)
Le but de ce sendto est de faire quoi?

**ram-0000** · 15/06/2011, 09h08

Envoyé par skeud

Pour le broadcast general je trouve sa un peu bizarre, en gros sa serait un paquet qui part d'une machine, traverse le premier routeur du reseaux puis se demultiplie a chaque reseaux pour aller sur tout les routeur et toutes les machine, en gros sa serait un super paquet qui parcourerait la terre entiere

Je trouve sa un peu gros pour que sa soit autoriser

C'est le fonctionnement de certains protocoles.

Au boot d'une machine DHCP, la machine ne connait pas son adresse IP ni l'adresse du serveur DHCP (puisqu'elle n'a pas de configuration réseau). Elle envoie donc un paquet DHCP request à 255.255.255.255.

Après, effectivement, c'est dangereux de router un tel paquet, il faut savoir ce que l'on fait et autorise. Ceci dit, je te rassure, aucun routeur d'Internet n'accepte ce paquet, il sera purement et simplement ignoré.

**skeud** · 15/06/2011, 09h22

Envoyé par ram-0000

Après, effectivement, c'est dangereux de router un tel paquet, il faut savoir ce que l'on fait et autorise. Ceci dit, je te rassure, aucun routeur d'Internet n'accepte ce paquet, il sera purement et simplement ignoré.

Ah ouf pendant un moment j'ai eu un peu peur, pauvre naif que je suis

En meme temps si il y a du reseaux dans sont application, soit c'est du local et 255.255.255.255 c'est pas bon soit c'est du distant et 255.255.255.255 n'est pas bon non plus

je pense qu'il faudrait qu'il revoit la conception de son archi reseaux pour savoir ou envoyer le paquet

**Obsidian** · 15/06/2011, 12h18

Je développe un peu plus mon commentaire numéro 6.

Les adresses 255.255.255.255 vont effectivement poser problème un peu plus loin mais dans le cas qui nous occupe immédiatement, c'est le bool qui provoque le bug :

kyrillos52 utilise une adresse de broadcast ;
Les sockets doivent être explicitement paramétrés pour ce faire (avec setsockopt) ;
setsockopt() est bien appelé mais le code de retour n'est pas vérifié ;
Quand on vérifie ce code de retour et que l'on ajoute perror("setsockopt"), on obtient
Code : Sélectionner tout - Visualiser dans une fenêtre à part
```
setsockopt: Invalid argument
```
« Invalid argument » correspond à EINVAL. La man page est claire à ce sujet :

EINVAL optlen invalid in setsockopt(). In some cases this error can also occur for an invalid value in optval (e.g., for the IP_ADD_MEMBERSHIP option described in ip(7)).
La plupart des options de socket, surtout quand elles ne sont pas explicitement décrites dans leur man page, attendent un booléen ;
setsockopt() est écrite en C ;
bool est du C++, ou du C99 si <stdbool.h> a été inclus ;
Dans les deux cas, la norme spécifie que bool ou _Bool doit être assez grand pour stocker 0 ou 1. Sous GCC, un sizeof (bool) ou sizeof(_Bool) vaut 1 ;
setsockopt() n'est pas au courant de ces détails et, pour elle, un booléen, c'est un int ordinaire ;
Comme setsockopt() utilise un pointeur void * pour recevoir des arguments de différents types en fonction de l'option mise en œuvre, elle ne peut vérifier la validité de ce qu'on lui passe, mais peut au moins contrôler le fait que sa taille indiquée soit bien celle attendue. Ne serait-ce que pour aller lire la donnée sans risquer la segfault ;
Comme un int fait généralement quatre octets mais jamais un seul en tout cas, ça suffit à faire échouer l'appel ;
Passer un booléen bool sur les autres appels fonctionne en général correctement car il y a un prototype explicite qui spécifie que l'argument est un int et la conversion est donc automatique.

Moralité : remplacer « bool tmpBool » par « int tmpBool ».

Ensuite, je pense qu'effectivement, le noyau ne te laissera plus broadcaster vers tous les sous-réseaux à la fois (255.255.255.255) et il semblerait que ce soit désormais la politique de Windows 7, également, mais je n'arrive pas encore à en trouver la trace officielle dans la doc.

**orfix** · 16/06/2011, 01h52

Envoyé par ram-0000

<...>

Le broadcast que j’appellerais général (tous les bits à 1 ==> 255.255.255.255). Normalement, ce broadcast général n'est pas routé et ne devrait pas franchir le premier routeur sauf configuration explicite (UN DHCP request est envoyé à 255.255.255.255 et si le serveur DHCP est sur un autre réseau, il faut bien qu'il soit acheminé par un routeur).

<...>

Un limited broadcast (255.255.255.255) n'est jamais retransmis par un routeur, peut importe la configuration.

Pour ce qui est de l'exemple du DHCP_REQUEST que vous citez, le serveur DHCP ne recevra même pas le DHCP_DISCOVER et donc encore moins le DHCP_REQUEST, dans ce type de réseau, où les clients et les serveurs DHCP ne sont pas sur le même sous-réseau on utilise des relais DHCP, ces derniers transforme donc les messages DHCP broadcast des clients en unicast vers le ou les serveurs DHCP.

**kyrillos52** · 20/06/2011, 09h07

Merci pour toutes vos réponses.

Effectivement, le fait de passer du bool à int à résolu le problème, du moins, il n'y a plus le message d'erreur.

Je vérifie si la trame est bien envoyé sur le réseau et je vous tiens au courant.

SendTo : Permission denied

Réseau C

Discussions similaires

Partager

Partager