PINE64 - Ethernet Port

Ethernet does not work

Sat, 07 Feb 2026 01:19:42 +0000

I'm using the pine a64 with 512mb of ram. i used like 5 different operating systems and all of them couldn't detect my Ethernet connection. what could be detected was a USB Ethernet dongle, however none of the operating systems had drivers for it. I'm pretty sure there's something broken on the board and wanted advice on confirming that and what to do next. thank you

Ethernet port down afert 1 day

Sat, 12 Nov 2022 12:48:08 +0000

Hi,

I have bought 2 Pine A64+ from Ibood last week.
One of the boards has some trouble with the ethernet connection.

Everything worked just fine, but after 1 day, the network connection was dropped and my board was not accessible anymore.

This is my setup:
Serial number : 410640172333
OS : DietPi
Installed software : Webmin, docker, docker-compose

I have tried a new microsd card with a fresh installation of DietPi, but at the installation the system is complaining that there is no internet connection.
I also switched the microsd card with the one that works on the other board.
I have tried a different switch, network cabel, power supply, DHCP / static ip.
Switched the network speed to 100.
But nothing did the trick.

My network contoller (Unifi) says there is a device connected, but the device is not accesible

Ibood says i have to take contact by this forum.

So my question is, what can i do to make everything work again.

Kind regards,

Jelle

Rock64: MAC Address is NOT Unique!

Mon, 25 Jan 2021 02:19:24 +0000

I have two Rock64 boards:

One is Version 2 (4GB).
One is Version 3 (4GB).

I've installed DietPi 6.34.3 on both boards. But I'm not able to connect both to the same broadcast domain at the same time because each has board has the same MAC address (86:e0:c0:ea:fa:a9)!

So I started digging around. And I found that...

I'm not able to find the first 3 octets (86:e0:c0) in any OUI databases. But the kernel ring buffer had these entries...

Code:
e1000e: Intel(R) PRO/1000 Network Driver

e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

igb: Intel(R) Gigabit Ethernet Network Driver

igb: Copyright (c) 2007-2014 Intel Corporation.

igbvf: Intel(R) Gigabit Virtual Function Network Driver

...and...

Code:
RTL8211F Gigabit Ethernet stmmac-0:00: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:00, irq=POLL)

RTL8211F Gigabit Ethernet stmmac-0:01: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL)

To state the obvious:

The first one appears to be related to an Intel PRO/1000 NIC.
The second one appears to be a Realtek RTL8211 NIC.

I've read a few of Mark's posts on the subject. And I know/believe that...

When setting the MAC address: It should begin with 00:06:dc (i.e., The OUI of Syabas Technology [Amquest]). [ Reference ]
The accepted solution is to specify the MAC address manually in /etc/uEnv.txt using the macaddr= and/or the eth_addr= settings. I may be wrong - But I believe that these settings are now located in /boot/armbianEnv.txt. [ Reference ]

But specifying either one or both has no affect on the MAC address (86:e0:c0:ea:fa:a9)! e.g., Neither setting appears in the Kernel command-line:

Code:
dietpi@DietPi:~$ grep addr  /boot/armbianEnv.txt 

ethaddr=00:06:dc:00:00:01

mac_addr=00:06:dc:00:00:01

dietpi@DietPi:~$ ip add | grep ether | awk '{ print $2 }'

86:e0:c0:ea:fa:a9

dietpi@DietPi:~$ cat /proc/cmdline 

root=UUID=1542112e-4bd9-4f4a-9660-e9405c792736 rootwait rootfstype=ext4  consoleblank=0 loglevel=4 ubootpart=72193746-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u  

dietpi@DietPi:~$ sudo dmesg | grep 'Kernel command line' | sed 's/\[.*\] //'

Kernel command line: root=UUID=1542112e-4bd9-4f4a-9660-e9405c792736 rootwait rootfstype=ext4  consoleblank=0 loglevel=4 ubootpart=72193746-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u

Have I overlooked something besides the solution proposed on the Wiki page? i.e., WNpctool.exe
Is there a solution for folks that don't have MS Windows in their environment? e.g., Linux "purists"

TIA!

ROCK64 keeps connection

Sat, 09 Mar 2019 12:08:24 +0000

Dear reader,

I have a question about my ROCK64 4GB board, but I do not really know where to post the problem, as I think it can fit into multiple categories. So I'm posting here, and someone can move it to another topic if needed

The problem is that I keep losing the ability to SSH into the board from another PC in the network. I've ruled out that it is a problem with the router ports, and the board is configured with a static IP through both netplan and /etc/network/interfaces (didnt really know which one takes precedence so I did both).

This problem occurs when I connect my usb hub with two external harddrives. The hub is externally powered, and functioning as expected (tested on another PC). The board itself is powered with the official 5A power supply.

