struct ip in ping(8):
sbin/ping/ping.c:1684:53: error: taking address of packed member
'ip_src' of class or structure 'ip' may result in an unaligned pointer
value [-Werror,-Waddress-of-packed-member]
(void)printf(" %s ", inet_ntoa(*(struct in_addr *)&ip->ip_src.s_addr));
^~~~~~~~~~~~~~~~~
sbin/ping/ping.c:1685:53: error: taking address of packed member
'ip_dst' of class or structure 'ip' may result in an unaligned pointer
value [-Werror,-Waddress-of-packed-member]
(void)printf(" %s ", inet_ntoa(*(struct in_addr *)&ip->ip_dst.s_addr));
^~~~~~~~~~~~~~~~~
MFC after: 3 days
After calling the cap_init(3) function Casper will fork from it's original
process, using pdfork(2). Forking from a process has a lot of advantages:
1. We have the same cwd as the original process.
2. The same uid, gid and groups.
3. The same MAC labels.
4. The same descriptor table.
5. The same routing table.
6. The same umask.
7. The same cpuset(1).
From now services are also in form of libraries.
We also removed libcapsicum at all and converts existing program using Casper
to new architecture.
Discussed with: pjd, jonathan, ed, drysdale@google.com, emaste
Partially reviewed by: drysdale@google.com, bdrewery
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4277
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
network packets that we parse and not against local users trying to gain root
access through ping's set-uid bit - this is handled by dropping privileges very
early in ping.
Submitted by: Mikhail <mp@lenta.ru>
current version of FreeBSD, this isn't guarenteed by the API. Custom
security modules, or future implementations of the setuid and setgid
may fail.
PR: bin/172289
PR: bin/172290
PR: bin/172291
Submittud by: Erik Cederstrand <erik@cederstrand.dk>
Discussed by: freebsd-security
Approved by: cperciva
MFC after: 1 week
wait time for a packet. This allows to:
- Count number of packets received before and after specified
time.
- Shorten time of execution of 'ping -c 1' scripts.
Submitted by: Lytochkin Boris <lytboris gmail.com>
ping ICMP payload of packets being sent is increased with given step.
Sweeping pings are useful for testing problematic channels, MTU
issues or traffic policing functions in networks.
PR: bin/82625
Submitted by: Chris Hellberg <chellberg juniper.net> (with some cleanups)
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?)
