domoticity

Hy
I answer myself :)
 
I have found what's going wrong.
 
tinkerboard register the interfaces in this files /etc/udev/rules.d/70-persistent-net.rule
When the eth0 is already used, the next mac adress takes eth1.
 
So the solution: delete this files /etc/udev/rules.d/70-persistent-net.rule

Hy
Of course.
I upload it in a share cloud and give toi the link.
But IMPORTANT, nous apt-get upgrade

Hy
I answer myself :)
 
I have found what's going wrong.
 
tinkerboard register the interfaces in this files /etc/udev/rules.d/70-persistent-net.rule
When the eth0 is already used, the next mac adress takes eth1.
 
So the solution: delete this files /etc/udev/rules.d/70-persistent-net.rule

Hello domoticity;
 
Odd. Have you checked the actual negotiated speed of your interface card (in the Tinkerboard)?
 
Looks like it is running in 100 Mbps instead. Check out my result:
 
[root@tinkerboard ~]# ethtool eth0 Settings for eth0: Supported ports: [ TP AUI BNC MII FIBRE ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s <======================== HERE Duplex: Full Port: MII PHYAD: 0 Transceiver: external Auto-negotiation: on Supports Wake-on: ug Wake-on: d Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes [root@tinkerboard ~]#  
Check your board result with # ethtool eth0 and let us know.
 
Ah. For what is worth, I have just finished a stress test here (I will replace the raspi with this tinkerboard) with netcat using the Tinkerboard both as the final destination (netcat running in the Tinkerboard) and NATting (using VLAN tag from two different VLANs).
 
I got effective routing throughput of ~ 930 Mbps from both up and downstream.
 
For completeness, this is a diagram of the test:
 
+-------------+ +-------------+ +--------------+ | Computer 1 | | Tinkerboard | | Computer 2 | | 172.16.3.1 | | | | 172.16.8.1 | +---+---------+ +------+------+ +------------+-+ | | | | eth0.3 | eth0.8 | Untagged VLAN 3 | VLAN 3 | VLAN 8 |Untagged VLAN 8 | 172.16.3.13 | 172.16.8.13 | | +-----------+----------------+ | | | | | +-------+ Switch +------+ | | +----------------------------+  
The tinkerboard is acting as a NAT / Gateway for VLAN 8. So we have here:
 
# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -I POSTROUTING -o eth0.3 -j MASQUERADE
 
So in Computer 1 I have:
# cat /dev/zero | nc -l 3333
 
In computer 2:
# nc 172.16.3.1 > /dev/null
 
Monitoring the traffic in Tinkerboard, using # iptraf-ng
 
This puts double penalty over the Tinkerboard. Instead of just routing, which is easy-peasy, it also does makes the Traffic pass through the Netfilter engine, and remember that I'm using VLAN tag, meaning the same physical inetraface servers both endpoints.
 
But wait, there's more: I'm using the Asus-provided heatsink (Tony will surely roll his eyes) with temperatures not  going above 56 Celsius.
 
Even with this scenario I managed to pull ~930 Mbps of effective NAT traffic.
 
The reverse is also true. Scenario:
 
Tinkerboard:
# iptables -t nat -I PREROUTING -p tcp --dport 4444 -j DNAT --to 172.16.8.1
 
Computer 2:
# cat /dev/zero | nc -l 4444
 
Computer 1:
# nc 172.16.8.13 4444
 
The second test is even more costly, because it has both the NAT and the Destination NAT.
 
Still ~930 Mbps.
 
<3'ing my tinkerboard!!!! \o/