Re: Possible bug while using -sY -PY and --data-length.

[Daniel Miller <bonsaiviking () gmail com>]

José,

Thank you for the bug report. This is an unfortunate consequence of
the way that --data-length is implemented. TCP does not specify a
payload length in the header, and UDP specifies the length once. SCTP,
on the other hand, specifies the length of each chunk individually;
the SCTP INIT chunk that is sent to accomplish the port scan is one,
and then any random data that is sent because of --data-length is
interpreted as a second chunk.

I've attached an image of how Wireshark decoded one packet from my
machine with these same options.

A solution would be to interpret the --data* options as referring to
one of the 15 valid chunk types and then fill in the correct length
and payload. This is not really a high priority for me, since the
--data* options are not part of the core port scanning functionality
of Nmap, but we would welcome a patch that would fix the invalid
packet situation.

Dan

On Sat, Sep 27, 2014 at 2:14 PM, José Maria Foces Vivancos
<masterbondfv () gmail com> wrote:
> Hi, Nmap development team.
>
> While studiying your network scanning tool I have found something weird
> while using nmap with the following parameters:
>
> nmap -d -n -p8002 -sY -PY8002 --data-length 10 <objective>
>
> I dont know if its a bug or if it's working fine.
>
> Wireshark shows that SCTP INIT packets are malformed.
> [image: Imágenes integradas 1]
>
> It works ok when running against a TCP port and with options -sS -PS.
> Thank you so much for this great job.
>
> Bye.
> José María Foces Vivancos.
>
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/