You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
recently I worked on a synscan and I started from the example there is in the repo. Although I find that pretty cool seems like sharing the handle when reading and writing packets to it causes troubles: scanning would become extremely slow and flaky e.g: on this https://gist.github.com/CyberRoute/5cd02e1ee10d1c4cef09e5cca1d6f57c
// scanner handles scanning a single IP address.
type scanner struct {
// iface is the interface to send packets on.
iface *net.Interface
// destination, gateway (if applicable), and source IP addresses to use.
dst, gw, src net.IP
handle *pcap.Handle
// opts and buf allow us to easily serialize packets in the send()
// method.
opts gopacket.SerializeOptions
buf gopacket.SerializeBuffer
}
After testing with handles decoupled for arp and tcp when reading packets everything goes pretty smooth and fast even without parallelism as on the example. e.g:
Hi,
recently I worked on a synscan and I started from the example there is in the repo. Although I find that pretty cool seems like sharing the handle when reading and writing packets to it causes troubles: scanning would become extremely slow and flaky e.g: on this https://gist.github.com/CyberRoute/5cd02e1ee10d1c4cef09e5cca1d6f57c
After testing with handles decoupled for arp and tcp when reading packets everything goes pretty smooth and fast even without parallelism as on the example. e.g:
TCP:
ARP:
The text was updated successfully, but these errors were encountered: