PeterL:

sorry,

Debian Jessie Proxmox as CT
Debian Jessie on Physical Hardware
Ubuntu 16.4 LT on VM
Also tested on OpenJDK 7 jre

Hi jeanphi,

I think there is nothing more we could do or test now, as there is no usable output for debugging this any further.
So the question that remains is: why is it working on some systems but not on ours?
This question can only be answered by the person(s) who hacked together the application.

(and I have to use this opportunity to rant about the missing software quality of TP-Link products and firmware ... I've already been troubleshooting obvious firmware bugs, which just got a "won't repair" answer)

I've opened a support case with TP-Link Germany and I'm currently waiting for a reply.
If I get an answer, I'll update this thread.

Regards
Peter

Support did not answer yesterday and also chat and phone support was not reachable.
This morning I decided to give it a shot and setup an old HP desktop (Core2Duo ...) with Debian 8.3 and see how the EAP controller is doing there.
Guess what - it also did not run correctly.

Compared to current server or even desktop hardware that old desktop took quite some time starting everything up until the java process exits, which gave me some time to think about the problem.
The difference between the systems I was able to test on was, the ones with static/dynamic private IP addresses showed the problem, the ones with public IP addresses worked normally.

So what I did - just as a test I did not expect any results from - is I assigned the network interface a static public IP (it was still connected to our private network at work) and tried to fire up the EAP controller.
Now ... guess what ... the controller started normally (although slowly because of that ancient hardware).
I switched back and forth between static public and static private IP to rule out a random success and the problem did come with the private and go with the public IP address.

A dirty hack is to assign the network interface a public IP, fire up the EAP Controller and change back to the private IP - the EAPC still works afterwards.
You don't need network access working with the public IP, so you can just pick a random one ...
e.g
address 1.2.3.5
netmask 255.255.255.252
gateway 1.2.3.6


Regards
Peter

Edit1:
It also works when the network interface is DOWN with a private IP address.
This is - like the public IP - a workaround and needs access to the physical console for obvious reasons.

The server.log then shows the following:
---- start server.log ----
2017-08-17 08:54:55 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : eap.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : eap.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : mongodb.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : jetty.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : log4j.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : device.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : netty.properties
2017-08-17 08:55:06 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : user.params.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : eap.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : mongodb.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : jetty.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : log4j.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : device.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : netty.properties
2017-08-17 08:55:50 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : user.params.properties
2017-08-17 08:56:09 [main] [WARN]-[Slf4JLogger.java:136] - Failed to find a usable hardware address from the network interfaces; using random bytes: e5:48:b4:26:ac:c1:29:b8
2017-08-17 08:56:11 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring root WebApplicationContext
2017-08-17 08:56:31 [main] [INFO]-[MonitorInit.java:39] - monitor context initialing...
2017-08-17 08:56:31 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring FrameworkServlet 'springMVC'
2017-08-17 08:56:33 [main] [INFO]-[DbCompatibleServcie.java:96] - no need to compatible db.
.
.
.
--- end server.log ----


Edit2:

Still a dirty hack but at least working on reboot:

For Debian based systems the network configuration could look like this:
Obviously you will have to replace the IP address of eth0:0 with one of your network.

---- start /etc/network/interfaces ----
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface for TP-Link EAPC workaround
allow-hotplug eth0
iface eth0 inet static
address 1.2.3.5
netmask 255.255.255.252

# The ACTUAL network interface
auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.254
---- end /etc/network/interfaces ----


Edit3:

Example with DHCP on the alias interface (and new interface naming scheme - replace XYZ with your interface name)

---- start /etc/network/interfaces ----
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface for TP-Link EAPC workaround
allow-hotplug enXYZ
iface enXYZ inet static
address 1.2.3.5
netmask 255.255.255.252

# The ACTUAL network interface
auto enXYZ:0
allow-hotplug enXYZ:0
iface enXYZ:0 inet dhcp
---- end /etc/network/interfaces ----


Edit 4:
Support case with TP-Link Germany opened via phone.
If you read this, this is the end of troubleshooting and now it's YOUR turn to fix it.

R1D2 wrote

Weird. I use private IP addresses on both Debian servers, too, and don't have those problems. Maybe, it has to do with the 192.168.0.0 subnet you're using: 192.168.0.254 is usually the default address of EAPs. Maybe, the EAPC handles IP addresses in this address space specially in some way (what it should not do, but who knows ...).

Hi,

the 192.168.0.0/24 subnet is just an example.
We're not using that subnet anywhere nor at any customer's site - just like the 192.168.1.0/24 subnet.
There are too many network vendors that use those subnets as defaults ...

I also tried some 10.x.x.0/24 subnets but stopped my tests as the problem was reproducible.

Regards
Peter

R1D2 wrote

AFAIK, besides the java RTE, there are only 3 binaries in EAPController, which are compiled for 64 bit: mongo, mongodb and portt, a tiny helper utility checking if EAPC is alive by connecting to its port. If you can get mongo/mongoDB and jre >= 1.7 for your Synology NAS, only portt would be needed to run the EAPC, so it would be no big deal for TP-Link to compile it for 32 bit platforms. Maybe you want open a ticket/feature requests with TP-Link support?

well, I tried to open a ticket, but it seems that I can not open a ticket in USA for this since I'm in beglium. even when its the same controller....

Hi!

For my configuration this is not a solution:

#ifconfig
enp3s0 Link encap:Ethernet Hardware Adresse xxx
inet Adresse:1.2.3.5 Bcast:1.2.3.7 Maske:255.255.255.252
inet6-Adresse: fe80::c23f:d5ff:fe6b:6a19/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:835 Fehler:0 Verloren:178 Überläufe:0 Fenster:0
TX-Pakete:579 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:138117 (138.1 KB) TX-Bytes:128621 (128.6 KB)

enp3s0:0 Link encap:Ethernet Hardware Adresse xxx
inet Adresse:192.168.1.4 Bcast:192.168.1.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX-Pakete:626 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:626 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1
RX-Bytes:43694 (43.6 KB) TX-Bytes:43694 (43.6 KB)

-> Starting EAP Controller ........./usr/bin/tpeap: Zeile 79: 2076 Killed nohup $JAVA_TOOL -server -Xms128m -Xmx1024m -XX:MaxHeapFreeRatio=60 -XX:MinHeapFreeRatio=30 -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError -Deap.home="${eapHome}" -cp ${eapHome}"/lib/com.tp-link.eap.start-0.0.1-SNAPSHOT.jar:"${eapHome}"/lib/*:"${eapHome}"/external-lib/*" com.tp_link.eap.start.EapMain start > ${eapHome}/logs/startup.log 2>&1

R1D2 wrote

http://www.tp-link.com/nl-be/support-contact.html#E-mail-Support

or as per your preference:

http://www.tp-link.com/fr-be/support-contact.html#E-mail-Support

already did that....