[net_server] it shouldn't be possible to auto-config an interface with no link

[diver]

Currently ifconfig configures link-local address on interfaces with no link.

<mmlr_thinkpad> it's just buggy/not fully implemented 
<mmlr_thinkpad> it doesn't actually check the link state 
<mmlr_thinkpad> indeed for wireless networks this will have to be reworked anyway 
<mmlr_thinkpad> or any network where link != usable 
<mmlr_thinkpad> dailup, vpn for example 
<mmlr_thinkpad> or maybe "link" should be reworked so that it actually means usable 
<mmlr_thinkpad> for wireless link usually means an association with an ap is there 
<mmlr_thinkpad> for wpa this doesn't mean that the link is actually usable though, because the wpa handshake needs to be completed first 
<mmlr_thinkpad> usually you don't notice that as it's rather quick and the dhcp requests are simply retried 
<mmlr_thinkpad> it's not exactly correct either way though 

[diver]

hrev45436 (​http://cgit.haiku-os.org/haiku/commit/?id=274b8be6c415dfb623f95ca9e4709c9f79836ae9) didn't help.

[mmlr]

Indeed hrev45436 should have disabled this behaviour. So unless BNetworkInterface::HasLink() is broken, or the driver at hand does not provide the link state via IFM_ACTIVE (or not at all), no configuration should happen. I have an unattached rtl81xx device here and invoking ifconfig /dev/net/rtl81xx/0 auto-config does nothing as it should.

I have disabled the ipv6 module here, so I can't comment on that.

[diver]

Indeed, I can only reproduce it with pcnet driver in vbox. ipro1000 driver works as expected. However, ​IFM_ACTIVE seems to be there.

[mmlr]

Can you attach a syslog? The media changes are printed there, so it should show there what's going on. Maybe media status reporting is broken or not implemented for that driver? You can verify that by checking the ifconfig output. The line where the MTU is printed also shows "link" if a link is detected. Note that there sadly are two different flags that are used to determine link state, IFM_ACTIVE and IFF_LINK. The ethernet network stack module does set IFF_LINK based on IFM_ACTIVE, but I haven't verified whether or not it is possible that the flags diverge at some point.

[diver]

After issuing the following command: VBoxManage controlvm Haiku setlinkstate1 off

this is what appears in syslog:

KERN: [net/pcnet/0] lost carrier
KERN: /dev/net/pcnet/0: media change, media 0x20 quality 1000 speed 1000000000
KERN: [net/pcnet/0] lost carrier

However, ifconfig still shows that the interface in question is UP:

/dev/net/pcnet/0
        Hardware type: Ethernet, Address: 08:00:27:b8:ae:41
        inet addr: 10.0.2.15, Bcast: 10.0.2.255, Mask: 255.255.255.0
        MTU: 1500, Metric: 0, up broadcast auto-configured
        Receive: 5 packets, 0 errors, 1856 bytes, 0 mcasts, 0 dropped
        Transmit: 7 packets, 0 errors, 954 bytes, 0 mcasts, 0 dropped
        Collisions: 0

After a minute new stuff appears in the syslog:

KERN: module: Search for network/protocols/ipv6/v1 failed.
KERN: [net/pcnet/0] lost carrier
Last message repeated 1 time
KERN: module: Search for network/protocols/ipv6/v1 failed.
KERN: [net/pcnet/0] device timeout
KERN: /dev/net/pcnet/0: media change, media 0x800020 quality 1000 speed 1000000000
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 4 secs (try 0)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
KERN: [net/pcnet/0] device timeout
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 8 secs (try 0)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
KERN: [net/pcnet/0] device timeout
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 2 secs (try 1)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 4 secs (try 1)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 8 secs (try 1)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
KERN: [net/pcnet/0] device timeout
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 2 secs (try 2)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 4 secs (try 2)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 8 secs (try 2)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
KERN: [net/pcnet/0] device timeout
DAEMON 'DHCP': /dev/net/pcnet/0: DHCP status = Operation timed out
KERN: module: Search for network/protocols/ipv6/v1 failed.

pcnet is still UP:

/dev/net/pcnet/0
        Hardware type: Ethernet, Address: 08:00:27:b8:ae:41
        Media type: Auto-select
        inet addr: 169.254.0.120, Bcast: 169.254.255.255, Mask: 255.255.0.0
        MTU: 1500, Metric: 0, up broadcast link auto-configured
        Receive: 5 packets, 0 errors, 1856 bytes, 0 mcasts, 0 dropped
        Transmit: 19 packets, 0 errors, 3954 bytes, 0 mcasts, 0 dropped
        Collisions: 0

VBoxManage controlvm Haiku setlinkstate1 on doesn't print anything in th syslog

I decided to manually trigger auto-config ifconfig /dev/net/pcnet/0 auto-config

DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_DISCOVER to 255.255.255.255:67
KERN: module: Search for network/protocols/ipv6/v1 failed.
KERN: [net/pcnet/0] lost carrier
KERN: /dev/net/pcnet/0: media change, media 0x20 quality 1000 speed 1000000000
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 4 secs (try 0)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_DISCOVER to 255.255.255.255:67
KERN: [net/pcnet/0] lost carrier
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 8 secs (try 0)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_DISCOVER to 255.255.255.255:67
KERN: [net/pcnet/0] lost carrier
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 2 secs (try 1)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_DISCOVER to 255.255.255.255:67
KERN: [net/pcnet/0] lost carrier
DAEMON 'DHCP': /dev/net/pcnet/0: Timeout shift: 4 secs (try 1)
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_DISCOVER to 255.255.255.255:67
KERN: /dev/net/pcnet/0: media change, media 0x800020 quality 1000 speed 1000000000
DAEMON 'DHCP': /dev/net/pcnet/0: Received DHCP_OFFER from 10.0.2.2
DAEMON 'DHCP':   your_address: 10.0.2.15
DAEMON 'DHCP':   subnet: 255.255.255.0
DAEMON 'DHCP':   gateway: 10.0.2.2
DAEMON 'DHCP':   nameserver[0]: 192.168.10.1
DAEMON 'DHCP':   lease time: 86400 seconds
DAEMON 'DHCP':   server: 10.0.2.2
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Received DHCP_ACK from 10.0.2.2
DAEMON 'DHCP':   subnet: 255.255.255.0
DAEMON 'DHCP':   gateway: 10.0.2.2
DAEMON 'DHCP':   nameserver[0]: 192.168.10.1
DAEMON 'DHCP':   lease time: 86400 seconds
DAEMON 'DHCP':   server: 10.0.2.2
KERN: module: Search for network/protocols/ipv6/v1 failed.
DAEMON 'DHCP': /dev/net/pcnet/0: DHCP status = No error
DAEMON 'DHCP': /dev/net/pcnet/0: Send DHCP_REQUEST for 10.0.2.15 to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/pcnet/0: Received DHCP_ACK from 10.0.2.2
DAEMON 'DHCP':   subnet: 255.255.255.0
DAEMON 'DHCP':   gateway: 10.0.2.2
DAEMON 'DHCP':   nameserver[0]: 192.168.10.1
DAEMON 'DHCP':   lease time: 86400 seconds
DAEMON 'DHCP':   server: 10.0.2.2
DAEMON 'DHCP': /dev/net/pcnet/0: DHCP status = No error
KERN: module: Search for network/protocols/ipv6/v1 failed.

[axeld]

The up state has nothing to do with the interface having link or not. If the interface actually has a link, ifconfig would mention that. IOW it appears that DHCP is issued even though there is no link. Since it took a minute or so, it might be lease time related; maybe the timeout is not reset or incorrectly used.

[jackburton]

isn't this a dup of #9411 ?

[diver]

The question is: why link appears a minute after VBoxManage controlvm Haiku setlinkstate1 off. ifconfig /dev/net/pcnet/0 auto-config also triggers link state...

[diver]

Not reproducible with ipro1000 driver.

[diver]

It appears that pinging something helps triggering correct link state with pcnet driver. Go figure...

[diver]

Still here after pcnet update in hrev46220.

[waddlesplash]

This looks like the issue tqh said he was going to look into recently, so CC'ing him on it.