# Dual Boot FreeBSD - Linux: conflict with the Ethernet adapter



## freezr (Jan 10, 2022)

Dear All,

I'd like to say that I fully switched to FreeBSD however still have a big issue that prevents me to use FreeBSD daily.

I have issue with the "Atheros Killer E2400 Ethernet Adapter as formerly described here:








						Solved - Atheros Killer E2400 Does Not Work!
					

Hi Folks,  I am still uncertain if to be sad or upset, but this has been almost shocking for me and my future plans.  During the WE, in my very few spare time available, I tested out the hardware compatibility of my laptop with the latest NomadBSD and GhostBSD, especially with the former which...




					forums.freebsd.org
				




During the installation time FreeBSD was unable to use the ethernet and the wifi card, however in a former test I was able to get the ethernet working with NomadBSD, hence I tried to troubleshoot the ethernet card with NomadBSD again to check eventually which special setup allowed NomadBSD to have the ethernet working.

Well after 4 or maybe 5 rebooting with NomadBSD the NIC suddenly started to work and I was able to finish to setup FreeBSD, and everything have beeing doing smooth (for a week) until yesterday that I had to boot into Linux again.

I was worried this would triggered again the same issue and as a matter of fact when later I rebooted again in FreeBSD the NIC was again in that state that cannot get a DHCP address. I left the laptop dischargingg in order to verify if this is able to "reset" the state of the NIC and make it working again with FreeBSD. I am pretty sure when it worked with NomadNSD I forgot the laptop unplugged.

Anyway this is very annoying, *is this a common issue when the same hardware is shared between FreeBSD and Linux?*

I don't have any clue on how to address this issue, but* it is clear that Linux leaves the NIC in a state that makes it unusable for FreeBSD.* I can't provide my rc.conf, right now, since I forgot the pendrive where I saved it, but it is pretty standard and it doesn't have anything special:


```
ifconfig_alc0="DHCP"
ifconfig_alc0_ipv6="inet6 accept_rtadv"
```

Any hint and suggestion to understand what is happening is really appreciated!

Thanks,

D.


----------



## jbo (Jan 10, 2022)

tgl said:


> I'd like to say that I full y switch to FreeBSD [...]


Nice!



tgl said:


> Anyway this is very annoying, *is this a common issue when the same hardware is shared between FreeBSD and Linux?*


In general: No.
A known problem is when dualbooting Windows regarding the system time.
Frankly there is also not a lot that can go on here. If there are side-effects between cross-boots I'd argue that it's most likely related to some firmware being written to the piece of hardware in question which for some reason doesn't happen on the next cross-boot. But this is extremely far fetched.
You might want to check `dmesg` for firmware related messages.

Based off of your first post here I'm also not sure what "not working" means. Does the device show up but it can't get a link? Or does the device not show up at all? Given that this is a PCIe NIC you might want to compare outputs of `pciconf` to check whether a driver is attached when it's "not working".

Another far fetched thing: If "not working" means that the device does not show up but it does after a couple of reboots maybe there is something preventing the auto-detection from loading the corresponding alc(4) driver. Check the output of `kldstat` to see whether the driver is actually loaded when the device is "not working".

Even more far-fetching: Maybe there's something regarding MSI not working properly. If you're desperate you might want to try setting `hw.alc.msi.disable` to `1` and likewise for `hw.alc.msix_disable`.
There have been some MSI related fixes a few days/weeks ago but I think those were all related to bhyve.

Furthermore, can you provide information regarding the functionality under Linux? Do you get similar flakey behavior there or is it rock-solid working 10-out-of-10 times there?

But please: Provide more information regarding the "not working" situation. What are the exact symptoms?


----------



## zirias@ (Jan 10, 2022)

I never heard of this specific problem, so I'd confirm NO, that's NOT a common issue when using the same hardware with different OS.

What I've seen in the past is hardware going to some broken state where only a full power-down helps, unfortunately such things happen. So it's not too surprising (although VERY unlikely to happen) different drivers might do something to a specific piece of hardware that breaks the _other_ driver.

Solution: Always boot the same system 

But, seriously, depending on what you use this Linux system for, maybe virtualization would be an alternative?


----------



## freezr (Jan 10, 2022)

Hi, Thanks to all.

The Atheros Killer e2400 is a ethernet card, the wifi is working although I haven't setup it yet, and I would avoid to use it since the wifi space is already congested by tablets, phones and SmartTVs.

I left the Linux partition because there are still stuff that work on Linux only, for instance I have zoom interview this week and I don't want use any workaround to make Zoom working barely acceptable with such delicate stuff.

Maybe might exist some command in the Linux driver that clears up the state of the card and I could run it when I reboot/shutdown Linux...


