Roberto Riggio wrote:
> Hi,
> 

Hi!

> i have a problem with a simple daemon that I'm writing (the problem
> is not happening on the x86 target).
> 

probably due to diff C libraries...

> Basically the piece of code that is creating the problem is the following:
> 
> #include <arpa/inet.h>
> 
> int main()
> {
>     struct sockaddr_in addr_1, addr_2, addr_3;
> 

      /*make sure the result isn't from uninit mem*/
      memset(&addr_1, 0, sizeof(struct sockaddr_in));
      memset(&addr_2, 0, sizeof(struct sockaddr_in));
      memset(&addr_3, 0, sizeof(struct aockaddr_in));

>     addr_1.sin_addr = inet_makeaddr(127, 1);
>     addr_2.sin_addr = inet_makeaddr(0, 0);
>     addr_3.sin_addr.s_addr = INADDR_ANY;
> 

man inet_makeaddr:

### Begin ########################
inet_lnaof(), inet_netof(), and inet_makeaddr()  are  legacy  functions
that assume they are dealing with classful network addresses.  Classful
networking divides IPv4 network addresses into host and network  compo-
nents at byte boundaries, as follows:
...
Classful network addresses are now obsolete, having been superseded  by
Classless  Inter-Domain  Routing  (CIDR),  which divides addresses into
network and host components at arbitrary bit (rather than byte)  bound-
aries.
### End ##########################

I suspect the target C library thinks inet_makeaddr() is legacy.
Is there a reason you need to use inet_makeaddr() vice inet_aton()?

>     printf("Server (1), binded to %s\n",inet_ntoa(addr_1.sin_addr));
>     printf("Server (2), binded to %s\n",inet_ntoa(addr_2.sin_addr));
>     printf("Server (3), binded to %s\n",inet_ntoa(addr_3.sin_addr));
> 
>     return 0;
> }
> 
> the output of this code on an ixp4xx target is the following:
> 
> Server (1), binded to 0.0.133.112
> Server (2), binded to 0.0.133.112
> Server (3), binded to 0.0.0.0
> 
> While it should be 127.0.0.1 on the first case and 0.0.0.0 on the second
> and the third cases.
> 

My guess is uncleared memory and inet_makeaddr() failing.  If you can use 
inet_aton(), do so and check the return value.

hth,

Jason.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to