This is the first time I've come across this:
panic[cpu1]/thread=ffffff02e79e7880:
assertion failed: !IN6_IS_ADDR_V4MAPPED(dst_addr), file:
../../common/inet/ip/ip6.c, line: 1984
ffffff0010671340 genunix:process_type+162480 ()
ffffff0010671440 ip:ip_set_destination_v6+4a9 ()
ffffff0010671500 ip:ip_attr_connect+147 ()
ffffff00106715c0 ip:conn_connect+10f ()
ffffff0010671650 ip:tcp_set_destination+70 ()
ffffff0010671720 ip:tcp_input_listener+c1a ()
ffffff00106717c0 ip:squeue_enter+963 ()
ffffff0010671880 ip:ip_fanout_v6+97f ()
ffffff0010671b00 ip:ire_send_local_v6+44c ()
ffffff0010671b80 ip:conn_ip_output+2bc ()
ffffff0010671bb0 ip:tcp_send_data+80 ()
ffffff0010671c60 ip:tcp_do_connect+430 ()
ffffff0010671d40 ip:tcp_connect+c9 ()
ffffff0010671de0 sockfs:so_connect+fe ()
ffffff0010671e30 sockfs:socket_connect+3c ()
ffffff0010671eb0 sockfs:connect+b1 ()
ffffff0010671f00 unix:brand_sys_syscall32+272 ()
Here I was running firefox in a NG zone to a redirected ssh port (that
is to say with 'ssh -L 8169:192.168.0.1:8069 remote-ip-addr'
not sure it really makes any difference, though.
I did use "firefox24 localhost:8169" though, and I was connected for a
few minutes prior to the panic.
Pretty vanilla, really.
/etc/hosts contains (among other adresses):
::1 localhost
127.0.0.1 localhost loghost
richard@devzone:~$ ifconfig
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
vnic0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.0.80 netmask ffffff00 broadcast 192.168.0.255
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252
index 1
inet6 ::1/128
vnic0: flags=20002000840<RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 ::/0
The code suggests
/*
* Verify that both the source and destination addresses are valid. If
* IPDF_VERIFY_DST is not set, then the destination address may be unreachable,
* i.e. have no route to it. Protocols like TCP want to verify destination
* reachability, while tunnels do not.
*
* Determine the route, the interface, and (optionally) the source address
* to use to reach a given destination.
* Note that we allow connect to broadcast and multicast addresses when
* IPDF_ALLOW_MCBC is set.
* first_hop and dst_addr are normally the same, but if source routing
* they will differ; in that case the first_hop is what we'll use for the
* routing lookup but the dce and label checks will be done on dst_addr,
*
* If uinfo is set, then we fill in the best available information
* we have for the destination. This is based on (in priority order) any
* metrics and path MTU stored in a dce_t, route metrics, and finally the
* ill_mtu/ill_mc_mtu.
*
* Tsol note: If we have a source route then dst_addr != firsthop. But we
* always do the label check on dst_addr.
*
* Assumes that the caller has set ixa_scopeid for link-local communication.
*/
int
ip_set_destination_v6(in6_addr_t *src_addrp, const in6_addr_t *dst_addr,
const in6_addr_t *firsthop, ip_xmit_attr_t *ixa, iulp_t *uinfo,
uint32_t flags, uint_t mac_mode)
{
ire_t *ire;
int error = 0;
in6_addr_t setsrc; /* RTF_SETSRC */
zoneid_t zoneid = ixa->ixa_zoneid; /* Honors SO_ALLZONES */
ip_stack_t *ipst = ixa->ixa_ipst;
dce_t *dce;
uint_t pmtu;
uint_t ifindex;
uint_t generation;
nce_t *nce;
ill_t *ill = NULL;
boolean_t multirt = B_FALSE;
ASSERT(!IN6_IS_ADDR_V4MAPPED(dst_addr));
ASSERT(!(ixa->ixa_flags & IXAF_IS_IPV4));
Any clues on what to look for? Anything new in this area that might be
suspect?
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
