Nevermind the 'clear the sockets thing' I just attack an inetd
port and then kill inetd and they go away, which allows me to
work faster in the lab.
I guess my real question to someone who is more familiar with
'RFC' history is the same as the last post...
Why when an attacked host sends a SYN,ACK to an UNREACHABLE
destination does the SYN,ACK just go down a black hole
without an ICMP message to the originator, when I use
0.0.0.4 as a spoofed address?
Shouldn't this be covered in an RFC somewhere as something
that must happen?
The reason I ask is obvious.... if I could get the error message
I could have tcp_err() do some quick and dirty cleaning of
the queue (and at least have a piece of this puzzle in place..)
Thanks,
Tim
[CC: list rigorously trimmed]
Why when an attacked host sends a SYN,ACK to an UNREACHABLE
destination does the SYN,ACK just go down a black hole
without an ICMP message to the originator, when I use
0.0.0.4 as a spoofed address?
Shouldn't this be covered in an RFC somewhere as something
that must happen?
RFC792:
If, according to the information in the gateway's routing tables,
the network specified in the internet destination field of a
datagram is unreachable, e.g., the distance to the network is
infinity, the gateway may send a destination unreachable message
to the internet source host of the datagram. In addition, in some
networks, the gateway may be able to determine if the internet
destination host is unreachable. Gateways in these networks may
send destination unreachable messages to the source host when the
destination host is unreachable.
ICMP unreachable messages are optional in any case, but there seems to be
a singularity about 0/8. Does anyone know why this is?
Try using a different bogus source address...