----------



## jbo (Jan 10, 2022)

I've edited my post above a minute after posting it so you might have missed the remainder of the content - especially the questions I've added.


----------



## freezr (Jan 10, 2022)

I just found it on the Arch wiki and I have internet from the cable:


> Troubleshooting​
> Swapping computers on the cable modem​Some cable ISPs (Vidéotron for example) have the cable modem configured to recognize only one client PC, by the MAC address of its network interface. Once the cable modem has learned the MAC address of the first PC or equipment that talks to it, it will not respond to another MAC address in any way. Thus if you swap one PC for another (or for a router), the new PC (or router) will not work with the cable modem, because the new PC (or router) has a MAC address different from the old one. To reset the cable modem so that it will recognise the new PC, you must power the cable modem off and on again. Once the cable modem has rebooted and gone fully online again (indicator lights settled down), reboot the newly connected PC so that it makes a DHCP request, or manually make it request a new DHCP lease.
> 
> If this method does not work, you will need to clone the MAC address of the original machine. See also MAC address spoofing.



Can it be the issue related with the Mac Address?

Sometimes we reset the router because the Smart TVs have issues to get a stable signal, maybe this might be another reason why the network used to work...


----------



## jbo (Jan 10, 2022)

It would really help if you could answer at least some of the questions from my first post. As far as I am concerned we still don't know what "doesn't work" or "unable to use the ethernet card" means.

Whether or not you are able to talk to your ISP shouldn't matter based on "unable to use the ethernet card".


----------



## freezr (Jan 10, 2022)

Sorry now I got your changes.



jbodenmann said:


> You might want to check `dmesg` for firmware related messages.
> 
> Based off of your first post here I'm also not sure what "not working" means. Does the device show up but it can't get a link? Or does the device not show up at all? Given that this is a PCIe NIC you might want to compare outputs of `pciconf` to check whether a driver is attached when it's "not working".



It can't get a DHCP address and I get:


```
DHCP lease acquisition failed
```



jbodenmann said:


> Another far fetched thing: If "not working" means that the device does not show up but it does after a couple of reboots maybe there is something preventing the auto-detection from loading the corresponding alc(4) driver. Check the output of `kldstat` to see whether the driver is actually loaded when the device is "not working".



The kernel module is properly loaded, sorry for the generalization. The issue is in getting a DHCP address in order to work, however with a static IP doesn't work either.



jbodenmann said:


> Even more far-fetching: Maybe there's something regarding MSI not working properly. If you're desperate you might want to try setting `hw.alc.msi.disable` to `1` and likewise for `hw.alc.msix_disable`.
> There have been some MSI related fixes a few days/weeks ago but I think those were all related to bhyve.
> 
> Furthermore, can you provide information regarding the functionality under Linux? Do you get similar flakey behavior there or is it rock-solid working 10-out-of-10 times there?



I already tried all those changes none of them worked, I started to get the IP address I guess for two reason: 1) laptop battery went down; 2) I restarted the router.

With Linux worked out of the box, this is an ten years old System76 laptop, but still pretty powerful; designed to work with Debian based distros out-of-the-box.



jbodenmann said:


> But please: Provide more information regarding the "not working" situation. What are the exact symptoms?



The DHCP lease doesn't work and therefore I can't get any internet access.

This is the state of my cards (from NomadBSD) when I can't get the DHCP address:






I'll post more info later in the evening.


----------



## jbo (Jan 10, 2022)

so the device itself is *always* showing up properly when you boot into FreeBSD? As in: You *always* see alc0 showing up under `ifconfig`?



tgl said:


> [...], however with a static IP doesn't work either.


Can you show the output of `ifconfig alc0` after setting a static IP & netmask?

This is another long shot but it might be fun to check whether ARP itself is working. I'm suggesting this because unless I'm missing something your NIC is active and auto-selected the correct media.
But keep in mind that this is just another long shot. It doesn't make a lot of sense given that if ARP is working the networking stack should be able to send IP packages.

I assume you already tried the "_have you turned it off and on again?"_ approach: `ifconfig alc0 down` `ifconfig alc0 up`.
Also what Zirias said earlier: What about proper cold boots? What behavior are you observing then?


----------



## Logicien (Jan 10, 2022)

Hello,

I have this wire Ethernet card

Ethernet controller [0200]: Qualcomm Atheros AR8132 Fast Ethernet [1969:1062] (rev c0)

FreeBSD detect it as alc0. I use it with a static IP address to connect it directly to an other device. I use only wireless in dhcp. So far it have always work.

