ale0 gets no carrier

[Marius Nünnerich]

On Thu, Oct 22, 2009 at 21:38, Pyun YongHyeon <pyunyh at gmail.com> wrote:
> On Thu, Oct 22, 2009 at 09:18:15PM +0200, Milan Obuch wrote:
>> On Thursday 22 October 2009 21:05:39 Mike Tancsa wrote:
>> > At 02:22 PM 10/22/2009, Marius N?nnerich wrote:
>> > >Hi Pyun, all,
>> > >
>> > >today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros
>> > > nic: ale0 at pci0:2:0:0:        class=0x020000 card=0x831c1043
>> > > chip=0x10261969 rev=0xb0 hdr=0x00
>> > >     vendor     = 'Attansic (Now owned by Atheros)'
>> > >     device     = 'PCI-E ETHERNET CONTROLLER  (AR8121/AR8113 )'
>> > >     class      = network
>> > >     subclass   = ethernet
>> > >
>> > >ale0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> > >
>> > >options=319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL
>> > >_MAGIC> ether 00:24:8c:a4:0a:b3
>> > >         media: Ethernet autoselect (none)
>> > >         status: no carrier
>> > >
>> > >The nic gets no carrier at all. I tried against two known-working nics
>> > >with a cross-over cable and against a dsl-modem.
>> > >Any idea what to try? Will happily test patches.
>> >
>> > Did you try and give it an IP address so that its
>> > "UP" ? Some nics dont seem to have carrier until
>> > you put it in UP state with an IP. Try something simple like
>> > ifconfig ale0 192.168.255.254/30
>> >
>>
>> In my case
>>
>> ale0 at pci0:2:0:0:        class=0x020000 card=0x831c1043 chip=0x10261969
>> rev=0xb0 hdr=0x00
>>     vendor     = 'Attansic (Now owned by Atheros)'
>>     device     = 'PCI-E ETHERNET CONTROLLER  (AR8121/AR8113 )'
>>     class      = network
>>     subclass   = ethernet
>>
>> (exactly the same, as I can see) when configuring interface manually, I need
>> to do 'ifconfig ale0 up' before I can successfully acquire IP with 'dhclient
>> ale0'. Everything works normally with 'ifconfig_ale0="DHCP"' line
>> in /etc/rc.conf.
>>
>
> This is intended behavior as establishing a link requires
> negotiation with link-partner and the link state could be changed
> after the negotiation. So showing (fake/incorrect) link state
> before UPing the interface wouldn't be correct behavior.

Ok, sounds plausible. It's just that every other nic I have had worked
the other way.