so the ietf.org/rfc/rfc2132.txt definition of dhcp option 3 allows multiple addresses in the same option and says " The router option specifies a list of IP addresses for routers on the client's subnet. Routers SHOULD be listed in order of preference."

but it doesn't specify the client behavior

jclulow: unplumb is I think not the intended way

sommerfeld: Yeah I think it's sufficiently underspecified that you should never do it unless all of the router IPs are equivalent

EisNerd_: Indeed, you should be able to do something with the ipadm command

not the ifconfig command

And if you cannot, then we should get a bug filed with the detalis of the system got into this state and what isn't working when trying to fix it

how to get rid of this "e1000g0/?"

I'm not sure! I would try to delete-addr -- but I suspect that won't work

ipadm: could not delete address: Object not found

For the bug, I would get at least the following information together: the contents of "/etc/ipadm/ipadm.conf", the output of "ipadm show-addr" and "ipadm show-if", and the output of "ifconfig -a", and perhaps "dladm show-link"

guess illumos?

Yes

oh also the output of "svcs network/physical"

jclulow: illumos.org/issues/16472

→ BUG 16472: unable to remove addr-obj with ipadm (New)

EisNerd_: So did you have nwam enabled previously?

btw how well is support for zfs audit flag currently?

jclulow: maybe on install

but I removed this cleanly years ago

So where does the IP address on e1000g0 come from

configuration using hostname files

Ah ok, can you include that detail in the issue

give me a second

When you say you had an "/etc/hostname6.e1000g0" file, you've removed that now? And rebooted?

Do you have any /etc/dhcp.* files?

jclulow: not yet rebooted

Ok, so the empty "hostname6.e1000g0" file is probably where the addrconf address came from I imagine, at least

What does "netstat -D" say

manual ifconfig (and hostname.ifname) will create temporary address object in ipadm term (that is what you see as ifname/? entry), but since ifconfig plumb will also create temporary 'ipadm create-if', that whole combination is probably having some interesting corner cases in ipadm context...

jclulow: added comment with this information

EisNerd_: alright thanks

just to note, parts of this is older than ipadm afaik

Now that you have removed the /etc/hostname6.* file, if you reboot does that weird IPv6 stuff go away?

And then, once it's gone, hopefully "ipadm create-addr -T addrconf e1000g0/v6" will work

jclulow: yes, worked, thx

Excellent

afaik initially ipadm was not able to just autoconfigure v6, it was eigther both or nothing, so I used the hostname-file way

but the log gets still flooded

just replace e1000g0:1: with e1000g0:2:

logflooding stops if I remove the v6 addr

as to be expected

well, our commit log does not mention ipadm + v6 changes, and v6 addrobj was present in 'PSARC 2009/306 Brussels II - ipadm and libipadm' :) but thats long time ago and details are not easy to find:)

anyway, the logflooding is anoying

any idea to this part?

what is the message in that flood?

see the issue, I added it there also

as I suspected it being a potential symptom

you have stateful addrconf ?

looks like the file thing was more or less working as expected, just a bit awkward but with the same result in the end

tsoome: ??

I have a fritz box configured for dual stack operation intern and extern using public prefix provided, this is also the reason I need v6 auto configuration

as I do not know the exact v6 address I get

sadly I'm not a v6 expert and still looking for some source to explain this entire thing useful

did you try ipadm create-addr -T addrconf -p stateless=yes

does not change anything

If my memory serves, stateless is autoconfig based on announced prefix and mac address; stateful is dhcpv6

but I can not find references that quick:D

my network should be able to serve both, but I could check

I have never used dhcpv6 myself, have no idea how our dhcpagent is behaving with v6

ipadm show-addr -o all is telling me:

e1000g0/v6 addrconf ok U---- U-- fe80::ec4:7aff:fe6b:3dae%e1000g0/10

e1000g0/v6 addrconf ok U---- --- 2001:7d0:4981:f900:ec4:7aff:fe6b:3dae/64

dhcpv6 is active

same here (jsut different addresses ;))

but also v6 advertising afaik

maybe this is the cause, as both methods try to configure the if on illumos

does snoop/wireshark confirm your host is performing v6 dhcp request/replys?

guess I solved it

different prefixes should trigged creation of additional virtual interfaces (ifname:X)

=> ipadm create-addr -T addrconf -p stateless=no e1000g0/v6

and the flood stopped?

yes

and following our discussion it was concluding

so dhcpv6 and stateless config is not healthy

so stateless autoconf kicked in first and configured the ip based on advertisements

dhcpv6 was slower but get same result and tried also to configure it

but can't as the ip was already configured

sounds like a bug to me:)

I guess if I set "stateful=no" it will also stop

worth to test but I'm quite sure it will

/sbin/dhcpagent[4053]: [ID 490758 daemon.error] send_pkt_internal: cannot send RELEASE packet to server (will retry in 1 seconds): No buffer space available

uh?

ok flooding is back, let's check

I'm using v6 since it appeared in Solaris 7;)

ok, yes this also resolves flooding (stateful=no)

so which would be the better choice?

depends on your intent. stateless depends on prefix announcements from router, stateful is depending on dhcp server config.

both should be equal here

dhcp allows to set lease times etc

ok the reboot also solved my usb ftdi issue

and maybe without the log flood other things get smother

btw is there any progress regarding persistent device naming?

and, as already asked, how well is support for zfs audit flag currently and is there some good documentation about this?

nothing special is added recently. there are some patches around to add better support, especially related to nfs and smb, but this all does take a lot of time.

EisNerd_: How do you mean persistent device naming? Much of our device naming is persistent already

tsoome: yeah saw on issues that Gordon was working on this some time ago

jclulow: for example for USB ftdi serial adapters

Ah, well, USB is pretty tricky to be honest

jclulow: would be nice to have some persistent naming, like /dev/cua/by-name/[DRIVER]-[TYPE]-[SERIAL]

Yes, I've thought about that before

Part of the trouble is that there are literally no guarantees about the serial numbers

They might not exist, they might not be unique, they might contain illegal characters, etc

if it does not work or gets collisions, we can add a seuqence number, choosen by path

EisNerd_: Can you pastebin the output of "prtconf -v" on the system with your FTDI parts

it would be still better compared to current situation

cfgadm also shows all is needed

thats a lot

it is! can you just paste it into a gist/pastebin

on mac i get /dev/tty.usbserial-210

Also the output of "ls -la /dev/term"

can I use such in zone configuration? /devices/pci@0,0/pci8086,3b4e@1c,6/pci17aa,219c@0/device@3:0,cu

No I believe you need to match things in /dev

That said I think you can just create your own links in a part of /dev that devfsadm isn't managing?

maybe /etc/devlink.tab can help already

I mean you can just use "ln -s"

e.g., something like: ln -s ../devices/pci@0,0/pci8086,3b4e@1c,6/pci17aa,219c@0/device@3:0,cu /dev/myserialport

I suspect that would work in a zone device "match" rule then

how to get the ddi_ type of a device?

Seriously I can spell "approval". :-/

:)

sure?

2 out of 3 isn't bad

[illumos-gate] 16452 want strerrordesc_np and strerrorname_np -- Robert Mustacchi <rm⊙fo>