When printing the interface name from the ipstate_t struct the interface
name in is_ifp may not always be avaiable when reading it from kmem
(tested on FreeBSD and NetBSD). However the is_ifname (the interface
name character string) is almost always available -- it is not available
when the source of the packet is a process running on the firewall
itself. Rather than print both interface name strings, print only the
one.
MFC after: 1 week
Rather than use a kmem read to determine the interface name used by a
nat_t structure through a pointer, nat_ipfs->netif->if_xname, obtain it
directly from nat_ifnames in the nat_t structure itself using the new
FORMAT_IF macro.
MFC after: 1 week
Interface names stored in the ipstate_t and ipnat_t structures can be
NULL. This occurs when an application, such as named, is running on the
firewall machine itself. For example an application, i.e. named, running
on the firewall itself will cause a state table display and NAT mapping
display to show a null ingress interface and its egress interface. This
is perfectly valid but confusing to human eyes. Rather than print
nothing, print "(null)".
MFC after: 1 week
Add serial-number sysctl if that fdt property exists and is a printable
string. While here, ensure that the hw.fdt sysctl values fit in the
buffers provided so that they will be NUL-terminated. Tested on
Raspberry Pi 3B+ and 4.
MFC after: 5 days
Reviewed by: manu imp
Differential Revision: https://reviews.freebsd.org/D34356
Use seperate nvlist entries for the romfile and the varfile.
While here, don't leak varfd in bootrom_loadrom().
Reviewed by: jhb, markj
Differential Revision: https://reviews.freebsd.org/D33433
VGA hardware provides many different graphics and data access modes,
each with different capabilities and limitations.
VGA vt(4) graphics mode operates on blocks of pixels at a time. When a
given pixel block contains only two colours the vt_vga driver uses write
mode 3. When the block contains more than two colours it uses write
mode 0. This is done because two-colour write mode 3 is much more
efficient.
In practice write mode 3 is used most of the time, as there is often a
single foreground colour and single background colour across the entire
console. One common exception requiring the use of mode 0 is when the
mouse cursor is drawn over a background other than black, as we need
black and white for the cursor in addition to the background colour.
VGA's default 16-colour palette provides the same set of colours as the
system console, but in a different order. Previously we configured a
non-default VGA palette that had the same colours at the same indexes.
However, this caused anything drawn before the kernel started (drawn by
the loader, for instance) to change colours once the kernel configured
the new, non-default palette.
In 5e251aec86 we switched to leaving the default VGA palette in place,
translating console colour indexes to VGA colour indexes as necessary.
This translation was missed for the write mode 0 case for pixel blocks
with more than two colours.
PR: 261751
Reviewed by: adrian
MFC after: 1 week
Fixes: 5e251aec86 ("vt(4): Use default VGA palette")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34412
Some chromebooks e.g. ASUS C300 have no valid _CID and _DSM ACPI
objects required for device identification and HID descriptor address
detection. Add quirk to allow required data to be hardcoded in to
driver.
MFC after: 2 month
This command is intended to be compatible with I2CRDWR ioctl.
It is required to perform arbitrary I2C transfers by device
drivers which can switch between HID and native non-HID modes.
MFC after: 2 month
This command is intended to be compatible with USB_REQUEST ioctl.
It is required to perform arbitrary control endpoint requests by device
drivers which can switch between HID and native non-HID modes.
MFC after: 2 month
hid_ioctl method executes arbitrary transport backend command.
Format of the command is defined by hardware transport driver.
It is intended to assist HID device drivers to execute non-HID commands
on hybrid devices like Elan and Apple touchpads which can be switched
between HID and proprietary modes.
MFC after: 2 month
Just as pfctl already does for other rules we print the ethernet rules
we would have loaded if '-n' is specified.
Sponsored by: Rubicon Communications, LLC ("Netgate")
When filtering Ethernet packets allow rules to specify a mac address
with a mask. This indicates which bits of the specified address are
significant. This allows users to do things like filter based on device
manufacturer.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Combine anchor, dummynet and rdr to produce a more complex captive
portal setup.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32484
Teach the 'ether' rules to accept { mac1, mac2, ... } lists, similar to
the lists of interfaces or IP addresses we already supported for layer 3
filtering.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32481
Ensure that the 'match' keyword works with dummynet
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32480
Test that we can set dummynet information on L2, which is processed by
L3 later (assuming it's not overruled by L3 rules, of course).
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32223
Allow packets to be tagged with dummynet information. Note that we do
not apply dummynet shaping on the L2 traffic, but instead mark it for
dummynet processing in the L3 code. This is the same approach as we take
for ALTQ.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32222
Document how 'ether' rules can be set, and what options they support.
Reviewed by: bcr
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31751
If we're not filtering on a specific MAC address don't print it at all,
rather than showing an all-zero address.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31749
Allow the evaluations/packets/bytes counters on Ethernet rules to be
cleared.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31748
Test that we correctly match inbound ('in') or outbound ('out') Ethernet
packets.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31747
Use the ether rules to selectively (i.e. per MAC address) redirect
certain connections. Test that tags carry over to the layer-3 pf code.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31746
Test that we can express 'ether block from ! 00:01:02:03:04:05'.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31744
Test the MAC address filtering capability in the new 'ether' feature in
pf.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31743
Avoid the overhead of the Ethernet pfil hooks if we don't have any
Ethernet rules.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31742
Avoid the overhead of acquiring a (read) RULES lock when processing the
Ethernet rules.
We can get away with that because when rules are modified they're staged
in V_pf_keth_inactive. We take care to ensure the swap to V_pf_keth is
atomic, so that pf_test_eth_rule() always sees either the old rules, or
the new ruleset.
We need to take care not to delete the old ruleset until we're sure no
pf_test_eth_rule() is still running with those. We accomplish that by
using NET_EPOCH_CALL() to actually free the old rules.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31739
