Re: Retrieving MAC address from struct ifnet

Mouse <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
> I am trying to read MAC address of network interface in kernel from
> member of struct ifnet: [...]

> When I try to cycle through interfaces and I read first member of
> if_hwdl (struct sockaddr *ifa_addr) the result for ethernet is:

> sa_family: 18, sa_len: 17,
> sa_data: 01 00 06 03 06 00 77 6D 30 F0 DE F1 8F AD EB 00 00

That looks reasonable.  Family AF_LINK, length 17:
sdl_index = 1 (if you're on a LE CPU) or 256 (if BE)
sdl_type = 6 = IFT_ETHER
sdl_nlen = 3
sdl_alen = 6 (as expected for IFT_ETHER)
sdl_slen = 0
sdl_data:
	77 6d 30 = ASCII for "wm0" (sdl_nlen octets long)
	f0 de f1 8f ad eb = MAC of wm0
	00 00 = memory beyond the end of the struct sockaddr_dl
		(I suspect you're treating sa_len as the length of
		sa_data, whereas it's actually the length of the whole
		sockaddr, including sa_len and sa_family.)

> and the result for wireless is:

> sa_family: 18, sa_len: 18,
> sa_data: 02 00 06 04 06 00 69 77 6E 30 08 11 96 52 DA 90 00 00

This one is AF_LINK, length 18:
sdl_index = 2 (LE) or 512 (BE)
sdl_type = 6 (IFT_ETHER)
sdl_nlen = 4
sdl_alen = 6 (as expected for IFT_ETHER)
sdl_slen = 0
sdl_data:
	69 77 6E 30 = ASCII for iwn0 (sdl_nlen octets long)
	08 11 96 52 da 90 00 00 = MAC of iwn0
	00 00 = memory beyond end, as above

> How can I reliably retrieve index of first byte of these MAC
> addresses ?

It begins sdl_nlen octets into sdl_data.  (I'm not aware of anywhere
this is documented except the code, but it's entirely possible there's
something I just haven't seen.)

In the versions I use, there's a macro, LLADDR, which takes a struct
sockaddr_dl * and returns a pointer to the first octet of its
link-layer address.  It returns char * (IMO it should be unsigned char
*, but they didn't ask me).  There's also CLLADDR, which is the same
except it returns a const char * instead of a char *.  I can't easily
check -current, because HTTP access to cvsweb has been broken; it now
insists on trying to ram HTTPS down my throat.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.