If you cannot get an ip configuration from the dhcp server, be sure that the dhcp server is not in cause. You can do like me for a test, connect an RJ45 câble between alc0 and an other computer and configure them on the same network and try to login on any side through this wire link. The problem can be the RJ45 cable as well than the connectors on both sides so, make a manual test on FreeBSD to be sure it work without a dhcp server even if you know that it work on Linux.

Have you reset the dhcp server and poweroff FreeBSD before to try to connect? Be sure too that you use the same MAC address for this alc0 card in FreeBSD than in Linux. Servers need to be reset to accept a new MAC address. In my case I rename alc0 to eth0 in rc.conf so, you can try to rename it too:

ifconfig_alc0_name="eth0"
ifconfig_eth0="inet aaa.bbb.ccc.ddd broadcast aaa.bbb.ccc.ddd netmask aaa.bbb.ccc.ddd"

or

ifconfig_alc0_name="eth0"
ifconfig_eth0="SYNCDHCP"

I use dhcpcd as the dhcp client on FreeBSD and Linux more than dhclient. Note that wpa_supplicant can configure wire links as well than wireless ones. So, have only one dhcp client ask the dhcp server for an ip configuration.


----------



## freezr (Jan 10, 2022)

Unfortunately I can do all those tests in the evening but I will, however I found also this about DHCLIENT[1]:


```
EXPIRE : The DHCP client has failed to renew its lease or acquire a new one, and the lease has expired.  The IP address must be relinquished, and all related parameters should be deleted, as in RENEW and REBIND.

FAIL: The DHCP client has been unable to contact any DHCP servers, and any leases that have been tested have not proved to be valid.  The parameters from the last lease tested should be deconfigured.  This can be handled in the same way as EXPIRE
```

Maybe you can force the NIC to "reset" internally and get a proper address...
Not sure I am just "brainstorming as noob"...

[1]https://www.unix.com/man-page/FreeBSD/8/dhclient-script/[/code]


----------



## jbo (Jan 10, 2022)

I don't think that you'll get anything out of messing with DHCP as you stated earlier that networking is not working either if you assign a static IP. And before all of that: If ARP is not working there's no point in trying to mess with the IP layer at all. Check whether ARP is doing the its thing first.


----------



## freezr (Jan 10, 2022)

jbodenmann said:


> so the device itself is *always* showing up properly when you boot into FreeBSD? As in: You *always* see alc0 showing up under `ifconfig`?
> 
> I assume you already tried the "_have you turned it off and on again?"_ approach: `ifconfig alc0 down` `ifconfig alc0 up`.
> Also what Zirias said earlier: What about proper cold boots? What behavior are you observing then?



During the boot time the interface il properly loaded, the order is Up, Down, Up, then is configured and start the DHCP lease process. It hangs for a while since *can't get the DHCP offer*.

Doing "down/up" and then "dhclient alc0" doesn't work, even using the "/etc/nestart" helps to fix it. Simply it can't configure the DHCP.

I think I already tried this:


```
ifconfig_alc0_name="eth0"
ifconfig_eth0="SYNCDHCP"
```

But it didn't work out, but I can try again.

What do you mean with cold boots?

Thanks for all your help!

TGL


----------



## covacat (Jan 10, 2022)

when it does not work can you see any traffic thats not sent by it with tcpdump ?
also try to force media to 100basetx


----------



## Logicien (Jan 10, 2022)

Reboot can leave the firmware of a card in the state of the precedent operating system and conflict with the one you are using. Cold boot preceeded by poweroff prevent this. Even remove the pile, the battery and the power cable can help to have the desire cold boot with the router reset. If there is a setup who always work in most systems it is to configure a wire network card.

Because it work on other systems it must be a configuration problem on the router and/or FreeBSD. I have upgrade my RJ45 cables from Cat 5 to Cat 6 recently.


----------



## jbo (Jan 10, 2022)

tgl You keep stating _"doesn't work"_ but we have yet to learn what that actually means. Please provide more verbose information. If the program in question (i.e. `dhclient`) doesn't yield any useful messages you might want to look into the various log files.



tgl said:


> What do you mean with cold boots?


Turn the computer off completely (removing all power). This is merely to ensure that there is no "foreign" firmware loaded onto the device (i.e. from the Linux driver).


----------



## freezr (Jan 10, 2022)

Hi guys,

I apology for the improper use of "this doesn't work", this my limitation about how much I understand the networking...

Actually the card works and it is recognized however hangs to get an IP through the DHCP service.


----------



## jbo (Jan 11, 2022)

If the card is up and running (and ethernet cable connected), do you get any output from running this? --> `tcpdump -i alc0`?


----------



## freezr (Jan 11, 2022)

jbodenmann

