# Setting up ethernet device Atheros AR8161



## Boson (Apr 23, 2017)

Hi! 

I installed FreeBSD 11.0 today and cannot get ethernet to work. 

My ethernet device: 
Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10) 

The alc(4) man page states that the device is supported. 

On BSD startup, dhclient fails to get an IP from the router (DHCP works fine for Windows and Linux on the same machine). 

ifconfig output: 

```
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 90:2b:34:d6:10:89 
    inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255  
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> 
    media: Ethernet autoselect (1000baseT <full-duplex>) 
    status: active
```
I tried to set a static IP by modifying /etc/rc.conf: 

```
#ifconfig_alc0="DHCP" 
ifconfig_alc0="inet 192.168.178.34 netmask 255.255.255.0" 
defaultrouter="192.168.178.1"
```
This does not work, too. ifconfig sets the new IP, but i cannot ping anything on the local network (timeout) or the internet (no route) and the computer cannot be pinged by other computers on the network (timeout).

Any idea what goes wrong here? 

Best regards, 
Dirk


----------



## balanga (Apr 24, 2017)

I'd suggest reinstalling using FreeBSD-11.0-RELEASE-amd64-mini-memstick.img. That would configure your ethernet automatically....

Just my opinion... I'm assuming that FreeBSD would recognise your NIC. It always seems to work for me.


----------



## ralphbsz (Apr 24, 2017)

My theory: You don't have a hardware support or driver problem; you have a networking problem.  Please look through dmesg for all messages relating to this ethernet device.  Are there any error messages (or messages that might indicate errors, even if they aren't worded that way)?  If not, we should probably assume for the time being that the driver worked fine.

The first output from ifconfig above looks like your interface is correctly configured, and waiting for DHCP to get an address.  When you say "dhclient fails to get", do you mean that there are any error messages, or do you mean that DHCP configuration just doesn't succeed?  Are you sure you have a functioning DHCP server on your network?  Are you sure you have the DHCP client on this machine configured correctly?

In particular the fact that you are getting "no route" errors indicates that your network is misconfigured.  You do know that the settings in /etc/rc.conf are applied at boot time?  To perform these settings at runtime, you have to enter the equivalent `ifconfig` and `route` commands.

To verify what's going on, try the following: From another computer that's also connected to the same physical network, run `tcpdump`, and look for the communication between the machine with the problem and the "server" machine.  In the DHCP case, you should see all the DHCP packets going back and forth.  In the static case, you should see arp packets, followed by the ping and ping response.


----------



## Boson (Apr 25, 2017)

I now tried FreeBSD-10.3, 11.0 and 12.0-current. Neiter of them work.

The DHCP server is working properly, because on the same computer i run Windows and Linux, and these OSes successfully get their IPs from the DHCP server.
I took an old PC and connected it to the same ethernet switch and installed FreeBSD 11 on it. DHCP is working there, too. So i can be pretty sure there is no hardware problem, and the DHCP server is configured correctly.

On this old PC with FreeBSD I used tcpdump to monitor the traffic between the other PC and the router with the DHCP server.

`# tcpdump -vv portrange 67-68

13:49:35.425459 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 90:2b:34:d6:10:89 (oui Unknown), length 300, xid 0x988fd763, Flags [none] (0x0000)
     Client-Ethernet-Address 90:2b:34:d6:10:89 (oui Unknown)
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Discover
       Client-ID Option 61, length 7: ether 90:2b:34:d6:10:89
       Hostname Option 12, length 7: "desktop"
       Parameter-Request Option 55, length 9:
         Subnet-Mask, BR, Time-Zone, Classless-Static-Route
         Default-Gateway, Domain-Name, Domain-Name-Server, Hostname
         Option 119`

A "Discover" message is sent, but I see no answer.

For comparison, this is what tcpdump monitors, when Arch Linux is booting up on the same machine:

