nullt3r

Does, for example, command `nmap --noninteractive 127.0.0.1 -p 55432` work?

I am unable to reproduce this behaviour, could you try running a (pdb) debugger on the jfscan?

For such task, please use masscan directly (https://github.com/robertdavidgraham/masscan) and follow https://github.com/robertdavidgraham/masscan#pf_ring

This will work with only with Masscan and scans will be much faster, but Nmap will not utilize such throughput as it does not have it's own TCP/IP stack implemented...

Provide more details, so I can replicate the issue: - Which ports were found by nmap? - On what platform did you run the scan? - What settings did you...

Ok. First of all, the port number 162 is not in database: ``` { Name: "snmp", Payloads: []string{"302902010004067075626C6963A01C0204565ADC5D020100020100300E300C06082B060102010101000500", "302602010104067075626C6963A1190204DC63C29A020100020100300B300906052B060102010500", "303A020103300F02024A69020300FFE30401040201030410300E0400020100020100040004000400301204000400A00C020237F00201000201003000"}, Port: []int{161}, }, ``` I will add it to the...

I am always open to constructive criticism. UDPX is effective for scanning larger networks, /24 or so. Remember, that it is packet-based approach, so it does not wait for ICMP...

Good idea, I will look into it. Documentation is still work in progress, but there is [this](https://github.com/nullt3r/udpx#how-to-add-your-own-probe) little section. I am thinking about adding YML templates.

The poor's man solution is to capture the data via netcat, e. g. `nc -ul PORT > /tmp/out.pkt` and then convert the packet to hex data `cat /tmp/out.pkt | hexdump...

Yep, I realised there is TLS 1.3 by design in QUICK, so thats expected.