[Bug]: zt client can find neighbor each other, but can not ping ?
ipv6next opened this issue · comments
🐛 Describe the Bug
ZTNET controller show the status of zt client connection is direct.
and ,zt client can find neighbor each other,
but why can not ping each other ?
🔍 Steps to Reproduce
1.reload openwrt system
2.change the ztnet server
it does not work
🔧 Deployment Type
- Docker
- Standalone
✨ Expected Behavior
ping each other is ok!
📋 ZTNET Logs
root@VM-16-12-ubuntu:/home/ubuntu# docker logs ztnet
Creating .env file...
psql: error: connection to server at "postgres" (172.31.255.3), port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
Postgres is unavailable - sleeping
psql: error: connection to server at "postgres" (172.31.255.3), port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
Postgres is unavailable - sleeping
Applying migrations to the database...
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "ztnet", schema "public" at "postgres:5432"
31 migrations found in prisma/migrations
Applying migration `20230402192938_`
Applying migration `20230714081023_flow`
Applying migration `20230717095341_tags`
Applying migration `20230717150852_nw_member`
Applying migration `20230723084736_mailoptions`
Applying migration `20230724093114_nw_description`
Applying migration `20230728082722_init`
Applying migration `20230806115334_zt_central`
Applying migration `20230808053939_db_rework`
Applying migration `20230809202431_cascade`
Applying migration `20230811063619_user_options`
Applying migration `20230813195808_user_group`
Applying migration `20230815175550_custom_root`
Applying migration `20230818113722_custom_root_extend`
Applying migration `20230823185550_update_cascade_delete`
Applying migration `20230825053528_user_invitation`
Applying migration `20230910161252_authorize_warning`
Applying migration `20231006203924_landing_page_body`
Applying migration `20231028155404_token_user_expiration`
Applying migration `20231030072137_userid`
Applying migration `20231203075656_organization`
Applying migration `20231204170707_cascade_delete_user`
Applying migration `20231221190212_member_id_as_name`
Applying migration `20231222102756_oauth`
Applying migration `20231229104733_webhooks`
Applying migration `20240111172646_root_nodes`
Applying migration `20240310090305_physical_address`
Applying migration `20240315064831_api_token_extended`
Applying migration `20240327130439_org_invites`
Applying migration `20240514144732_user_created_at`
Applying migration `20240517203421_routes_and_invitations`
The following migration(s) have been applied:
migrations/
└─ 20230402192938_/
└─ migration.sql
└─ 20230714081023_flow/
└─ migration.sql
└─ 20230717095341_tags/
└─ migration.sql
└─ 20230717150852_nw_member/
└─ migration.sql
└─ 20230723084736_mailoptions/
└─ migration.sql
└─ 20230724093114_nw_description/
└─ migration.sql
└─ 20230728082722_init/
└─ migration.sql
└─ 20230806115334_zt_central/
└─ migration.sql
└─ 20230808053939_db_rework/
└─ migration.sql
└─ 20230809202431_cascade/
└─ migration.sql
└─ 20230811063619_user_options/
└─ migration.sql
└─ 20230813195808_user_group/
└─ migration.sql
└─ 20230815175550_custom_root/
└─ migration.sql
└─ 20230818113722_custom_root_extend/
└─ migration.sql
└─ 20230823185550_update_cascade_delete/
└─ migration.sql
└─ 20230825053528_user_invitation/
└─ migration.sql
└─ 20230910161252_authorize_warning/
└─ migration.sql
└─ 20231006203924_landing_page_body/
└─ migration.sql
└─ 20231028155404_token_user_expiration/
└─ migration.sql
└─ 20231030072137_userid/
└─ migration.sql
└─ 20231203075656_organization/
└─ migration.sql
└─ 20231204170707_cascade_delete_user/
└─ migration.sql
└─ 20231221190212_member_id_as_name/
└─ migration.sql
└─ 20231222102756_oauth/
└─ migration.sql
└─ 20231229104733_webhooks/
└─ migration.sql
└─ 20240111172646_root_nodes/
└─ migration.sql
└─ 20240310090305_physical_address/
└─ migration.sql
└─ 20240315064831_api_token_extended/
└─ migration.sql
└─ 20240327130439_org_invites/
└─ migration.sql
└─ 20240514144732_user_created_at/
└─ migration.sql
└─ 20240517203421_routes_and_invitations/
└─ migration.sql
All migrations have been successfully applied.
Migrations applied successfully!
Seeding the database...
Environment variables loaded from .env
Running seed command `ts-node --compiler-options {"module":"CommonJS"} prisma/seed.ts` ...
Seeding:: User Options complete!
Seeding:: Updating user ID complete!
The seed command has been executed.
┌─────────────────────────────────────────────────────────┐
│ Update available 5.15.0 -> 5.16.1 │
│ Run the following to update │
│ npm i -g prisma@latest │
│ npm i @prisma/client@latest │
└─────────────────────────────────────────────────────────┘
Database seeded successfully!
Executing command
▲ Next.js 14.1.4
- Local: http://89656f4a751f:3000
- Network: http://172.31.255.4:3000
✓ Ready in 119ms
2024/07/03 10:06:47 startup flag parsed: true
2024/07/03 10:06:47 config file read.
2024/07/03 10:06:47 config file unmarshalled.
2024/07/03 10:06:47 read world signing key failed: open previous.c25519: no such file or directory , open current.c25519: no such file or directory
2024/07/03 10:06:47 preflight check error occurred, but still can proceed.
2024/07/03 10:06:47 new world signing key generated.
2024/07/03 10:06:47 preflight check successfully complete.
2024/07/03 10:06:47 generating pre-sign message.
2024/07/03 10:06:47 pre-sign world generated and serialized successfully.
2024/07/03 10:06:47 world has been signed.
2024/07/03 10:06:47 new signed world are packed.
2024/07/03 10:06:47 packed new signed world has been written to file.
2024/07/03 10:06:47
2024/07/03 10:06:47
2024/07/03 10:06:47 now c language output:
root@VM-16-12-ubuntu:/home/ubuntu#🖼 Screenshots
This is more of a zerotier related questions and not directly related to ztnet.
Do you have a managed route of 10.121.15.0/24 via LAN in your network?
I have a managed route of 10.121.15.0/24 via LAN in my networks!
but , I think. the error in docker logs maybe the reason:
2024/07/03 10:06:47 read world signing key failed: open previous.c25519: no such file or directory , open current.c25519: no such file or directory
2024/07/03 10:06:47 preflight check error occurred, but still can proceed.
I think. the error in docker logs maybe the reason:
2024/07/03 10:06:47 read world signing key failed: open previous.c25519: no such file or directory , open current.c25519: no such file or directory
These are normal when you create a new planet. It will generate new certificates previous.c25519 & current.c25519
If there were any issues with the planet configuration, your nodes would not have been able to join the network.
Have you confirmed that ICMP/ping is not blocked by your firewall?
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 3 days since being marked as stale.