Fresh install Homer 7 not inserting data on postgree

[ggcsercomtel]

Hi,

I'm having trouble with data ingestion on a fresh HOMER 7 Docker installation.

I'm trying to install Homer 7 and i can't insert data with hepgen.js at it.

While i'm running "hepgen.js -s 127.0.0.1-p 9060-c $(npm root -g)/hepgen.js/config/b2bcall_rtcp.js" i can see the traffic with tcpdump but i can't find anything at the homer webportal.

Then i go check at postgree and there is none data saved.

Checking some logs the system looks normal and the status of the server looks ok to.

Additional note, please be advised that the documentation still uses the deprecated command docker-compose instead of the current docker compose syntax.

Could any help me?

Thanks!

[lmangani]

Hi @ggcsercomtel most likely cause is packets are not arriving, port is closed, wrong target, etc.

"hepgen.js -s 127.0.0.1-p 9060-c $(npm root -g)/hepgen.js/config/b2bcall_rtcp.js"

Suspicious. I dont see how this could work in a docker env (unless you're running inside the heplify-server container?)

[ggcsercomtel]

Hi @lmangani , thanks for your help!

Ports are open, and the only firewall rules configured were applied when Docker started with "docker compose up -d"

### netstat -an
Conexões Internet Ativas (servidores e estabelecidas)
Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado
tcp 0 0 0.0.0.0:9030 0.0.0.0:* OUÇA
tcp 0 0 0.0.0.0:9060 0.0.0.0:* OUÇA
tcp 0 0 0.0.0.0:9061 0.0.0.0:* OUÇA
tcp 0 0 0.0.0.0:9080 0.0.0.0:* OUÇA
tcp 0 0 0.0.0.0:22 0.0.0.0:* OUÇA
tcp 0 0 127.0.0.1:631 0.0.0.0:* OUÇA
tcp 0 0 0.0.0.0:3100 0.0.0.0:* OUÇA
tcp 0 0 192.168.5.41:22 192.168.20.30:55218 ESTABELECIDA
tcp 0 0 192.168.5.41:9080 192.168.8.48:18297 ESTABELECIDA
tcp 0 0 172.18.0.1:58058 172.18.0.9:80 ESTABELECIDA
tcp 0 0 172.18.0.1:46688 172.18.0.9:80 ESTABELECIDA
tcp 0 0 192.168.5.41:9080 192.168.8.48:18296 ESTABELECIDA
tcp6 0 0 :::9030 :::* OUÇA
tcp6 0 0 :::9060 :::* OUÇA
tcp6 0 0 :::9061 :::* OUÇA
tcp6 0 0 :::9080 :::* OUÇA
tcp6 0 0 :::22 :::* OUÇA
tcp6 0 0 :::3100 :::* OUÇA
tcp6 0 0 ::1:631 :::* OUÇA
udp 0 0 0.0.0.0:37380 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 0.0.0.0:9060 0.0.0.0:*
udp6 0 0 :::5353 :::*
udp6 0 0 :::55639 :::*
udp6 0 0 :::9060 :::*

### docker ps (here at docker)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3659241497d6 sipcapture/heplify-server "./heplify-server" 3 minutes ago Up 3 minutes 9090/tcp, 0.0.0.0:9060-9061->9060-9061/tcp, 0.0.0.0:9060->9060/udp, [::]:9060-9061->9060-9061/tcp, [::]:9060->9060/udp, 9096/tcp heplify-server

130090abe9be sipcapture/webapp "/docker-entrypoint.…" 3 minutes ago Up 3 minutes 0.0.0.0:9080->80/tcp, [::]:9080->80/tcp homer-webapp
5518f8356c0e prom/node-exporter:latest "/bin/node_exporter …" 3 minutes ago Up 3 minutes 9100/tcp nodeexporter
808f2bc5ef3f postgres:11-alpine "docker-entrypoint.s…" 3 minutes ago Up 3 minutes (healthy) 5432/tcp db
c567ed512b21 prom/alertmanager:latest "/bin/alertmanager -…" 3 minutes ago Up 3 minutes 9093/tcp alertmanager
45ea7133ee2b grafana/grafana:master "/run.sh" 3 minutes ago Up 3 minutes (healthy) 0.0.0.0:9030->3000/tcp, [::]:9030->3000/tcp grafana
7e69fc006a91 prom/prometheus:latest "/bin/prometheus --c…" 3 minutes ago Up 3 minutes 9090/tcp prometheus
d2dd360af7aa grafana/loki "/usr/bin/loki -conf…" 3 minutes ago Up 3 minutes 0.0.0.0:3100->3100/tcp, [::]:3100->3100/tcp loki

#Suspicious. I dont see how this could work in a docker env (unless you're running inside the heplify-server container?)
I can't understand why this fails, as firewall rules are successfully directing the data to the Docker host.
Do you think it's better to try a installation without docker?

Thanks!

[lmangani]

Docker should be fine - I just think you should try use the explicit docker container name when sending HEP traffic with this type of setup.

[ggcsercomtel]

Hi, sorry for the delay.

Following up on my previous ticket, I've performed a new, bare-metal installation (without Docker), but the ingestion issue persists.

The core problem remains the same: HEP traffic is reaching the host, but data is not being written to the database.

• Packet Flow: I can confirm the HEP test packets are hitting the network interface (via tcpdump on UDP 9060).
• Database Check: Direct checks on the PostgreSQL database show zero data. For example:
  select count(*) from public.hep_proto_1_call_20251029_1100; (Result: 0)

Any other ideas?

Thanks!