When not connected to the hub, the board seems to be working fine. I can SSH into it and it stays connected. When I connect the hub and reboot, it takes forever to get a connection to the board. And when it succeeds, I can log in but it disconnects after a short while (not always the same time, but soon after logging in). I use Putty from a Windows machine to connect, but Putty gives no error or messages that it has been disconnected, it just freezes. After this has happened, I can no longer see the board from the connected devices in my router. Then, after a longer time (5 minutes or so) it shows up in the connected devices again. I can then connect again and the same thing happens.

So my thoughts were that the usb hub somehow drains so much power from the board that the ethernet interface cannot be powered sufficiently. I know that harddrives can require a lot of power, especially during spinup, thats why I bought a usb hub with external power supply. Is it possible that this power supply is not powerful enough to power the two harddrives and is trying to take the additional needed power from the board? Or could this problem be due to some other component on the board?

I hope someone can point me in the right direction, and that I have provided enough information to do so. If you need more information or specs, please feel free to ask.

Kind Regards,

Bik

connect 2 network cable to rock64 device.

Tue, 29 May 2018 13:34:40 +0000

hi!
if i weld this:

to my rock64 device, it will be able to connect 2 network cables?
thank's.

Boot needs up to 7 minutes on Ubuntu 16.04

Fri, 10 Mar 2017 08:52:40 +0000

Hi together!

I need help with my Pine64 2GB RAM Board.

The problem is a very long boot time, if ethernet is unplugged. The systems hangs on "[XXXXXXXX] Call trace:".
Nothing else behind this note.
The system boots completely after 4-7 minutes, but only if ethernet is unplugged.
If ethernet is plugged in, the system starts within 1 minute.

It doesn't matter which version of Pine64 I'm using, because I already tried 512 MB, 1 GB and 2 GB of RAM.

Some information about my setup:
- Ubuntu 16.04 with updated kernel and U-Boot via update scripts.
- installed WiFi-/Bluetooth module.
- Static IP address via WiFi in /etc/network/interfaces and router.
- No connection via ethernet, just via WiFi.
- Samsung Evo microsd card.
- Official Pine64 power supply from Pine64 shop.
- Deleted standard MAC address.

Please help me with my little problem.

Best regards
Julian

1Gbps clock sync

Sat, 17 Sep 2016 17:54:58 +0000

I have a 'bad' PINE64+ board, running armbian with legacy kernel, powered via micro-USB AC adapter. NIC and UART0 serial are the only active peripherals. 100Mbps is perfectly fine, but there's a major packet loss at 1Gbps, no need for iperf to tell there's an issue.

VDD33 voltage is between 3.26V and 3.27V, regardless of
- 1Gbps or 100Mbps or 10Mbps link speed
- CPU idle (/sys/class/thermal/thermal_zone0/temp @ 42 degrees) or busy (/sys/class/thermal/thermal_zone0/temp @ 65 degrees)
- 3 different microUSB AC 5V adapters and cables

That voltage is within tolerance range of 2.97V to 3.63V for PHY VDD33 (per PHY DS). PMIC AC input tolerance range is 3.5V to 7V (per PMIC DS), so PHY should be getting conditioned ~3.3V consistently, even when microUSB AC source is used. Unfortunately I don't have a scope to monitor continuously, but if AC-IN voltage drops were affecting 1Gbps communications, I'd expect them to equally affect 100Mbps communications and that is not the case. So the issue with my board doesn't seem to be caused by PHY input voltage fluctuations.

However, there is a noticeable difference in the amount of packet loss with different power sources:
1. laptop USB, so <500mA, 2 feet USB cable
PC -> SBC: 30% loss
SBC -> PC: 36% loss

2. AC 5V/2A adapter, 6 feet USB cable
PC -> SBC: 5% loss
SBC -> PC: 11% loss

3. AC 5V/3A adapter, 3 feet USB cable
PC -> SBC: 15% loss
SBC -> PC: 31% loss

I'd speculate that there's possibly another element sensitive to AC input inconsistencies that might not be conditioned by the PMIC or that may have a narrow tolerance range. Alternatively, PINE64+ PCB layout might not be strictly following guidelines for RTL8211E IC as set forth in PHY DS, resulting in EMI affecting its operation or VDD10 conditioned input being outside of a narrow 0.95V to 1.06V tolerance range.

References:
PHY DS - http://files.pine64.org/doc/datasheet/pine64/rtl8211e(g)-vb(vl)-cg_datasheet_1.6.pdf
PMIC DS - http://files.pine64.org/doc/datasheet/pi...t_V1.0.pdf

So I've fiddled around with EMAC IC and its RGMII interface to PHY IC.