the cold boot worked, but it is not really ideal.


```
tcpdump -i alc0
19:41:25.441866 IP a23-54-149-128.deploy.static.akamaitechnologies.com.https > 10.0.0.113.47100: Flags [.], seq 247387:248835, ack 9182, win 441, options [nop,nop,TS val 3735202666 ecr 3438550869], length 1448
19:41:25.441876 IP a23-54-149-128.deploy.static.akamaitechnologies.com.https > 10.0.0.113.47100: Flags [P.], seq 248835:249127, ack 9182, win 441, options [nop,nop,TS val 3735202666 ecr 3438550869], length 292
19:41:25.441881 IP 10.0.0.113.47100 > a23-54-149-128.deploy.static.akamaitechnologies.com.https: Flags [.], ack 249127, win 7769, options [nop,nop,TS val 3438550914 ecr 3735202666], length 0
```


----------



## jbo (Jan 11, 2022)

Next time it doesn't work, check the output of `tcpdump -i alc0` again and post it here.
Basically what `tcpdump` shows you is traffic on that interface. If you get no output at all there it means that something is wrong / not-working on a level where messing with DHCP is not gonna help you at all to track down the problem.


----------



## sko (Jan 11, 2022)

Does FreeBSD actually receive DHCP replies?

From alc(4):


> All LOMs supported by the alc driver have TCP/UDP/IP checksum offload for
> transmit, TCP segmentation offload (TSO), hardware VLAN tag
> stripping/insertion features, Wake On Lan (WOL) and an interrupt
> moderation mechanism as well as a 64-bit *multicast hash filter.*



I've once seen one of those "pseudo-intelligent" gaming NICs filtering out a lot of (sometimes important!) traffic (even ARP!) so the OS/services never received what they were waiting for. If the vendor offers some kind of firmware without any "acceleration"-snakeoil enabled, use that!

Wild guess: The firmware doesn't get reset on 'warm'-reboots and filters DHCP packets (or ARP?) and may prevent the dhclient from acquiring a lease. Run `tcpdump` and filter for ports 67/68 to see what FreeBSD is sending out and receiving in reply. Depending on what you use as a DHCP server you might also run a quick `tcpdump` on that to see if it receives and answers the requests.

