I wonder why illumos is the only OS (as far as I managed to test, anyway) that implements getifaddrs() and for Ethernet interfaces returns AF_LINK addresses with sdl_type set to 0 instead of IFT_ETHER

is there any explanation why this would be the intended behaviour?

Feels more likely just a bug?

from my point of view, yes, but I decided to ask first

I'm just looking at the source and there's nothing obvious there.

Support for AF_LINK was added relatively recently to getifaddrs().

I know how it feels

It wasn't immediately in the information we were grabbing to fill in that field.

It was set on the ifi_type for that case on the higher level ifaddr structure.

does the kernel have enough internal information about the interfaces to derive sdl_type from?

So I think it'd likely be a similar operation here.

Yeah, it should

We do when getting it from other ways, but getifaddrs() isn't a kernel thing.

It's just going through info from different sources.

I do not know if illumos implements SIOCGIFTYPE, but that in theory should feed from the same internal interface type

I mean, we have this info in the ifi_type, so it should just be another assignment, if I'm reading this correctly.

We don't have anything by that name (but neither does FreeBSD).

I suppose at least IFT_ETHER and IFT_LOOP from /usr/include/net/if_types.h should have a purpose

although for the loopback getifaddrs() does not return an AF_LINK address

That's correct because there is no layer 2 address for it.

alright, I am opening a bug report then?

Sure. If you do, let me know and I can add some more specifics. Or I can write something up.

would "lib" or "networking" be the correct category?

Either is fine. Don't sweat it.

I'm going to have to step afk, so leave me a note of the bug id and I can add more specifics about whta's required to be filled in.

Though I do wonder if it would be better to try libdlpi here, though that's probably more of a pain.

rmustacc: illumos.org/issues/16383

→ BUG 16383: getifaddrs() returns AF_LINK addresses with sockaddr_dl.sdl_type == 0 (New)

thank you for the comments

for packet capture DLPI used to be the interface of choice on older Solaris versions, then at some point Solaris grew BPF, which libpcap started to use instead

for interface enumeration it used to be SIOCGIFCONF for very old Unixes, probably including SunOS, then Solaris developed SIOCGLIFCONF, which served the purpose on Solaris 10 and probably before, then Solaris 11 developed getifaddrs()

so illumos inherited the BPF+getifaddrs() combination, which is one of the most popular

there is quite a bit of DLPI-specific code, but now it covers HP-UX only, and if there is a need to adapt it to another OS, there would be a risk of breaking HP-UX

Thanks for filing that. I've followed up with the note about what I think the fix is likely.

the illumos getifaddrs is largely built on top of SIOCGLIFCONF

is there a meaningful advantage of one over another or it is just a BSD/SystemV difference?

all of the SIOCG*IF* socket ioctls are complicated & fussy. SIOCGIFCONF wasn't a good match for what solaris had in its stack, especially with the addition of IPv6

so getifaddrs() hides the mess so only the library maintainer has to muck with it.

in libpcap getifaddrs() is the first choice, then SIOCGLIFCONF, then SIOCGIFCONF: github.com/the-tcpdump-group/libpcap/blob/master/configure.ac#L1162

it is difficult to tell immediately whether it would make more sense to prefer SIOCGLIFCONF, but at least one useful side effect is discovering a bug in getifaddrs()

this currently applies to Solaris 10 only: github.com/the-tcpdump-group/libpcap/blob/master/fad-glifc.c

anyway, thank you for the comments, it is becoming late in this corner of the Internet, I will be back tomorrow

I think preferring getifaddrs() makes sense in almost all cases.

I tried sharing physical drive over iSCSI from SmartOS host (p0) and linux machine doesn't see it and Windows iSCSI sees it and target but in disk management con't see partitions bt trats it as unformatted.

nikolam: does it look unformatted in SmartOS too?

Denis, nope, look allright, in format/fdisk, like 1 Ntfs partition on drive.

well, then I don't know

is the size at least the same at both ends?

Denis, what size. physical disk block size? I tried also today to set it on 512 was before 4096 exported and nothing changes, like, windows treats iscsi target as unformatted

nikolam: show the output of stmfadm list-lu -v

I had the exact disk size in bytes in mind, just to make sure it is the right lot of bytes that is being fed into iSCSI

denk, bpa.st/PZKQ

nikolam: you should recreate it and use metafile

otherwise the metadata will be placed into the data file

ah. metafile

it uses for about 64k

/dev/rdsk/c1t1d0p0 means a partition on the disk, doesn't it?

looking for a manual for metafile.. p0 should be the whole drive

the disk would be /dev/rdsk/c1t1d0, AFAIR, and the sizes would be different

but perhaps you know better

nikolam: also disable writeback cache

denk, thankt, still look how to make the metafiel and docs on it

thanks

stmfadm create-lu -pmeta=/path/to/meta.file -pblk=<physical sector size> -pserail=MySerial -pwcd=true /dev/rdsk/<device>

meta.file should exist

for example, touch /var/tmp/meta.file

wow I see thanks

probably you have corrupted the data on the device

don't forget about 64k of the metadata

anyway, you have been warned some time ago about second chance to fail :)

second chance to fail? :P

with zfs and snapshots

you choosen direct device

Ah ok :P data integrity. No sweat in this case

now with /var/tmp/meta.file is sees the drive wight in iscsi on windows. Without -pserail=MySerial , Will see about disabling writeback cache

wcd can be modified by modify-lu subcommand

stmfadm modify-lu -pwcd=true <guid>

wow I should be really reading more man pages. many thanks denk

will reboot to see how it it going on in real windows , thank you

sommerfeld: rmustacc: found another bug in getifaddrs(), filed as #16384

rmustacc: re DLPI, libpcap uses it on Solaris 10 for packet capture, but it would be only compile-testable with the current resources

also, re AF_LINK on the loopback interface, the semantics in other OSes that do it is to set sdl_alen to 0, then the purpose of sockaddr_dl is to convey the interface type and index