Some findings:
1. MII RXERC = 0 in mii-tool reg dump, supposedly that indicates PHY is not receiving erroneous frames
#mii-tool -vvv
registers for MII PHY 0:
1140 796d 001c c915 01e1 cde1 000d 2001
6801 0300 7800 0000 0000 0000 0000 3000
016e acc2 9f01 0000 8040 1006 4100 2100
0000 8c00 0040 0106 21fc 8038 0123 0000
2. EMAC reports RGMII speed/duplex and clock is consistent with PHY link type

1Gbps/full:
EMAC BASIC_CTL_0:
#devmem2 0x1c30000 w

0x1 = 1Gbps/full
EMAC RGMII_STA:
#devmem2 0x1c300d0 w

0xD = 0b1101 - 1Gbps, 125MHz clock
MII PHY:
#mii-tool -vvv
registers for MII PHY 0:
1140 796d 001c c915 0001 cde1 000f 2001
6801 0200 7800 0000 0000 0000 0000 3000
016e acc2 9f01 6c52 8040 1006 4100 2100
0000 8c00 0040 0106 21fc 8038 0123 0000
100Mbps/full:
EMAC BASIC_CTL_0:
#devmem2 0x1c30000 w

0xD = 100Mbps/full
EMAC RGMII_STA:
#devmem2 0x1c300d0 w

0xB = 0b1011 - 100Mbps, 25MHz clock
MII PHY:
#mii-tool -vvv
registers for MII PHY 0:
1140 796d 001c c915 01e1 cde1 000d 2001
6801 0300 7800 0000 0000 0000 0000 3000
016e acc2 9f01 0000 8040 1006 4100 2100
0000 8c00 0040 0106 21fc 8038 0123 0000

3. EMAC is using internal clock for 1Gbps/125MHz
A64 EMAC_CLK_REG:
#devmem2 0x1c00030 w

clock 0b01 = GMII/RGMII external
clock 0b10 = GMII/RGMII internal (default)
This said, there could be a problem with 125MHz clock sync, required for proper RGMII communication between EMAC and PHY at 1Gbps rate. Judging by latest PCB diagrams, PHY CLK125 is attached to EMAC, presumably to supply 125MHz clock to EMAC, however EMAC's internal clock is enabled (by the EMAC driver?), so EMAC and PHY clocks are not synchronized. However, switching to external clock (supplied by PHY?) results in even higher packet loss, upwards of 80%

I was trying to dump EMAC DMA TX/RX descriptors and buffers to get an idea of whether frames received by PHY make it to EMAC over RGMII and vice versa, but so far didn't manage to access them from userland. I guess it would take to debug EMAC driver to monitor them and accumulate TX/RX frames and errors statistics.

Above is a re-post from my earlier post at armbian forum.

I don't know if my findings are conclusive, but I'd be interested to know if EMAC internal vs. external clock makes a difference on other boards.

Could someone who has a Pine64+ board with working 1Gbps NIC
1. Confirm if EMAC clock is internal on their board?
2. Try switching EMAC clock to external to confirm if that cripples 1Gbps performance?

Clock source change is volatile, can be reverted manuually or by reloading the board, so there's no permanent effect.

It would take to:
a). install devmem2

Code:
# sudo apt-get install devmem2

b). read EMAC register EMAC_CLK_REG at 0x1c00030

Code:
# devmem2 0x1c00030 w

Sample output:
/dev/mem opened.
Memory mapped at address 0x7f88009000.
Value at address 0x1C00030 (0x7f88009030): 0x10C06

c). test ping to default gateway

Code:
# ping `ip route show 0.0.0.0/0 | awk '{print $3}'`

Sample output:
PING 192.168.137.1 (192.168.137.1) 56(84) bytes of data.
64 bytes from 192.168.137.1: icmp_seq=2 ttl=128 time=0.725 ms
64 bytes from 192.168.137.1: icmp_seq=3 ttl=128 time=0.397 ms
64 bytes from 192.168.137.1: icmp_seq=5 ttl=128 time=0.366 ms
64 bytes from 192.168.137.1: icmp_seq=6 ttl=128 time=0.436 ms
64 bytes from 192.168.137.1: icmp_seq=7 ttl=128 time=0.303 ms
^C
--- 192.168.137.1 ping statistics ---
7 packets transmitted, 5 received, 28% packet loss, time 6004ms

d). write EMAC register EMAC_CLK_REG at 0x1c00030

Code:
# devmem2 0x1c00030 w 0x10C05

Sample output:
/dev/mem opened.
Memory mapped at address 0x7f911c2000.
Value at address 0x1C00030 (0x7f911c2030): 0x10C06
Written 0x10C05; readback 0x10C05

e). test ping to default gateway

Code:
# ping `ip route show 0.0.0.0/0 | awk '{print $3}'`

