o Warn when recieved packet length is not equal to length of the
packet we sent out. Idea from NetBSD.
o Fit the dump of packet with wrong data to 80 columns (from NetBSD).
Comments from: bde
(See: ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt)
This fulfills the host requirements for userland support by
way of the setsockopt() IP_EVIL_INTENT message.
There are three sysctl tunables provided to govern system behavior.
net.inet.ip.rfc3514:
Enables support for rfc3514. As this is an
Informational RFC and support is not yet widespread
this option is disabled by default.
net.inet.ip.hear_no_evil
If set the host will discard all received evil packets.
net.inet.ip.speak_no_evil
If set the host will discard all transmitted evil packets.
The IP statistics counter 'ips_evil' (available via 'netstat') provides
information on the number of 'evil' packets recieved.
For reference, the '-E' option to 'ping' has been provided to demonstrate
and test the implementation.
- Correct some problems with packet construction.
+--------+------------+----------+-------------+---------+
| | | | | |
| IP Hdr | MINICMPLEN | phdr_len | TIMEVAL_LEN | payload |
| | | | | |
+--------+------------+----------+-------------+---------+
| | | |
|<- IP ->|<------- ICMP -------->|<------ datalen ------>|
My previous changes tried to mess around with 'datalen' instead of
modifying 'phdr_len'.
I'm including this nice ASCII diagram (from Maxim) to further clarify things
in CVS history.
Submitted by: Maxim Konovalov <maxim@macomnet.ru>
when WARNS was increased recently, but __printf0like() has been
temporarily disabled for 8 months.
Fixed related style bugs (disordered declaraction and silly type for
maxpayload -- assume 16-bit ints like the rest of ping.c).
Submitted by: bde
Do not constantify maximum payload size. It is 65467 with -R
(record route), and 65507 without it.
Reviewed by: silence on -net
Proposed by: bde
I am going to MFC rev.1.77 - 1.81 ping.c and rev.1.39 and 1.40 ping.8:
MFC after: 6 months
gcc memcpy "knows" about types that are supposed to be actually already
aligned and triggers alignment errors doing the memcpy itself.
"Fix" this by changing it to a bcopy(). In this case, we had:
struct timeval *tp;
struct timeval tv1;
memcpy(&tv1,tp,sizeof(tv1));
.. and since gcc *knows* that a pointer to a timeval is longword aligned
and that tv1 is longword aligned, then it can use an inline that assumes
alignment. The following works too:
cp = (char *)tp;
memcpy(&tv1,cp,sizeof(tv1));
Simply casting (char *)tp for the memcpy doesn't work. :-(
This affected different 64 bit platforms in different ways and depends
a lot on gcc as well. I've seen this on alpha and ia64 at least, although
alpha isn't doing it right now.
o Fix zero payloading, unbreak ping -s 0.
o Increase socket recieve buffer, ping -s 65467 is working now.
Submitted by: anti-magic sweep based on kris's patch
Reviewed by: bde, silence on -audit
MFC after: 2 months
It does not help modern compilers, and some may take some hit from it.
(I also found several functions that listed *every* of its 10 local vars with
"register" -- just how many free registers do people think machines have?)
