the NOKERNINFO flag only marginally de-clutters the output and
has a number of unwanted side effects:
o The kernel info might be what you want to see
o ^T is left non-functional if ping is killed non-cleanly
o "ping -q foo &" gets suspended on tty output
Encouraged by: bde
lookup on an IP address from the packet (such as the IP that sent
a TTL exceeded error). If the DNS lookup takes a long time, ^C will
appear to be ineffective since the SIGINT handler just sets a flag
and returns. Work around this by exiting immediately on receipt of
a second SIGINT when DNS lookups are enabled.
PR: bin/4696
MFC after: 1 week
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?)
right; after a single packet was dropped it beeped after every
transmission.
Change its implementation to only output a bell when there is an
increase in the maximum value of the number of packets that were
sent but not yet received. This has the benefit that even for very
long round-trip times, ping -A will do roughly the right thing
after a few inital false-positives.
Reviewed by: ru
The original code was certainly broken; it knows that whereto is
to be used for a sockaddr_in, so it should be declared as such.
To support multiple protocols, there is also a sockaddr_storage
struct that can be used; I don't think struct sockaddr is supposed
to be used anywhere other than for casts and pointers.
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
MFC after: 3 weeks
This one is strange and goes against my rusty compiler knowledge.
The global declaration
struct sockaddr whereto;
produces for both i386 && alpha:
.comm whereto,16,1
which means common storage, byte aligned. Ahem. I though structs
were supposed to be ALDOUBLE always? I mean, w/o pragma packed?
Later on, this address is coerced to:
to = (struct sockaddr_in *)&whereto;
Up until now, we've been fine on alpha because the address
just ended up aligned to a 4 byte boundary. Lately, though,
it end up as:
0000000120027b0f B whereto
And, tra la, you get unaligned access faults. The solution I picked, in
lieu of understanding what the compiler was doing, is to put whereto
as a union of a sockaddr and sockaddr_in. That's more formally correct
if somewhat awkward looking.
user runs with privilege, allowing the sending of icmp packets with
larger size (up to 48k, the default receive buffer size in ping),
which is useful for network driver development testing, as well
as experimentation with fragmentation.
Reviewed by: wpaul