Sample output:
PING 192.168.137.1 (192.168.137.1) 56(84) bytes of data.
64 bytes from 192.168.137.1: icmp_seq=3 ttl=128 time=0.479 ms
64 bytes from 192.168.137.1: icmp_seq=7 ttl=128 time=0.398 ms
64 bytes from 192.168.137.1: icmp_seq=12 ttl=128 time=0.504 ms
^C
--- 192.168.137.1 ping statistics ---
14 packets transmitted, 3 received, 78% packet loss, time 13004ms

f). revert to internal clock

Code:
# devmem2 0x1c00030 w 0x10C06

Sample output:
/dev/mem opened.
Memory mapped at address 0x7f911c2000.
Value at address 0x1C00030 (0x7f911c2030): 0x10C05
Written 0x10C06; readback 0x10C06

Reference:
page 158 of http://files.pine64.org/doc/datasheet/pi...l_V1.0.pdf

Howto test and tune Gigabit Networking (1000M)

Sun, 21 Aug 2016 10:33:12 +0000

Pine64+ and Pine64+2GB have a Gigabit NIC. To actually test the speed of the network interface a few things need to be considered. If you want to test the NIC performance of your Pine64, this thread is for you.

To do any meaningful testing, you need another device which is well known and capable to deliver over 900MBit/s with the cable and switch it is connected to. Also make sure that the network cable you use for the Pine64 is working with Gigabit Network (8 wires twisted pair, Cat5e or Cat6).

It is important to understand that you should test network speed only. If you copy a file to the Pine or something you are testing something completely different.

Furthermore it is important to know the settings of the whole stack involved and always use same / good settings. I added a platform-script at https://github.com/longsleep/build-pine6...network.sh to help with that. Make sure to run this or similar before any testing.

- Make sure you use the latest Kernel. `uname -a`

Code:
root@pine64:~# uname -a

Linux pine64 3.10.102-3-pine64-longsleep #98 SMP PREEMPT Sat Aug 20 22:28:17 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

