In the modern kernel we have enough tools for TCP debugging. I personally
never used ddb(4) to debug TCP problems and never heard of anybody using
it in the last 15+ years. The code have always been just a maintenance
burden.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 73324 Build 70207: arc lint + arc unit
Event Timeline
I actually used and extended it. For example, syzkaller is dumping the information for all locked tcpcbs when panicing. This gives at least some information in a situation where you cannot access a core. This was good enough for me to fix some bugs.
I am happy to do some maintenance work, if required.
Unrelated but FYI I recently started to extend show ifnet again which helped me to fix two bugs so far; just in case that's on anyone's list as well.
Bjoern, what was your use case? syzkaller, too?
I personally find very little value in ddb today. Large changes to ifnet I did recently were all debugged with bhyve + kgdb.
Bringup on someone's HW/architecture where bhyve isn't ready to be used yet (especially not with passthru).
And in these cases it was M_TEMP memory corruption on if_groups.
There is still another one to be debugged at least.
If bhyve one day works with passthru on arm64 or riscv debugging may be different but then the bare metal would still not boot to actually get there... and typing in a few commands into ddb and setting hwatch is so much faster then transfering a dump to be used offline. Maybe is netdump would support IPv6 but ...