unless pipe is idle. This should fix follwing issues:
- 'dummynet: OUCH! pipe should have been idle!' log messages.
- exceeding configured pipe bandwidth.
MFC after: 1 week
hooked and the difference in handling the 'enable' variable
for layer2 and layer3. The latter needs fixing once i figure out
how it worked pre-vnet.
MFC after: 7 days
table of functions.
This commit (which is heavily based on work done by Marta Carbone
in this year's GSOC project), removes the goto's and explicit
return from the inner switch(), so we will have a easier time when
putting the blocks into individual functions.
MFC after: 3 weeks
(gcc 4.x under linux, not sure how real is the complaint).
- rename a macro argument to prevent name clashes.
- add the macro name on a couple of #endif
- add a blank line for readability.
MFC after: 3 days
using the new option numbers, IP_FW3 and IP_DUMMYNET3.
Right now the modules return an error if called with those arguments
so there is no danger of unwanted behaviour.
MFC after: 3 days
No functional differences.
- use the div64() macro to wrap 64 bit divisions
(which almost always are 64 / 32 bits) so they are easier
to handle with compilers or OS that do not have native
support for 64bit divisions;
- use a local variable for p_numbytes even if not strictly
necessary on HEAD, as it reduces diffs with FreeBSD7
- in dummynet_send() check that a tag is present before
dereferencing the pointer.
- add a couple of blank lines for readability near the end of a function
MFC after: 3 days
It fixes the issue which keep-alive doesn't work for an IPv6.
PR: kern/117234
Submitted by: mlaier, Joost Bekkers <joost__at__jodocus.org>
MFC after: 1 month
priority for such important information as MASTER/BACKUP state change,
and used a normal logging priority for such innocent messages as receiving
short packet (which is a normal VRRP packet between some other routers) or
receving a CARP packet on non-carp interface (someone else running CARP).
This commit shifts message logging priorities to a more sane default.
so the size and alignment of the ipfw_insn is not compiler dependent.
No changes in the code generated by gcc.
There was only one instance of this kind in our entire source tree,
so i suspect the old definition was a poor choice (which i made).
MFC after: 3 days
Userland daemons need to see IGMP traffic regardless of the group;
omit the imo filter check if the proto is IGMP. The kernel part
of IGMP will have already filtered appropriately at this point.
MFC after: ASAP
Submitted by: Franz Struwig
Reported by: Ivor Prebeg, Franz Struwig
into libkern in order to made it usable by other modules than alias_proxy.
Obtained from: Sandvine Incorporated
Sponsored by: Sandvine Incorporated
MFC: 1 week
in OpenBSD. As it is now, there is no way for this to be useful, since IPsec
is free to forward packets via whatever interface it wants, so checking
capabilities of the interface passed from ip_output (fetched from the routing
table) serves no purpose.
Discussed with: sam@
send an ACK right away if data was drained from a TCP socket that had
previously advertised a zero-sized window. The current code requires the
receive window to be exactly zero for this to kick in. If window scaling is
enabled and the window is smaller than the scale, then the effective window
that is advertised is zero. However, in that case the zero-sized window
handling is not enabled because the window is not exactly zero. The fix
changes the code to check the raw window value against zero.
Reviewed by: bz
MFC after: 1 week
is compared against the entry expiration time value (that was set based
on time_second) to check if the current time is larger than the set
expiration time. Due to the +/- timer granularity value, the comparison
returns false, causing the alternative code to be executed. The
alternative code path freed the memory without removing that entry
from the table list, causing a use-after-free bug.
Reviewed by: discussed with kmacy
MFC after: immediately
Verified by: rnoland, yongari
1. There is a regression issue in the ARP code. The incomplete
ARP entry was timing out too quickly (1 second timeout), as
such, a new entry is created each time arpresolve() is called.
Therefore the maximum attempts made is always 1. Consequently
the error code returned to the application is always 0.
2. Set the expiration of each incomplete entry to a 20-second
lifetime.
3. Return "incomplete" entries to the application.
Reviewed by: kmacy
MFC after: 3 days
packet filters. ALso allows ipfw to be enabled on on ejail and disabled
on another. In 8.0 it's a global setting.
Sitting aroung in tree waiting to commit for: 2 months
MFC after: 2 months
segment is likely to trigger a TCP state change (i.e., FIN/RST/SYN).
If we later have to upgrade the lock, we acquire an inpcb reference
and drop both global/inpcb locks before reacquiring in-order. In
that gap, the connection may transition into TIMEWAIT, so we need
to loop back and reevaluate the inpcb after relocking.
MFC after: 3 days
Reported by: Kamigishi Rei <spambox at haruhiism.net>
Reviewed by: bz