- Use iperf3. Start it in server mode on your other host (iperf3 -s). iperf 3 exists for essentially all platforms as precompiled binary (https://iperf.fr/iperf-download.php).

- Install iperf3 on your Pine64. `sudo apt-get install iperf3`.

- Run iperf3 in client mode on Pine64 `iperf -c $OTHER_HOST_IP`
This can reach about 800 Mbits/sec

Code:
root@pine64:~# iperf3 -c 192.168.1.111   

Connecting to host 192.168.1.111, port 5201

[  4] local 192.168.1.54 port 33437 connected to 192.168.1.111 port 5201

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd

[  4]   0.00-1.01   sec  99.0 MBytes   825 Mbits/sec    1    168 KBytes       

[  4]   1.01-2.00   sec   100 MBytes   848 Mbits/sec    1    139 KBytes       

[  4]   2.00-3.00   sec   101 MBytes   849 Mbits/sec    0    197 KBytes       

[  4]   3.00-4.00   sec   100 MBytes   841 Mbits/sec    0    235 KBytes       

[  4]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec    3    139 KBytes       

[  4]   5.00-6.00   sec  99.1 MBytes   831 Mbits/sec    2   82.0 KBytes       

[  4]   6.00-7.00   sec  95.4 MBytes   801 Mbits/sec    1    120 KBytes       

[  4]   7.00-8.00   sec  97.7 MBytes   819 Mbits/sec    1    151 KBytes       

[  4]   8.00-9.00   sec  96.8 MBytes   812 Mbits/sec    0    202 KBytes       

[  4]   9.00-10.00  sec   102 MBytes   854 Mbits/sec    1    175 KBytes       

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth       Retr

[  4]   0.00-10.00  sec   990 MBytes   830 Mbits/sec   10             sender

[  4]   0.00-10.00  sec   989 MBytes   829 Mbits/sec                  receiver

- Run iperf3 in client reverse mode on Pine64 `iperf -c $OTHER_HOST_IP -R`
This can reach about 900 Mbits/sec.

Code:
root@pine64:~# iperf3 -c 192.168.1.111 -R

Connecting to host 192.168.1.111, port 5201

Reverse mode, remote host 192.168.1.111 is sending

[  4] local 192.168.1.54 port 33435 connected to 192.168.1.111 port 5201

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-1.00   sec   104 MBytes   873 Mbits/sec                  

[  4]   1.00-2.00   sec   107 MBytes   901 Mbits/sec                  

[  4]   2.00-3.00   sec   106 MBytes   893 Mbits/sec                  

[  4]   3.00-4.00   sec   107 MBytes   901 Mbits/sec                  

[  4]   4.00-5.00   sec   108 MBytes   903 Mbits/sec                  

[  4]   5.00-6.00   sec   105 MBytes   879 Mbits/sec                  

[  4]   6.00-7.00   sec   109 MBytes   912 Mbits/sec                  

[  4]   7.00-8.00   sec   107 MBytes   898 Mbits/sec                  

[  4]   8.00-9.00   sec   107 MBytes   900 Mbits/sec                  

[  4]   9.00-10.00  sec   107 MBytes   895 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-10.00  sec  1.04 GBytes   896 Mbits/sec                  sender

[  4]   0.00-10.00  sec  1.04 GBytes   896 Mbits/sec                  receiver

- To completely max out the Pine64 run iperf 3 in parallel mode (4)
This should be a little faster (combined) than the results from only a single thread.

Code:
root@pine64:~# iperf3 -c 192.168.1.111 -P 4

Connecting to host 192.168.1.111, port 5201

[  4] local 192.168.1.54 port 33439 connected to 192.168.1.111 port 5201

[  6] local 192.168.1.54 port 33440 connected to 192.168.1.111 port 5201

[  8] local 192.168.1.54 port 33441 connected to 192.168.1.111 port 5201

[ 10] local 192.168.1.54 port 33442 connected to 192.168.1.111 port 5201

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd

[  4]   0.00-1.03   sec  26.9 MBytes   219 Mbits/sec    1    107 KBytes       

[  6]   0.00-1.03   sec  26.7 MBytes   218 Mbits/sec    0    209 KBytes       

[  8]   0.00-1.03   sec  26.5 MBytes   216 Mbits/sec    0    212 KBytes       

[ 10]   0.00-1.03   sec  26.4 MBytes   215 Mbits/sec    0    208 KBytes       

[SUM]   0.00-1.03   sec   106 MBytes   868 Mbits/sec    1             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   1.03-2.02   sec  26.2 MBytes   222 Mbits/sec    0    122 KBytes       

[  6]   1.03-2.02   sec  26.2 MBytes   222 Mbits/sec    0    236 KBytes       

[  8]   1.03-2.02   sec  26.2 MBytes   222 Mbits/sec    0    239 KBytes       

[ 10]   1.03-2.02   sec  26.2 MBytes   222 Mbits/sec    0    239 KBytes       

[SUM]   1.03-2.02   sec   105 MBytes   888 Mbits/sec    0             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   2.02-3.02   sec  26.2 MBytes   220 Mbits/sec    1   97.6 KBytes       

[  6]   2.02-3.02   sec  26.2 MBytes   221 Mbits/sec    1    112 KBytes       

[  8]   2.02-3.02   sec  26.2 MBytes   221 Mbits/sec    0    257 KBytes       

[ 10]   2.02-3.02   sec  26.2 MBytes   221 Mbits/sec    0    255 KBytes       

[SUM]   2.02-3.02   sec   105 MBytes   882 Mbits/sec    2             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   3.02-4.02   sec  26.2 MBytes   221 Mbits/sec    0    110 KBytes       

[  6]   3.02-4.02   sec  26.2 MBytes   221 Mbits/sec    0    124 KBytes       

[  8]   3.02-4.02   sec  26.2 MBytes   221 Mbits/sec    0    262 KBytes       

[ 10]   3.02-4.02   sec  26.2 MBytes   221 Mbits/sec    1    109 KBytes       

[SUM]   3.02-4.02   sec   105 MBytes   884 Mbits/sec    1             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   4.02-5.01   sec  26.2 MBytes   222 Mbits/sec    0    122 KBytes       

[  6]   4.02-5.01   sec  26.2 MBytes   222 Mbits/sec    0    130 KBytes       

[  8]   4.02-5.01   sec  26.2 MBytes   222 Mbits/sec    0    269 KBytes       

[ 10]   4.02-5.01   sec  26.2 MBytes   222 Mbits/sec    0    123 KBytes       

[SUM]   4.02-5.01   sec   105 MBytes   887 Mbits/sec    0             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   5.01-6.05   sec  27.5 MBytes   222 Mbits/sec    1    106 KBytes       

[  6]   5.01-6.05   sec  27.5 MBytes   222 Mbits/sec    0    132 KBytes       

[  8]   5.01-6.05   sec  27.5 MBytes   222 Mbits/sec    1   94.7 KBytes       

[ 10]   5.01-6.05   sec  27.5 MBytes   222 Mbits/sec    0    129 KBytes       

[SUM]   5.01-6.05   sec   110 MBytes   889 Mbits/sec    2             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   6.05-7.04   sec  27.0 MBytes   227 Mbits/sec    0    117 KBytes       

[  6]   6.05-7.04   sec  27.9 MBytes   235 Mbits/sec    0    143 KBytes       

[  8]   6.05-7.04   sec  25.8 MBytes   218 Mbits/sec    0    115 KBytes       

[ 10]   6.05-7.04   sec  22.8 MBytes   192 Mbits/sec    2   84.8 KBytes       

[SUM]   6.05-7.04   sec   103 MBytes   872 Mbits/sec    2             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   7.04-8.01   sec  26.1 MBytes   226 Mbits/sec    0    127 KBytes       

[  6]   7.04-8.01   sec  26.2 MBytes   228 Mbits/sec    0    150 KBytes       

[  8]   7.04-8.01   sec  24.9 MBytes   216 Mbits/sec    0    126 KBytes       

[ 10]   7.04-8.01   sec  23.8 MBytes   206 Mbits/sec    0    102 KBytes       

[SUM]   7.04-8.01   sec   101 MBytes   875 Mbits/sec    0             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   8.01-9.00   sec  26.2 MBytes   221 Mbits/sec    0    136 KBytes       

[  6]   8.01-9.01   sec  26.2 MBytes   221 Mbits/sec    0    156 KBytes       

[  8]   8.01-9.01   sec  26.2 MBytes   221 Mbits/sec    0    130 KBytes       

[ 10]   8.01-9.01   sec  26.2 MBytes   221 Mbits/sec    0    116 KBytes       

[SUM]   8.01-9.00   sec   105 MBytes   885 Mbits/sec    0             

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   9.00-10.00  sec  26.2 MBytes   221 Mbits/sec    0    144 KBytes       

[  6]   9.01-10.00  sec  26.2 MBytes   221 Mbits/sec    1    109 KBytes       

[  8]   9.01-10.00  sec  26.2 MBytes   221 Mbits/sec    0    139 KBytes       

[ 10]   9.01-10.00  sec  26.2 MBytes   221 Mbits/sec    0    127 KBytes       

[SUM]   9.00-10.00  sec   105 MBytes   882 Mbits/sec    1             

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth       Retr

[  4]   0.00-10.00  sec   265 MBytes   222 Mbits/sec    3             sender

[  4]   0.00-10.00  sec   265 MBytes   222 Mbits/sec                  receiver

[  6]   0.00-10.00  sec   266 MBytes   223 Mbits/sec    2             sender

[  6]   0.00-10.00  sec   266 MBytes   223 Mbits/sec                  receiver

[  8]   0.00-10.00  sec   262 MBytes   220 Mbits/sec    1             sender

[  8]   0.00-10.00  sec   262 MBytes   220 Mbits/sec                  receiver

[ 10]   0.00-10.00  sec   258 MBytes   216 Mbits/sec    3             sender

[ 10]   0.00-10.00  sec   258 MBytes   216 Mbits/sec                  receiver

[SUM]   0.00-10.00  sec  1.03 GBytes   881 Mbits/sec    9             sender

[SUM]   0.00-10.00  sec  1.03 GBytes   881 Mbits/sec                  receiver

Code:
root@pine64:~# iperf3 -c 192.168.1.111 -P 4 -R

Connecting to host 192.168.1.111, port 5201

Reverse mode, remote host 192.168.1.111 is sending

[  4] local 192.168.1.54 port 33444 connected to 192.168.1.111 port 5201

[  6] local 192.168.1.54 port 33445 connected to 192.168.1.111 port 5201

[  8] local 192.168.1.54 port 33446 connected to 192.168.1.111 port 5201

[ 10] local 192.168.1.54 port 33447 connected to 192.168.1.111 port 5201

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-1.01   sec  20.9 MBytes   174 Mbits/sec                  

[  6]   0.00-1.01   sec  20.8 MBytes   174 Mbits/sec                  

[  8]   0.00-1.01   sec  20.9 MBytes   174 Mbits/sec                  

[ 10]   0.00-1.01   sec  20.8 MBytes   173 Mbits/sec                  

[SUM]   0.00-1.01   sec  83.3 MBytes   694 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   1.01-2.00   sec  27.4 MBytes   231 Mbits/sec                  

[  6]   1.01-2.00   sec  27.3 MBytes   230 Mbits/sec                  

[  8]   1.01-2.00   sec  27.5 MBytes   232 Mbits/sec                  

[ 10]   1.01-2.00   sec  27.5 MBytes   232 Mbits/sec                  

[SUM]   1.01-2.00   sec   110 MBytes   925 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   2.00-3.00   sec  28.1 MBytes   236 Mbits/sec                  

[  6]   2.00-3.00   sec  28.0 MBytes   235 Mbits/sec                  

[  8]   2.00-3.00   sec  28.0 MBytes   235 Mbits/sec                  

[ 10]   2.00-3.00   sec  28.0 MBytes   235 Mbits/sec                  

[SUM]   2.00-3.00   sec   112 MBytes   941 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   3.00-4.00   sec  28.0 MBytes   235 Mbits/sec                  

[  6]   3.00-4.00   sec  28.1 MBytes   236 Mbits/sec                  

[  8]   3.00-4.00   sec  28.0 MBytes   235 Mbits/sec                  

[ 10]   3.00-4.00   sec  28.0 MBytes   235 Mbits/sec                  

[SUM]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   4.00-5.00   sec  28.0 MBytes   235 Mbits/sec                  

[  6]   4.00-5.00   sec  28.0 MBytes   235 Mbits/sec                  

[  8]   4.00-5.00   sec  28.1 MBytes   236 Mbits/sec                  

[ 10]   4.00-5.00   sec  28.1 MBytes   236 Mbits/sec                  

[SUM]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   5.00-6.00   sec  28.1 MBytes   236 Mbits/sec                  

[  6]   5.00-6.00   sec  28.1 MBytes   236 Mbits/sec                  

[  8]   5.00-6.00   sec  28.0 MBytes   235 Mbits/sec                  

[ 10]   5.00-6.00   sec  27.8 MBytes   233 Mbits/sec                  

[SUM]   5.00-6.00   sec   112 MBytes   940 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   6.00-7.00   sec  27.9 MBytes   234 Mbits/sec                  

[  6]   6.00-7.00   sec  27.9 MBytes   234 Mbits/sec                  

[  8]   6.00-7.00   sec  27.9 MBytes   234 Mbits/sec                  

[ 10]   6.00-7.00   sec  27.9 MBytes   234 Mbits/sec                  

[SUM]   6.00-7.00   sec   112 MBytes   934 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   7.00-8.00   sec  28.1 MBytes   236 Mbits/sec                  

[  6]   7.00-8.00   sec  28.0 MBytes   235 Mbits/sec                  

[  8]   7.00-8.00   sec  28.0 MBytes   235 Mbits/sec                  

[ 10]   7.00-8.00   sec  28.0 MBytes   235 Mbits/sec                  

[SUM]   7.00-8.00   sec   112 MBytes   941 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   8.00-9.00   sec  28.0 MBytes   235 Mbits/sec                  

[  6]   8.00-9.00   sec  28.0 MBytes   235 Mbits/sec                  

[  8]   8.00-9.00   sec  28.0 MBytes   235 Mbits/sec                  

[ 10]   8.00-9.00   sec  28.0 MBytes   235 Mbits/sec                  

[SUM]   8.00-9.00   sec   112 MBytes   941 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[  4]   9.00-10.00  sec  28.0 MBytes   235 Mbits/sec                  

[  6]   9.00-10.00  sec  28.1 MBytes   236 Mbits/sec                  

[  8]   9.00-10.00  sec  28.0 MBytes   235 Mbits/sec                  

[ 10]   9.00-10.00  sec  28.0 MBytes   235 Mbits/sec                  

[SUM]   9.00-10.00  sec   112 MBytes   940 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-10.00  sec   273 MBytes   229 Mbits/sec                  sender

[  4]   0.00-10.00  sec   273 MBytes   229 Mbits/sec                  receiver

[  6]   0.00-10.00  sec   273 MBytes   229 Mbits/sec                  sender

[  6]   0.00-10.00  sec   273 MBytes   229 Mbits/sec                  receiver

[  8]   0.00-10.00  sec   273 MBytes   229 Mbits/sec                  sender

[  8]   0.00-10.00  sec   273 MBytes   229 Mbits/sec                  receiver

[ 10]   0.00-10.00  sec   272 MBytes   228 Mbits/sec                  sender

[ 10]   0.00-10.00  sec   272 MBytes   228 Mbits/sec                  receiver

[SUM]   0.00-10.00  sec  1.06 GBytes   915 Mbits/sec                  sender

[SUM]   0.00-10.00  sec  1.06 GBytes   914 Mbits/sec                  receiver

If your results are even faster, consider yourself lucky . Feel free to post your results (please iperf3 results only).

Howto use MAC address as printed on the label on the back

Sat, 20 Aug 2016 17:13:40 +0000

The BSP Linux Kernel does automatically generate a locally administered MAC address for the Ethernet (eth0) interface.

Some networks might not be able to handle those correctly. The recommended solution is to manually set the MAC address to the one which is printed on the back of the Pine64 by adding it to /boot/uEnv.txt with a line like ethaddr=xx:xx:xx:xx:xx:xx.

The MAC address is the lower number on the barcode label on the back of your Pine board. Start from the left and add a colon every two chars. So far they all seem to start with 00:06:dc making this the vendor prefix.

The Mac Address Would Not Change on Debian, nor Gentoo

Fri, 19 Aug 2016 05:33:22 +0000

I ran into a very frustrating yet interesting problem last night when I tried to place two of my PineA64 boards on the same ethernet switch in preparation for the GbE testing I plan to do tomorrow.

Both of my machines had a VERY persistently stubborn mac address ( which belongs to longsleep ):
36:c9:e3:f1:b8:05

I am wondering now how many folks having ethernet problems don't really have an ethernet problem, they just don't have unique mac addresses on their network from the Pine Boards ?? (arp cache nightmare)

Anyway, I tried repeatedly to change the mac addresses of both machines... and they would NOT change... neither of them... for almost four hours.

I changed the mac address in /boot/uEnv.txt , powered off and then did a cold boot. (this on both machines) but when the boot finished both machines still had address 36:c9:e3:f1:b8:05

Believe it or not what I did to correct this was just be persistent... I started waiting longer between poweroff and cold boot... eventually the new address finally 'took' on both machines. When the address finally 'took' on both machines, both machines finally had the correct address in all four primary places:
/boot/uEnv.txt
/proc/cmdline
/sys/class/net/eth0/address
ifconfig

I really feel strongly that this needs to be changed. All Pine Boards need to have an automatic persistent unique mac address on the ethernet port; like any other IP machine interface. Or, there needs to be a very consistent way to set the persistent mac address easily so that multiple Pine Boards on the same switch are guaranteed to have unique mac addys; essential for Pine-Nut clusters !

edit: PS. I suspect that the mac address of choice has something to do with this as well... it may be that I just happened upon a prefix that would work... but took some trial and guessing. But, its looking like the mac address can not be fully ransomized.

If you have had difficulty with the GbE ethernet please take the poll

Wed, 17 Aug 2016 23:44:10 +0000

Greetings, if you have had trouble with the GbE ethernet issue on the PineA64 , please take the poll (located in the ethernet sub-forum) and fill out the data requested in the first post.

thanks

PS, use either this thread or the 'sticky' thread in the sub-forum for discussing this issue; please do not post discussion in the poll thread; that thread is only for data gathering. We are trying to identify a pattern, one way or the other.

GbE Ethernet Port Issue Data Gathering Statistics Intel

Wed, 17 Aug 2016 21:35:05 +0000

We want specific information about the ethernet port on the PineA64, relative to the board serial number. Please provide this information after you vote on the survey above:

1) board serial number and type (2G)
2) RTL chip numbers: ie, RTL8211E G2K40P2 GG10B
3) current ethernet switch or router make model and numbers
4) if you modded your board and made it work, how?
5) if you swapped out your switch or router and made it work, what or which?
6) if GbE is critical to your operation, please tell us how so ?
7) provide any other additional 'data only' that might be helpful.

