03:27:33 <sommerfeld> so the https://www.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."
03:27:49 <sommerfeld> but it doesn't specify the client behavior
04:56:43 <EisNerd_> jclulow: unplumb is I think not the intended way
04:58:13 <jclulow> sommerfeld: Yeah I think it's sufficiently underspecified that you should never do it unless all of the router IPs are equivalent
04:58:40 <jclulow> EisNerd_: Indeed, you should be able to do something with the ipadm command
04:58:43 <jclulow> not the ifconfig command
04:59:30 <jclulow> 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
05:00:20 <EisNerd_> how to get rid of this "e1000g0/?"
05:00:55 <jclulow> I'm not sure!  I would try to delete-addr -- but I suspect that won't work
05:02:41 <EisNerd_> ipadm: could not delete address: Object not found
05:03:10 <jclulow> 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"
05:04:55 <EisNerd_> guess illumos?
05:05:01 <jclulow> Yes
05:05:14 <jclulow> https://www.illumos.org/projects/illumos-gate/issues/new
05:06:01 <jclulow> oh also the output of "svcs network/physical"
05:31:42 <EisNerd_> jclulow: https://www.illumos.org/issues/16472
05:31:43 <fenix> → BUG 16472: unable to remove addr-obj with ipadm (New)
05:33:10 <jclulow> EisNerd_: So did you have nwam enabled previously?
05:33:30 <EisNerd_> btw how well is support for zfs audit flag currently?
05:33:43 <EisNerd_> jclulow: maybe on install
05:33:59 <EisNerd_> but I removed this cleanly years ago
05:34:14 <jclulow> So where does the IP address on e1000g0 come from
05:34:38 <EisNerd_> configuration using hostname files
05:34:55 <jclulow> Ah ok, can you include that detail in the issue
05:35:10 <EisNerd_> give me a second
05:36:00 <jclulow> When you say you had an "/etc/hostname6.e1000g0" file, you've removed that now?  And rebooted?
05:38:20 <jclulow> Do you have any /etc/dhcp.* files?
05:47:52 <EisNerd_> jclulow: not yet rebooted
05:48:40 <jclulow> Ok, so the empty "hostname6.e1000g0" file is probably where the addrconf address came from I imagine, at least
05:48:49 <jclulow> What does "netstat -D" say
07:06:44 <tsoome> 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...
07:18:58 <EisNerd_> jclulow: added comment with this information
07:19:27 <jclulow> EisNerd_: alright thanks
07:19:27 <EisNerd_> just to note, parts of this is older than ipadm afaik
07:20:04 <jclulow> Now that you have removed the /etc/hostname6.* file, if you reboot does that weird IPv6 stuff go away?
07:20:55 <jclulow> And then, once it's gone, hopefully "ipadm create-addr -T addrconf e1000g0/v6" will work
07:33:34 <EisNerd_> jclulow: yes, worked, thx
07:33:40 <jclulow> Excellent
07:34:26 <EisNerd_> afaik initially ipadm was not able to just autoconfigure v6, it was eigther both or nothing, so I used the hostname-file way
07:34:57 <EisNerd_> but the log gets still flooded
07:36:38 <EisNerd_> just replace e1000g0:1: with e1000g0:2:
07:41:28 <EisNerd_> logflooding stops if I remove the v6 addr
07:41:40 <EisNerd_> as to be expected
07:41:49 <tsoome> 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:)
07:44:51 <EisNerd_> anyway, the logflooding is anoying
07:45:04 <EisNerd_> any idea to this part?
07:45:06 <tsoome> what is the message in that flood?
07:45:23 <EisNerd_> see the issue, I added it there also
07:46:04 <EisNerd_> as I suspected it being a potential symptom
07:46:58 <tsoome> you have stateful addrconf ?
07:47:01 <EisNerd_> looks like the file thing was more or less working as expected, just a bit awkward but with the same result in the end
07:47:13 <EisNerd_> tsoome: ??
07:48:49 <EisNerd_> 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
07:49:34 <EisNerd_> as I do not know the exact v6 address I get
07:51:09 <EisNerd_> sadly I'm not a v6 expert and still looking for some source to explain this entire thing useful
07:51:12 <tsoome> did you try ipadm create-addr -T addrconf -p stateless=yes 
07:52:27 <EisNerd_> does not change anything
07:52:43 <tsoome> If my memory serves, stateless is autoconfig based on announced prefix and mac address; stateful is dhcpv6 
07:52:59 <tsoome> but I can not find references that quick:D
07:53:11 <EisNerd_> my network should be able to serve both, but I could check
07:54:01 <tsoome> I have never used dhcpv6 myself, have no idea how our dhcpagent is behaving with v6
07:57:13 <tsoome> ipadm show-addr -o all is telling me: 
07:57:14 <tsoome> e1000g0/v6        addrconf ok           U----   U--        fe80::ec4:7aff:fe6b:3dae%e1000g0/10
07:57:14 <tsoome> e1000g0/v6        addrconf ok           U----   ---        2001:7d0:4981:f900:ec4:7aff:fe6b:3dae/64
07:57:37 <EisNerd_> dhcpv6 is active
07:58:29 <EisNerd_> same here (jsut different addresses ;))
07:59:17 <EisNerd_> but also v6 advertising afaik
08:00:33 <EisNerd_> maybe this is the cause, as both methods try to configure the if on illumos
08:00:40 <tsoome> does snoop/wireshark confirm your host is performing v6 dhcp request/replys?
08:01:28 <EisNerd_> guess I solved it
08:01:36 <tsoome> different prefixes should trigged creation of additional virtual interfaces (ifname:X)
08:01:54 <EisNerd_> => ipadm create-addr -T addrconf  -p stateless=no e1000g0/v6
08:02:44 <tsoome> and the flood stopped?
08:02:48 <EisNerd_> yes
08:03:04 <EisNerd_> and following our discussion it was concluding
08:03:18 <tsoome> so dhcpv6 and stateless config is not healthy
08:03:30 <EisNerd_> so stateless autoconf kicked in first and configured the ip based on advertisements
08:03:51 <EisNerd_> dhcpv6 was slower but get same result and tried also to configure it
08:04:06 <EisNerd_> but can't as the ip was already configured
08:04:07 <tsoome> sounds like a bug to me:)
08:04:42 <EisNerd_> I guess if I set "stateful=no" it will also stop
08:05:55 <tsoome> worth to test but I'm quite sure it will
08:07:57 <EisNerd_>  /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
08:08:00 <EisNerd_> uh?
08:09:50 <EisNerd_> ok flooding is back, let's check
08:10:43 <tsoome> I'm using v6 since it appeared in Solaris 7;)
08:13:59 <EisNerd_> ok, yes this also resolves flooding (stateful=no)
08:15:39 <EisNerd_> so which would be the better choice?
08:17:10 <tsoome> depends on your intent. stateless depends on prefix announcements from router, stateful is depending on dhcp server config.
08:20:13 <EisNerd_> both should be equal here
08:21:19 <tsoome> dhcp allows to set lease times etc
08:25:17 <EisNerd_> ok the reboot also solved my usb ftdi issue
08:25:46 <EisNerd_> and maybe without the log flood other things get smother
08:26:34 <EisNerd_> btw is there any progress regarding persistent device naming?
08:29:55 <EisNerd_> and, as already asked, how well is support for zfs audit flag currently and is there some good documentation about this?
08:33:51 <tsoome> 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.
08:48:16 <jclulow> EisNerd_: How do you mean persistent device naming?  Much of our device naming is persistent already
08:52:46 <EisNerd_> tsoome: yeah saw on issues that Gordon was working on this some time ago
08:53:11 <EisNerd_> jclulow: for example for USB ftdi serial adapters
08:53:39 <jclulow> Ah, well, USB is pretty tricky to be honest
08:55:01 <EisNerd_> jclulow: would be nice to have some persistent naming, like /dev/cua/by-name/[DRIVER]-[TYPE]-[SERIAL]
08:55:18 <jclulow> Yes, I've thought about that before
08:55:36 <jclulow> Part of the trouble is that there are literally no guarantees about the serial numbers
08:55:48 <jclulow> They might not exist, they might not be unique, they might contain illegal characters, etc
08:57:28 <EisNerd_> if it does not work or gets collisions, we can add a seuqence number, choosen by path
08:57:38 <jclulow> EisNerd_: Can you pastebin the output of "prtconf -v" on the system with your FTDI parts
08:57:49 <EisNerd_> it would be still better compared to current situation
08:58:09 <EisNerd_> cfgadm also shows all is needed
08:58:36 <EisNerd_> thats a lot
08:58:48 <jclulow> it is!  can you just paste it into a gist/pastebin
08:59:11 <tsoome> on mac i get  /dev/tty.usbserial-210 
09:00:39 <jclulow> Also the output of "ls -la /dev/term"
09:07:13 <EisNerd_> can I use such in zone configuration? /devices/pci@0,0/pci8086,3b4e@1c,6/pci17aa,219c@0/device@3:0,cu
09:07:54 <jclulow> No I believe you need to match things in /dev
09:08:09 <jclulow> That said I think you can just create your own links in a part of /dev that devfsadm isn't managing?
09:10:01 <EisNerd_> maybe /etc/devlink.tab can help already
09:11:36 <jclulow> I mean you can just use "ln -s"
09:12:45 <jclulow> e.g., something like: ln -s ../devices/pci@0,0/pci8086,3b4e@1c,6/pci17aa,219c@0/device@3:0,cu /dev/myserialport
09:13:05 <jclulow> I suspect that would work in a zone device "match" rule then
09:17:45 <EisNerd_> how to get the ddi_ type of a device?
20:20:10 <kebe> Seriously I can spell "approval".  :-/
20:23:57 <tsoome> :)
20:23:58 <tux0r> sure?
20:44:04 <sommerfeld> 2 out of 3 isn't bad
23:23:46 <gitomat> [illumos-gate] 16452 want strerrordesc_np and strerrorname_np -- Robert Mustacchi <rm⊙fo>