Application can't find out the NICs in K2.6

[frater]

A bunch of programs are failing on the k26 implementation on DD-WRT. Most here just say these programs were not written for k26 and need a different implementation. Although this is true for 'modutils' it isn't for net-tools-ifconfig, xinetd, samba, twonky and ushare.

The common factor seems to be the inability of these programs to fetch a list of the networks used on DD-WRT's k26. I have another mips k26 device (a Playon!HD) and these same programs (same binaries) do not fail there...

Playon!HD's strace ​http://pastebin.com/d10075511

DD-WRT's strace: ​http://pastebin.com/f3f3fc2b1

DD-WRT fails here (only lo is named as device...)

ioctl(4, 0x8912, {108, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"", {AF_UNSPEC, "\303\177x\215\303\177\0\0\0\0\0\0\0\0"}}, {"", {AF_UNSPEC, "\0\0\v\0\0\0\10\0\0\0\217\0\0\0"}}}}) = 0
ioctl(4, 0x8913, {ifr_name="", ???})    = -1 ENODEV (No such device)

The playon!HD (k26) has this there...

ioctl(4, 0x8912, {64, {{"eth0", {AF_INET, inet_addr("192.168.10.70")}}, {"lo", {AF_INET, inet_addr("127.0.0.1")}}}}) = 0

And DD-WRT's k24 has this:

ioctl(4, 0x8912, {96, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"br0", {AF_INET, inet_addr("192.168.4.10")}}, {"br0:0", {AF_INET, inet_addr("169.254.255.1")}}}}) = 0

ioctl is only failing on DD-WRT's K26

[n3IVI0]

Awesome! Glad you've identified the problem. Here's hoping one of the devs jumps on this and fixes. Seems like a pretty serious bug to me...

[marto12]

Alright, I think the source of the problem is in the different definition of the struct "ifreq" in the if.h header file. For some reason in the dd-wrt's K26 if.h file the definition is the following:

struct ifreq 
{
#define IFHWADDRLEN	6
	union
	{
		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
	} ifr_ifrn;
	
	union {
		struct	sockaddr ifru_addr;
		struct	sockaddr ifru_dstaddr;
		struct	sockaddr ifru_broadaddr;
		struct	sockaddr ifru_netmask;
		struct  sockaddr ifru_hwaddr;
		short	ifru_flags;
		int	ifru_ivalue;
		int	ifru_mtu;
		struct  ifmap ifru_map;
		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
		char	ifru_newname[IFNAMSIZ];
		void __user *	ifru_data;
		struct	if_settings ifru_settings;
		struct {
			__u16 weight;
			char slave[IFNAMSIZ];	
		} ifru_weight;

	} ifr_ifru;
};

and in kernel.org's k26.23.17 if.h the definition is:

struct ifreq 
{
#define IFHWADDRLEN	6
	union
	{
		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
	} ifr_ifrn;
	
	union {
		struct	sockaddr ifru_addr;
		struct	sockaddr ifru_dstaddr;
		struct	sockaddr ifru_broadaddr;
		struct	sockaddr ifru_netmask;
		struct  sockaddr ifru_hwaddr;
		short	ifru_flags;
		int	ifru_ivalue;
		int	ifru_mtu;
		struct  ifmap ifru_map;
		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
		char	ifru_newname[IFNAMSIZ];
		void __user *	ifru_data;
		struct	if_settings ifru_settings;
	} ifr_ifru;
};

In older versions of dd-wrt we have:

129 struct ifreq  
130 { 
131 #define IFHWADDRLEN     6 
132         union 
133         { 
134                 char    ifrn_name[IFNAMSIZ];            /* if name, e.g. "en0" */ 
135         } ifr_ifrn; 
136          
137         union { 
138                 struct  sockaddr ifru_addr; 
139                 struct  sockaddr ifru_dstaddr; 
140                 struct  sockaddr ifru_broadaddr; 
141                 struct  sockaddr ifru_netmask; 
142                 struct  sockaddr ifru_hwaddr; 
143                 short   ifru_flags; 
144                 int     ifru_ivalue; 
145                 int     ifru_mtu; 
146                 struct  ifmap ifru_map; 
147                 char    ifru_slave[IFNAMSIZ];   /* Just fits the size */ 
148                 char    ifru_newname[IFNAMSIZ]; 
149                 char *  ifru_data; 
150                 struct  if_settings ifru_settings; 
151         } ifr_ifru; 
152 }; 

Perhaps there was a good reason for adding the ifru_weight in the ifreq structure, but this made all programs compiled with the original if.h nonfunctional.

[cfritzius]

Any update on this one? It would be great if this could be fixed. What can we do to move this along?

[zoomlink]

Devs: Please take a look at this issue. I has been outstanding for over 6 months and has gotten no response from you.

We just want to understand what we need to do to get this fixed so that Optware's ifconfig works the right way and when you enter 'netstat -i' you get back information about the network interfaces.

This is causing all media sharing programs such as Twonky, Ushare and others to blow up and not work. Please Please Please take a look at this.

[Kong]

Apps that are not compiled with dd-wrt toolchain, or a compatible toolchain are not supported.