Please DO NOT post discussion or questions to this thread; it is intended only for data gathering for the GbE database.

Also, please don't quote this post.

thank you

Edit: PS... it is easier to read the RTL chip numbers if you use a hand scope, and an LED flash-light ; changing the angle of the source light will make the text more visible in the scope.

What will it take to get the Ethernet port working?

Mon, 25 Jul 2016 00:58:39 +0000

As everyone knows, the gigabit Ethernet port does not work on the 2gig boards running Android and Remix OS. I have the WiFi card, that came with my pledge, installed, and it is OK for browsing the internet but not for a serious media player device.

Who is in charge of getting this to work?? Is there anyone steering the ship?

Pine64+ 1GB Ethernet Port spec

Fri, 08 Jul 2016 12:07:39 +0000

Has the specifications of the Ethernet port on the Pine64+ 1GB changed? According to the shop its only 10/100M.

The 1G Ethernet on the Pine64 is one of the main features I needed. I'm not happy that I have to connect it to a 100M switch to get it to work. I see from other post its possible to force the Pine64+ to 100M, so at least I don't need two routers now. Not that I'm using the Pine64+ at the moment. I bought a Banana Pi M1, which is great, especially with the proper SATA port (i.e., not USB to SATA like the Orange Pi or Banana Pi M3).

Kinda upset at the lack of response to GBe issues

Wed, 18 May 2016 13:28:25 +0000

I have the A64+ board, and I figured I'd use it to replace my Pi2 as a media center, and use the Pi2 for something else. I'm in the same boat as lots of others - GB network isn't working, which was one of the main reasons I got the damn thing. If I reduce the network connectivity on my switch to 100mbps for the port I connect the Pine64 to, it works fine (well, y'know.. "fine"). I dont even get the slow speed - I get an IP, but the Pine refuses to connect to anything.

My issue here is not with the issue at hand - I get that bugs can and will happen. What frustrates me to no end is the fact that there is nothing from the Pine guys on this. TL hasn't replied to a single thread about this as far as I know, and not even recognized this as an issue.

Could we please get an official statement on if the issues lots of us are experiencing with GBe are even on your list of things to fix? Do you guys have an ETA, or an idea on what the issue could be? If you don't think it's the Pine - any suggestions on what else it could be? I've tried 4 different wall outlets (2 of which I use to power Pi2 and Pi3), and they don't make a difference at all.