Project

General

Profile

Actions

Bug #14474

open

NWAM does not get event "LINK DOWN" but "LINK_UP" instead when eth cable is disconnected

Added by Stephan Althaus 5 months ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
networking
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Hello!

Last week my DSL internet connection was gone and i wanted to go online via WLAN connnected to my mobile..
When i disconnected the ethernet connection - nothing happened on the OI network-monitor-applet.

My first short investigation shows, that dladm show-phys and dladm show-link know about the new state "down",
but ipadm show-addr still shows the 'old' IP address of the lost connection.

After "sudo svcadm restart nwam" everything seems to be re-checked and the interface states are correct.

What does nwamadm see about this ? After i reconnect the cable, and disconnect the cable while looking on the events, this happens:

$ nwamadm show-events -v
EVENT DESCRIPTION
LINK_STATE e1000g4 -> state up

So there is an event going to NWAM, but not the correct one, the EVENT should be "STATE DOWN"

I crossed-checked with the latest OI-hipster-gui-20211031.usb on a (USB-2-only) laptop, there the event is correct and the connection is completely down after a second.
I hav re-checked the behaviour on this machine with the live-USB-image - this was ok.

Now i tried dtrace to get closer to the origin.

On the faulty system, the probe str_notify_link_up is hit when i disconnect the cable

#dtrace -n 'fbt::str_notify_link_up:entry { printf("%x %d", arg0, arg1); stack(); }'
dtrace: description 'fbt::str_notify_link_up:entry ' matched 1 probe
CPU ID FUNCTION:NAME
4 49481 str_notify_link_up:entry fffffe2caabe0ab8 -2007257701184
dld`str_notify+0x1a8
mac`i_mac_notify_thread+0x11c
unix`thread_start+0xb

... while str_notify_link_down is not:

dtrace -n 'fbt::str_notify_link_down:entry { printf("%x %d", arg0, arg1); stack(); }'
dtrace: description 'fbt::str_notify_link_down:entry ' matched 1 probe

But, on a machine booted with the latest iso the str_notify_link_down probe is hit:

dtrace -n 'fbt::str_notify_link_down:return { stack(); }'
dtrace: description 'fbt::str_notify_link_down:return ' matched 1 probe
CPU ID FUNCTION:NAME
0 36174 str_notify_link_down:return
dld`str_notify+0x1f8
mac`i_mac_notify_thread+0x11c
unix`thread_start+0xb

Any hints on how to get closer to the part where the events get compromised are welcome..

Actions #1

Updated by Stephan Althaus 5 months ago

Hmm.

mac_stat_get:return mac_stat_get 60 0

mac_client_stat_get:return mac_client_stat_get 50 1

Actions #2

Updated by Stephan Althaus 5 months ago

#dtrace -n 'fbt::e1000g_link*:return { printf("%s %x %d", probefunc, arg0, arg1); stack(); }'

works correctly.

MAC_STAT_LOWLINK_STATE is correct, the MAC_STAT_LINK_STATE is not.

Why should they be different, it is a simple buildtin PCIe e1000g4 (with IPV4 and IPV6 enabled with DHCP) ?

BTW, how can i print the interface name with dtrace, i did not manage to do a cast on the structs ?

Actions #3

Updated by Andy Fiddaman 5 months ago

Stephan Althaus wrote in #note-2:

BTW, how can i print the interface name with dtrace, i did not manage to do a cast on the structs ?

The easiest thing is probably just to print the instance ID. If you use the args array then dtrace knows the types, so it should be possible to just do:

fbt::e1000g_link_up:entry {
    trace(args[0]->instance);
    /* or */
    printf("e1000g%d\n", args[0]->instance);
}
Actions #4

Updated by Stephan Althaus 5 months ago

Thanks for your hint, your suggestion works. I will now try to isolate the problem further by comparing the results of the various functions.
Thanks!

Actions #5

Updated by Stephan Althaus 5 months ago

fbt::str_notify_link_up:entry
{  
    printf("%s %x %d %d:%d state %d\n", probefunc, arg0, arg1, args[0]->ds_major, args[0]->ds_minor, args[0]->ds_dlstate); 
    stack();  
}

fbt::str_notify_link_up:return
{  
    printf("%s %x state %d\n", probefunc, arg0, arg1 );   
    stack();  
}

fbt::str_notify_link_down:entry 
{  
    printf("%s %x %d %d:%d state %d\n", probefunc, arg0, arg1, args[0]->ds_major, args[0]->ds_minor, args[0]->ds_dlstate);   
    stack();  
}

fbt::str_notify_link_down:return
{  
    printf("%s %x state %d\n", probefunc, arg0, arg1);   
    stack();  
}

fbt::mac_client_link_state:entry { printf("%s %x (%s, %d) \n", probefunc, arg0, args[0]->mci_name, arg1);     
stack();
}
fbt::mac_stat_get:entry {          printf("%s %x (%s, %d) \n", probefunc, arg0, ((mac_impl_t *)args[0])->mi_name, arg1);     
stack();
}
fbt::mac_client_stat_get:entry {   printf("%s %x (%s, %d)\n", probefunc, arg0, ((mac_client_impl_t *)args[0])->mci_name, arg1);     
stack();
}

fbt::mac_client_link_state:return { printf("%s %x %d \n", probefunc, arg0, arg1); stack();  }
fbt::mac_stat_get:return {          printf("%s %x %d \n", probefunc, arg0, arg1); stack();  }
fbt::mac_client_stat_get:return {   printf("%s %x %d \n", probefunc, arg0, arg1); stack();  }

Actions #6

Updated by Stephan Althaus 5 months ago

$ dladm show-link
LINK CLASS MTU STATE BRIDGE OVER
vboxnet0 phys 9706 up -- --
e1000g4 phys 1500 up -- --
bhyve0 vnic 1500 up -- e1000g4

This vnic was disturbing the link state communication. After i removed it, the nwamadm got the right events.

I don't know but shouldn't the link state of a vnic go down together with the underlying physical link ?

And to summarize, is the described symptom of nwamadm getting "LINK_UP" the desired behaviour ?

Actions

Also available in: Atom PDF