`18:59:27.142329 IP (tos 0x0, ttl 64, id 47460, offset 0, flags [none], proto UDP (17), length 388)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 90:2b:34:d6:10:89 (oui Unknown), length 360, xid 0xe5b295fc, Flags [none] (0x0000)
     Client-Ethernet-Address 90:2b:34:d6:10:89 (oui Unknown)
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Request
       Client-ID Option 61, length 19: hardware-type 255, 34:d6:10:89:00:01:00:01:20:8f:8a:7e:90:2b:34:d6:10:89
       Requested-IP Option 50, length 4: desktop.fritz.box
       MSZ Option 57, length 2: 1472
       Vendor-Class Option 60, length 54: "dhcpcd-6.11.5:Linux-4.10.11-1-ARCH:x86_64:GenuineIntel"
       Hostname Option 12, length 7: "desktop"
       T145 Option 145, length 1: 1
       Parameter-Request Option 55, length 15:
         Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway
         Domain-Name-Server, Hostname, Domain-Name, MTU
         BR, NTP, Lease-Time, Server-ID
         RN, RB, Option 119`

Arch Linux sends a "request" message, not a "discover" message. But tcpdump is not showing an answer, too.
It seems that tcpdump is only catching the broadcast messages.

Am I using tcpdump wrong? Or is it possible that the old PC cannot monitor the answers of the router because of the ethernet switch they are connected to?

EDIT:
When i use a static IP and try to ping the DHCP server, the old PC running tcpdump does not see any ICMP message.


----------



## ralphbsz (Apr 25, 2017)

A: If you don't see the reply in the ArchLinux case, but DHCP works, something is wrong with your tcpdump invocation.  I'm not a tcpdump expert, and I wonder about the port range.  What happens if you use just tcpdump without any options?

B: If you use static IP, and try to ping any machine that you have not communicated with recently, then tcpdump should be showing you ARP packets before the ICMP packet.  If you don't see those, then either your static IP is set up wrong, or (more likely) tcpdump isn't working perfectly.

Let me ask a really stupid question: Could it be that you are on a switched network, and only see broadcast packets and point-to-point communication that includes the host running tcpdump?  Unfortunately, with modern ethernet hubs all being intelligent, that might always happen.  Perhaps you need to run tcpdump on either the sick node (the one you are switching between ArchLinux and FreeBSD) or on the DHCP server to see all packets.


----------



## Boson (Apr 26, 2017)

The problem seems to be that the computer does not receive any ARP packages.

I set up the PC with the non-functioning ethernet (now calling it "A") with a static IP (192.168.178.100). The other PC (now calling it OLD) has IP 192.168.178.47. When A pings the broadcast address (192.168.178.255) while running tcpdump on both, both computers can see that A pings the broadcast address:

`20:03:10.862161 IP 192.168.178.100 > 192.168.178.255: ICMP echo request, id 23811, seq 74, length 64`

When A pings OLD directly, OLD only receives an ARP requests, but no ICMP messages:

`20:04:18.950391 ARP, Request who-has 192.168.178.47 tell 192.168.178.100, length 46
20:04:19.974113 ARP, Request who-has 192.168.178.47 tell 192.168.178.100, length 46
20:04:20.985302 ARP, Request who-has 192.168.178.47 tell 192.168.178.100, length 46`

But A does not receive the ARP reply from OLD. ping outputs:
`ping: sendto: Host is down`

Looks like a driver issue on the ARP layer to me...


----------



## ralphbsz (Apr 27, 2017)

Could be, but sounds very unlikely.  At the low packet level (which is where tcpdump hooks in), an ARP packet is just a packet.  It would take extraordinary smarts for the hardware or low-level code to selectively destroy ARP packets.

Unfortunately, I don't know a better to debug this.  You are seeing ARP requests and no ARP replies; that's broken.


----------



## james122333 (May 11, 2017)

My new notebook with QCA8171 Gigabit Ethernet card doesn't work either...
PPP connection returned "alc0 DMA write error! --resetting"

UEFI?  But I boot FreeBSD in legacy bios mode...


----------



## james122333 (May 12, 2017)

OpenSUSE works well in legacy bios mode...


----------



## james122333 (May 14, 2017)

I've thought about it for a long time and finally found the following lines in /usr/src/sys/dev/alc/if_alc.c a while ago

```
/*
        * Force maximum payload size to 128 bytes for
        * E2200/E2400/E2500.
        * Otherwise it triggers DMA write error.
        */
       if ((sc->alc_flags & ALC_FLAG_E2X00) != 0)
           sc->alc_dma_wr_burst = 0;
```
By adding the same last two lines (with modified if condition) and rebuilding the whole system, it works, but I don't know if it exactly works fine or not.


----------