And just to cancel out those edge cases:
Any chance you are using the ISPs router in pass-through-mode to acquire a globally routable IP? Or have one of those rip-off plans where you are only allowed to use a specific number of end devices?
In both cases the DHCP is handled by your ISP and might block/ignore valid DHCP requests due to arbitrary limitations. (I've seen that with pass-through on Kabel Deutschland / Vodafone Cable lines here in Germany. Can be fixed by nagging them enough, at least on business plans)


----------



## freezr (Jan 11, 2022)

Hi guys thank you very much for helping me with this...

With the laptop several hours turned off, FreeBSD started properly including the DHCP.

This is what I got with `tcpdumb -vi alc0` when it didn't get the DHCP address:


```
08:14:29.284246 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA), bad cksum 0 (->3fa)!)
    0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 to_ex, 0 source(s)]
08:14:29.695928 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
08:14:30.695264 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
08:14:31.695271 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
08:14:33.884502 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::82fa:5bff:fe28:3669 > ff02::1:ff7b:246a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::3a5f:66ff:fe7b:246a
      source link-address option (1), length 8 (1): 80:fa:5b:28:36:69
[...]
```

It looks like Linux leaves the card in a state that is unusable for FreeBSD but not the contrary. But this is really doesn't surprise me anymore, for the Linux folks computers start with Windows and end with Linux...


----------



## sko (Jan 11, 2022)

There is no DHCP discovery/request in those logs. Of course you should (re)start dhclient on that interface after starting the tcpdump if you want to monitor what is going on DHCP-wise...  also what is the output of dhclient(8) if started manually on alc0?


----------



## freezr (Jan 11, 2022)

Got it, I'll try in the evening also providing other logs...


----------



## freezr (Jan 12, 2022)

At least I got the wifi working...

Anyway these are the commands I run when *tcpdump* was listening:

```
$ doas service netif restart
Stopping dhclient.
Waiting for PIDS: 7529.
Stopping wpa_supplicant.
Waiting for PIDS: 91895.
Stopping Network: lo0 alc0 wlan0.
lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
alc0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    media: Ethernet autoselect
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    groups: wlan
    ssid "" channel 1 (2412 MHz 11b)
    regdomain FCC country US authmode OPEN privacy OFF txpower 30
    bmiss 10 scanvalid 60 wme bintval 0
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Destroyed wlan(4) interfaces: wlan0.
Created wlan(4) interfaces: wlan0.
Starting wpa_supplicant.
Starting Network: lo0 alc0 wlan0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
alc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    inet6 fe80::82fa:5bff:fe28:3669%alc0 prefixlen 64 scopeid 0x1
    media: Ethernet autoselect (none)
    status: no carrier
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    groups: wlan
    ssid "" channel 1 (2412 MHz 11b)
    regdomain FCC country US authmode OPEN privacy OFF txpower 30
    bmiss 10 scanvalid 60 wme bintval 0
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
$ doas dhclient alc0
dhclient already running, pid: 62608.
exiting.
$ doas ifconfig alc0 down
doas ifconfig alc0 up
$ doas dhclient alc0
DHCPREQUEST on alc0 to 255.255.255.255 port 67
DHCPREQUEST on alc0 to 255.255.255.255 port 67
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 7
No DHCPOFFERS received.
Trying recorded lease 10.0.0.113
No working leases in persistent database - sleeping.
```

And this was the *tcpdump* output:


```
$ doas tcpdump -i alc0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on alc0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:57:05.924627 IP6 :: > ff02::1:ff28:3669: ICMP6, neighbor solicitation, who has fe80::82fa:5bff:fe28:3669, length 32
05:57:05.924631 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
05:57:05.924633 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88
05:57:05.924634 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:11.977078 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:21.985877 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:25.014066 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:28.060274 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:31.073958 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:36.078292 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:44.178095 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:57:52.209334 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:03.277107 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:30.562620 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:30.562624 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
05:58:30.562625 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
05:58:30.562626 IP6 :: > ff02::1:ff28:3669: ICMP6, neighbor solicitation, who has fe80::82fa:5bff:fe28:3669, length 32
05:58:30.562627 IP6 fe80::82fa:5bff:fe28:3669 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
05:58:30.562628 IP6 fe80::82fa:5bff:fe28:3669 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
05:58:30.562629 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:50.563862 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:58:58.564939 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:07.633037 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:19.634518 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:35.705091 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:44.728354 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:fa:5b:28:36:69 (oui Unknown), length 300
05:59:51.787359 ARP, Request who-has 10.0.0.113 tell 10.0.0.113, length 28
05:59:52.834260 ARP, Request who-has 10.0.0.1 tell 10.0.0.113, length 28
^C
28 packets captured
28 packets received by filter
0 packets dropped by kernel
```


----------



## covacat (Jan 12, 2022)

try to ifconfig alc0 down and up and change media / media-opt (this will trigger some reset/init code in the driver)


----------



## sko (Jan 12, 2022)

tgl said:


> At least I got the wifi working...


Your `ifconfig` output tells another story...



tgl said:


> media: Ethernet autoselect (none)



There isn't even a working link on that interface after you restarted netif (for what??)

Your tcpdump output shows that you don't have *any* incoming traffic on that interface the problem seems to be further down the stack...
Have you tried a different cable? What switch are you using?

Can you verify that you actually get a working link (i.e. "status: active") on that interface at all?
What media type is negotiated when you have a working link? Check the ifconfig output from your linux install. If the link is anything but 1000baseT /w full duplex, try another cable and/or switchport and/or switch.

If other devices/NICs work with that cable and on that switchport; dump that NIC and just get one with an intel chipset (basically any pro/1000 will 'just work'™)


----------



## freezr (Jan 12, 2022)

sko said:


> Your `ifconfig` output tells another story...



I got the wifi working with both networkmgr and wifimgr... 



sko said:


> There isn't even a working link on that interface after you restarted netif (for what??)







sko said:


> Your tcpdump output shows that you don't have *any* incoming traffic on that interface the problem seems to be further down the stack...
> Have you tried a different cable? What switch are you using?



No I haven't, I think that is only cable I have enough long to reach my desktop. It comes directly from the Comcast/Arris Modem-router-wifi...



sko said:


> Can you verify that you actually get a working link (i.e. "status: active") on that interface at all?
> What media type is negotiated when you have a working link? Check the ifconfig output from your linux install. If the link is anything but 1000baseT /w full duplex, try another cable and/or switchport and/or switch.



I'll check later what media type Linux is using.


sko said:


> If other devices/NICs work with that cable and on that switchport; dump that NIC and just get one with an intel chipset (basically any pro/1000 will 'just work'™)



This is a laptop, it has a Thunderbolt port though; anyway a cold boot makes the NIC negotiates properly the DHCP lease.

I am tempted to open a bug on the Linux side and saying the driver doesn't reset the card properly making impossible to get a DHCP address on FreeBSD...


----------



## sko (Jan 12, 2022)

tgl said:


> I got the wifi working with both networkmgr and wifimgr...


The previous output of ifconfig you posted didn't show a working configuration for wlan0 (ip 0.0.0.0 and no carrier)




> anyway a cold boot makes the NIC negotiates properly the DHCP lease.


Can you show us such a working state? Given that there was not a single incoming packet in your tcpdump, not even ARP or multicast packages that usually appear quite frequent on every LAN, makes it hard to believe that there is even a link present...

Again: make 100% sure your physical link is OK. Plug your cable out/in several (10) times and if you don't get a working link ("status: active" and "1000baseT <full-duplex>" media) within ~3 seconds every time, then replace that cable! Way too often there are hours wasted troubleshooting services or a network when the culprit is just a wonky cable with a bad connection on 1 or 2 wires...

If - and ONLY if - your link is stable and reliable it makes sense to diagnose anything further up the stack (like DHCP). If you confirmed your link is OK, but you don't get a DHCP lease, try a static IP configuration and always monitor what is going in and out of that interface (tcpdump is your friend!)


----------



## freezr (Jan 12, 2022)

sko said:


> The previous output of ifconfig you posted didn't show a working configuration for wlan0 (ip 0.0.0.0 and no carrier)
> 
> Can you show us such a working state? Given that there was not a single incoming packet in your tcpdump, not even ARP or multicast packages that usually appear quite frequent on every LAN, makes it hard to believe that there is even a link present...
> 
> ...



Sure I will, however right before the logs I posted from FreeBSD through the wifi  , I was setting up Zoom on Linux and the connection was working fine...

I am pretty sure I bought any gigabite ethernet cable in a brick-and-mortar store ten years ago, if you have any recommendation to buy a good cable please let me know, thanks!

TGL


----------



## jbo (Jan 12, 2022)

tgl said:


> Sure I will, however right before the logs I posted from FreeBSD through the wifi  , I was setting up Zoom on Linux and the connection was working fine...


We don't doubt that you're telling the truth. We are merely asserting that the information you provide does not align with what you're saying. This makes it difficult to be helpful in any meaningful way.


----------



## freezr (Jan 12, 2022)

jbodenmann said:


> We don't doubt that you're telling the truth. We are merely asserting that the information you provide does not align with what you're saying. This makes it difficult to be helpful in any meaningful way.



Maybe `wpa_supplicant` and `ifconfig` don't talk to each other...


----------



## freezr (Jan 14, 2022)

Linux configuration:


```
uname -a && lsb_release -a
Linux dad-devuan 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux
No LSB modules are available.
Distributor ID:    Devuan
Description:    Devuan GNU/Linux 4 (chimaera)
Release:    4
Codename:    chimaera
```


```
$ lspci |grep -i eth
3b:00.0 Ethernet controller: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller (rev 10)
```


```
$ sudo ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 80:fa:5b:28:36:69 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.113/24 brd 10.0.0.255 scope global dynamic noprefixroute eth0
       valid_lft 172749sec preferred_lft 172749sec
    inet6 2601:586:4a00:2050::17fb/128 scope global dynamic noprefixroute
       valid_lft 604749sec preferred_lft 604749sec
    inet6 fe80::82fa:5bff:fe28:3669/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether de:7b:b1:d0:0f:a7 brd ff:ff:ff:ff:ff:ff permaddr a4:34:d9:64:f8:ca
```


```
sudo ethtool eth0
Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: 1000Mb/s
    Duplex: Full
    Auto-negotiation: on
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    MDI-X: Unknown
        Current message level: 0x000060e4 (24804)
                               link ifup rx_err tx_err hw wol
    Link detected: yes
```

Anyway couldn't understand what kind of "media" the NIC is using on Linux.


----------



## freezr (Jan 14, 2022)

Once again I reboot into FreeBSD after Linux and DHCP didn't get the IP:


```
ifconfig
alc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    groups: wlan
    ssid "" channel 1 (2412 MHz 11b)
    regdomain FCC country US authmode OPEN privacy OFF txpower 30
    bmiss 10 scanvalid 60 wme bintval 0
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
```

I raised down the ethernet adapter and raised up the wifi one:


```
doas ifconfig alc0 down
doas ifconfig wlan0 up
```

Used the wifi to connect to my router, this time it is showed up correctly:


```
ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    inet 10.0.0.87 netmask 0xffffff00 broadcast 10.0.0.255
    groups: wlan
    ssid comcast-wireless channel 11 (2462 MHz 11g) bssid dc:fe:07:78:26:58
    regdomain FCC country US authmode WPA2/802.11i privacy ON
    deftxkey UNDEF TKIP 3:128-bit txpower 30 bmiss 10 scanvalid 60
    protmode CTS wme roaming MANUAL
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11g
    status: associated
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
```

Now I am going to reboot the PC again and see if by getting the IP with the WiFi will reset the alc0 card properly.


----------



## freezr (Jan 14, 2022)

It didn't change anything:


```
alc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    inet 10.0.0.87 netmask 0xffffff00 broadcast 10.0.0.255
    groups: wlan
    ssid Ste-and-Ste-wireless channel 11 (2462 MHz 11g) bssid dc:fe:07:78:26:58
    regdomain FCC country US authmode WPA2/802.11i privacy ON
    deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 30 bmiss 10
    scanvalid 60 protmode CTS wme roaming MANUAL
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11g
    status: associated
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
```

I put again tcpdump to listen, in the meantime I performed the following actions and uplugged/plugged the cable a bunch of time:


```
$ doas /etc/rc.d/dhclient stop alc0
Stopping dhclient.
Waiting for PIDS: 59318.
$ doas /etc/rc.d/dhclient start alc0
Starting dhclient.
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 17
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
$ doas ifconfig alc0
alc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
$ doas /etc/netstart
Setting hostuuid: 285bfa80-6936-0000-0000-000000000000.
Setting hostid: 0x293deffa.
Setting hostname: dad-bsd.
wpa_supplicant already running?  (pid=6256).
Starting Network: lo0 alc0 wlan0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
alc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 80:fa:5b:28:36:69
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
wlan0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    inet 10.0.0.87 netmask 0xffffff00 broadcast 10.0.0.255
    groups: wlan
    ssid "" channel 11 (2462 MHz 11g)
    regdomain FCC country US authmode WPA2/802.11i privacy ON
    deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 30 bmiss 10
    scanvalid 60 protmode CTS wme roaming MANUAL
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1 fib 0: route already in table
add net ff02::: gateway ::1 fib 0: route already in table
add net ::ffff:0.0.0.0: gateway ::1 fib 0: route already in table
add net ::0.0.0.0: gateway ::1 fib 0: route already in table
$ doas /etc/rc.d/dhclient restart alc0
Stopping dhclient.
Waiting for PIDS: 91737.
Starting dhclient.
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 17
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
$ doas ifconfig alc0 down
$ doas ifconfig alc0 up
$ doas /etc/rc.d/dhclient restart alc0
Stopping dhclient.
Waiting for PIDS: 10758.
Starting dhclient.
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on alc0 to 255.255.255.255 port 67 interval 14
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
```

_The log in in attachment._

The wifi works well without issue:


```
$ doas ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether a4:34:d9:64:f8:ca
    inet 10.0.0.87 netmask 0xffffff00 broadcast 10.0.0.255
    groups: wlan
    ssid comcast-wireless channel 11 (2462 MHz 11g) bssid dc:fe:07:78:26:58
    regdomain FCC country US authmode WPA2/802.11i privacy ON
    deftxkey UNDEF TKIP 2:128-bit txpower 30 bmiss 10 scanvalid 60
    protmode CTS wme roaming MANUAL
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g
    status: associated
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
```


```
$ doas  tcpdump -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:59:50.403669 IP 10.0.0.1 > all-systems.mcast.net: igmp query v3 [max resp time 1.0s]
01:59:50.404232 IP 10.0.0.87.20832 > cdns01.comcast.net.domain: 55458+ PTR? 1.0.0.10.in-addr.arpa. (39)
01:59:50.419254 IP cdns01.comcast.net.domain > 10.0.0.87.20832: 55458 NXDomain 0/0/0 (39)
01:59:50.419416 IP 10.0.0.87.16091 > cdns01.comcast.net.domain: 60746+ PTR? 1.0.0.224.in-addr.arpa. (40)
01:59:50.435220 IP cdns01.comcast.net.domain > 10.0.0.87.16091: 60746 1/0/0 PTR all-systems.mcast.net. (75)
01:59:50.435428 IP 10.0.0.87.13765 > cdns01.comcast.net.domain: 52140+ PTR? 87.0.0.10.in-addr.arpa. (40)
01:59:50.476916 IP cdns01.comcast.net.domain > 10.0.0.87.13765: 52140 NXDomain 0/0/0 (40)
01:59:50.477066 IP 10.0.0.87.52138 > cdns01.comcast.net.domain: 2826+ PTR? 75.75.75.75.in-addr.arpa. (42)
01:59:50.493684 IP cdns01.comcast.net.domain > 10.0.0.87.52138: 2826 1/0/0 PTR cdns01.comcast.net. (74)
01:59:51.325352 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
01:59:51.325549 IP 10.0.0.87.15826 > cdns01.comcast.net.domain: 2887+ PTR? 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
01:59:51.342216 IP cdns01.comcast.net.domain > 10.0.0.87.15826: 2887 NXDomain 0/1/0 (154)
01:59:54.294986 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
01:59:57.366992 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
02:00:00.439008 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
02:00:03.408615 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
02:00:06.480619 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
02:00:09.450407 IP6 fe80::3a5f:66ff:fe7b:246a > ff02::1: ICMP6, router advertisement, length 120
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel
```

5/6 hours should be enough to make a cold boot and having the alc0 adapter able to work properly...


----------



## freezr (Jan 15, 2022)

I cannot say this is solved but at least after a while with the laptop turned off when you reboot the ethernet connection works as expected, and when I have to use both OSes I will have the back-up offered by the WiFi...
It is awkward but at least I can get internet...


----------



## ct85711 (Jan 15, 2022)

One thing that you could also do; is completely skip the dhcp portion is try just configuring a static ip address (and set the default gateway and dns servers).  The main thing on that, is more of setting an ip address that it won't/very unlikely assign (like 220, something at the end of normal range that the chances of it using those address with is unlikely unless you have a large network).

Most commonly, .1 is often the router/modem and default gateway, and 254 is used to an lesser extent.  Of course 255 is the broadcast, so can't be used.  Outside of that, a lot of consumer routers often start the DHCP range at 100+.  Beyond that, DHCP generally doesn't assign a random address in it's range, it works in sequential order (with an limited history built in).


----------



## Terry_Kennedy (Jan 21, 2022)

I think that what is going on is that Linux is putting the MII / PHY in a state that neither the BIOS nor the FreeBSD driver can overcome. If it always works from a cold power-on it isn't the DHCP server or the cable. Arguably, it is the job of the BIOS / card firmware to get things back to a known state before loading any operating system, but that isn't happening.

If your system has options for UEFI vs. "legacy", you could try switching (note that this may involve bootblocks, EFI partitions and even less savory things). If it has an option for "fast reboot", you could try switching that to the other setting. If Linux has something similar to FreeBSD's "hw.acpi.handle_reboot" or "hw.acpi.disable_on_reboot" you could try those to see if Linux leaves the controller in a more usable state on a reboot. Another thing to try is enabling PXE booting in the card's setup, if it has that option. That last suggestion _probably_ won't do anything because netboot will only be tried if booting from disk doesn't work. But there is a possibility that some card initialization will happen earlier on and clear whatever is causing the card to not receive packets.

Other than that, you're probably going to need to involve a FreeBSD developer. That probably means opening a PR since most developers don't read these forums looking for things to fix. Better that they spend time coding.


----------



## freezr (Jan 21, 2022)

ct85711 said:


> One thing that you could also do; is completely skip the dhcp portion is try just configuring a static ip address (and set the default gateway and dns servers).  The main thing on that, is more of setting an ip address that it won't/very unlikely assign (like 220, something at the end of normal range that the chances of it using those address with is unlikely unless you have a large network).
> 
> Most commonly, .1 is often the router/modem and default gateway, and 254 is used to an lesser extent.  Of course 255 is the broadcast, so can't be used.  Outside of that, a lot of consumer routers often start the DHCP range at 100+.  Beyond that, DHCP generally doesn't assign a random address in it's range, it works in sequential order (with an limited history built in).


Static setup didn't work as well


----------



## freezr (Jan 21, 2022)

Terry_Kennedy said:


> I think that what is going on is that Linux is putting the MII / PHY in a state that neither the BIOS nor the FreeBSD driver can overcome. If it always works from a cold power-on it isn't the DHCP server or the cable. Arguably, it is the job of the BIOS / card firmware to get things back to a known state before loading any operating system, but that isn't happening.
> 
> If your system has options for UEFI vs. "legacy", you could try switching (note that this may involve bootblocks, EFI partitions and even less savory things). If it has an option for "fast reboot", you could try switching that to the other setting. If Linux has something similar to FreeBSD's "hw.acpi.handle_reboot" or "hw.acpi.disable_on_reboot" you could try those to see if Linux leaves the controller in a more usable state on a reboot. Another thing to try is enabling PXE booting in the card's setup, if it has that option. That last suggestion _probably_ won't do anything because netboot will only be tried if booting from disk doesn't work. But there is a possibility that some card initialization will happen earlier on and clear whatever is causing the card to not receive packets.
> 
> Other than that, you're probably going to need to involve a FreeBSD developer. That probably means opening a PR since most developers don't read these forums looking for things to fix. Better that they spend time coding.



Actually the laptop support legacy mode and I think I can disable PXE booting. However opening a bug report for a ten years old laptop is not really worth!

Thanks!


----------

