Re: Multicast routing on FreeBSD 11 current
On Saturday, 23 January 2016, Ben Woods wrote: > > I am running the GENERIC kernel, except with VIMAGE enabled and SCTP > disabled. > > When I try to load the kernel module, I am getting an error: > % sudo kldload -v ip_mroute > kldload: an error occurred while loading the module. Please check dmesg(8) > for more details. > % dmesg > linker_load_file: Unsupported file type > > Any ideas what could be causing this error? > > Thanks for your help. > > Regards, > Ben > > -- > From: Benjamin Woods > woods...@gmail.com > Hi everyone, Could someone running FreeBSD current on a test machine try loading the ip_mroute driver on their machine? This is to enable multicast routing, but I am wondering if it fails to load for everyone, or it is specific to my build some how. I am running r294463, please let me know which version you are running if it works or doesn't work. Regards, Ben -- -- From: Benjamin Woods woods...@gmail.com ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Does FreeBSD have sendmmsg or recvmmsg system calls?
On Sun, 24 Jan 2016 07:06:34 +0200
Konstantin Belousov wrote:
[delete irrelevant parts of the patch]
> > + rcvd = 1;
> > + for (i = rcvd; i < vlen; i++) {
> i = rcvd = 1; ... i++, rcvd++ ?
>
> > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags);
> > + if (ret == -1) {
> > + if (rcvd != 0) {
> > + /* We've received messages. Let caller know. */
> > + return (rcvd);
> > + }
> > + return (ret);
> > + }
> > +
This seems wrong. rcvd is initialized to 1 so that the check for
rcvd != 0 can never be false. We already successfully called
__sys_recvmsg() just above the loop, so why not simplify the
code by doing
if (ret == -1)
return (rcvd);
--
Gary Jennejohn (gj@)
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multicast routing on FreeBSD 11 current
On 24.01.16 01:14, Ben Woods wrote: > % sudo kldload -v ip_mroute > kldload: an error occurred while loading the module. Please check dmesg(8) > for more details. > % dmesg > linker_load_file: Unsupported file type > > Any ideas what could be causing this error? Usually this means that your running kernel is out of sync with modules. You are running r294463, but __FreeBSD_version was bumped recently in r294505. You need rebuild and reinstall your kernel and all modules. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Multicast routing on FreeBSD 11 current
On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods wrote: > > Hi everyone, > > Could someone running FreeBSD current on a test machine try loading the > ip_mroute driver on their machine? > Hi, no problem here: root@lame5 # uname -a FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu Jan 21 20:07:04 CET 2016 r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 root@lame5 # kldload ip_mroute root@lame5 # kldstat -m ip_mroute Id Refs Name 4971 ip_mroute Regards, Olivier ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 Olli Hauer changed: What|Removed |Added CC||oha...@freebsd.org --- Comment #1 from Olli Hauer --- Hm, looking man(4) oce there is a hint to address such issues to emulex. I was myself looking the last days for an LPe12000 (FC) driver (no luck) but there is one for the LPe16000 on the emulex site http://www.emulex.com/downloads/emulex/drivers/freebsd/freebsd-10/drivers/ -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 --- Comment #2 from Ron --- I looked there before opening the case, for me I just see this under download: "Ethernet Driver - Use inbox driver" -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 --- Comment #3 from Olli Hauer --- Hi Ron, you are right no download for 10.x, but there is a driver for 9.3 in the old pkg format. I'm not sure if it will work on 10.x and for FC but maybe give it a try. Perhaps Koobs or another Bugzilla admin can add the Emulex contact email address freebsd-driv...@emulex.com to the PR (does not exist until now so I cannot add the address to the CC list) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 --- Comment #4 from Ron --- I will give it a shot shortly, last time I tried this I had failures due to the change from gcc to clang. Will report back shortly. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 --- Comment #5 from Olli Hauer --- I forgot the change from gcc to clang already. oce.ko is a static module, and even it works I wouldn't trust in production without a vendor statement. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 Kubilay Kocak changed: What|Removed |Added Status|New |Open --- Comment #6 from Kubilay Kocak --- (In reply to Olli Hauer from comment #3) I don't think it's appropriate to create user accounts (to be CC'd on things) without asking, but if you could send them an email to create an account that would be great :) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multicast routing on FreeBSD 11 current
On Sun, 24 Jan 2016 13:17:45 +0300 "Andrey V. Elsukov" wrote: > On 24.01.16 01:14, Ben Woods wrote: > > % sudo kldload -v ip_mroute > > kldload: an error occurred while loading the module. Please check > > dmesg(8) for more details. > > % dmesg > > linker_load_file: Unsupported file type > > > > Any ideas what could be causing this error? > > Usually this means that your running kernel is out of sync with > modules. You are running r294463, but __FreeBSD_version was bumped > recently in r294505. You need rebuild and reinstall your kernel and > all modules. In this particular case the problem is that ip_mroute demands more space for "virtualized global" variables than what kernel linker has put aside for each vnet. Bumping VNET_MODMIN to 24 should circumvent the issue that Ben is observing. A more vnet-friendly fix would require refactoring ip_mroute's arrays so that they get malloc()ed / free()d from SYSINIT handlers instead of being declared "virtualized global". Marko === --- vnet.c (revision 294659) +++ vnet.c (working copy) @@ -170,7 +170,7 @@ * we want the virtualized global variable space to be page-sized, we may * have more space than that in practice. */ -#defineVNET_MODMIN 8192 +#defineVNET_MODMIN 3 * 8192 #defineVNET_SIZE roundup2(VNET_BYTES, PAGE_SIZE) #defineVNET_MODSIZE(VNET_SIZE - (VNET_BYTES - VNET_MODMIN)) ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multicast routing on FreeBSD 11 current
On 24 January 2016 at 11:36, Otacílio wrote: > Em 24/01/2016 07:24, Olivier Cochard-Labbé escreveu: > >> On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods wrote: >> >> Hi everyone, >>> >>> Could someone running FreeBSD current on a test machine try loading the >>> ip_mroute driver on their machine? >>> >>> Hi, >> >> no problem here: >> >> root@lame5 # uname -a >> FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu >> Jan 21 20:07:04 CET 2016 >> r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG >> amd64 >> root@lame5 # kldload ip_mroute >> root@lame5 >> >> # kldstat -m ip_mroute >> Id Refs Name >> 4971 ip_mroute >> >> >> Regards, >> >> Olivier >> >> > No problem here also. > > root@nostromo:~ # kldload ip_mroute > root@nostromo:~ # kldstat > Id Refs AddressSize Name > 1 34 0x8020 1e39ca8 kernel > 21 0x8203b000 e3b8 cuse.ko > 31 0x8204a000 3d90 pty.ko > 41 0x82221000 57b8 fdescfs.ko > 51 0x82227000 a3ac linprocfs.ko > 61 0x82232000 695a linux_common.ko > 71 0x82239000 26f8avboxguest.ko > 81 0x8226 7a9 vboxvideo.ko > 91 0x82261000 52092drm2.ko > 101 0x822b4000 2679 iicbus.ko > 111 0x822b7000 1f6a imgact_binmisc.ko > 121 0x822b9000 657f nullfs.ko > 131 0x822c abe8 tmpfs.ko > 141 0x822cb000 ceff ip_mroute.ko > root@nostromo:~ # uname -a > FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294319M: Tue Jan 19 > 20:29:21 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/GENERIC amd64 > Thanks for your feedback everyone. Having spent some time now investigating, I have confirmed that this problem is related to VIMAGE. With VIMAGE enabled in the kernel, loading the ip_mroute kernel module will fail. With VIMAGE disabled on the same kernel source (no other changes), loading the ip_mroute kernel module works fine. I have submitted this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206583 Regards, Ben -- From: Benjamin Woods woods...@gmail.com ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Problem reports for freebsd-net@FreeBSD.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- In Progress |203422 | mpd/ppoe not working with re(4) with revision 285 New |193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc New |203175 | Daily kernel crashes in tcp_twclose https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ipfw NAT /etc/rc.firewall question
Hi,
I am making myself learn better how ipfw works. I am curious about
the optimal location of the NAT rule definition code. My immediate
application is a generic NATing gateway with an outside iface armored
up and an inside iface permitting general anarchy. The usual services
will be accessible to both sides. I plan to use kernel nat.
Looking at /etc/rc.firewall:
In the "open" | "client" section, natd/kernel nat are configured prior
to other rules.
In the "simple" section, natd only is configured after a bunch of
rules, and before a bunch more.
My question is, right after the natd configuration, are a bunch of
rules that specify deny rules for problematic addresses. Here's the
beginning and end of the section I'm curious about:
${fwcmd} add deny all from "table($BAD_ADDR_TBL)" to any via ${oif}
if [ -n "$inet6" ]; then
# Stop unique local unicast address on the outside interface
${fwcmd} add deny all from fc00::/7 to any via ${oif6}
${fwcmd} add deny all from any to fc00::/7 via ${oif6}
...
${fwcmd} add deny all from ff05::/16 to any via ${oif6}
${fwcmd} add deny all from any to ff05::/16 via ${oif6}
fi
Reading the comment before the nat configuration and also many
comments provided by the goog, suggests it's better to define as many
rules as possible before the nat config.
But these rules are placed after. Can someone explain to me why this
is better|required? I suspect I am missing something possibly
important.
This is stable/10.
Thanks,
Russell
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Closed] D4972: hyperv/hn: Partly rework transmission path
This revision was automatically updated to reflect the committed changes.
Closed by commit rS294700: hyperv/hn: Partly rework transmission path (authored
by sephe).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D4972?vs=12444&id=12668#toc
REPOSITORY
rS FreeBSD src repository
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D4972?vs=12444&id=12668
REVISION DETAIL
https://reviews.freebsd.org/D4972
AFFECTED FILES
head/sys/dev/hyperv/netvsc/hv_net_vsc.c
head/sys/dev/hyperv/netvsc/hv_net_vsc.h
head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
head/sys/dev/hyperv/netvsc/hv_rndis.h
head/sys/dev/hyperv/netvsc/hv_rndis_filter.c
head/sys/dev/hyperv/netvsc/hv_rndis_filter.h
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, decui_microsoft.com, honzhan_microsoft.com,
howard0su_gmail.com, royger, network, adrian
Cc: freebsd-net-list
diff --git a/head/sys/dev/hyperv/netvsc/hv_rndis_filter.h b/head/sys/dev/hyperv/netvsc/hv_rndis_filter.h
--- a/head/sys/dev/hyperv/netvsc/hv_rndis_filter.h
+++ b/head/sys/dev/hyperv/netvsc/hv_rndis_filter.h
@@ -99,6 +99,7 @@
int hv_rf_on_receive(netvsc_dev *net_dev,
struct hv_device *device, netvsc_packet *pkt);
void hv_rf_receive_rollup(netvsc_dev *net_dev);
+void hv_rf_channel_rollup(netvsc_dev *net_dev);
int hv_rf_on_device_add(struct hv_device *device, void *additl_info);
int hv_rf_on_device_remove(struct hv_device *device, boolean_t destroy_channel);
int hv_rf_on_open(struct hv_device *device);
diff --git a/head/sys/dev/hyperv/netvsc/hv_rndis_filter.c b/head/sys/dev/hyperv/netvsc/hv_rndis_filter.c
--- a/head/sys/dev/hyperv/netvsc/hv_rndis_filter.c
+++ b/head/sys/dev/hyperv/netvsc/hv_rndis_filter.c
@@ -974,3 +974,21 @@
rndis_dev = (rndis_device *)net_dev->extension;
netvsc_recv_rollup(rndis_dev->net_dev->dev);
}
+
+void
+hv_rf_channel_rollup(netvsc_dev *net_dev)
+{
+ rndis_device *rndis_dev;
+
+ rndis_dev = (rndis_device *)net_dev->extension;
+
+ /*
+ * This could be called pretty early, so we need
+ * to make sure everything has been setup.
+ */
+ if (rndis_dev == NULL ||
+ rndis_dev->net_dev == NULL ||
+ rndis_dev->net_dev->dev == NULL)
+ return;
+ netvsc_channel_rollup(rndis_dev->net_dev->dev);
+}
diff --git a/head/sys/dev/hyperv/netvsc/hv_rndis.h b/head/sys/dev/hyperv/netvsc/hv_rndis.h
--- a/head/sys/dev/hyperv/netvsc/hv_rndis.h
+++ b/head/sys/dev/hyperv/netvsc/hv_rndis.h
@@ -1050,6 +1050,7 @@
netvsc_packet *packet,
rndis_tcp_ip_csum_info *csum_info);
void netvsc_recv_rollup(struct hv_device *device_ctx);
+void netvsc_channel_rollup(struct hv_device *device_ctx);
void* hv_set_rppi_data(rndis_msg *rndis_mesg,
uint32_t rppi_size,
diff --git a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
--- a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
+++ b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
@@ -129,6 +129,41 @@
#define HV_NV_SC_PTR_OFFSET_IN_BUF 0
#define HV_NV_PACKET_OFFSET_IN_BUF 16
+/* YYY should get it from the underlying channel */
+#define HN_TX_DESC_CNT 512
+
+#define HN_RNDIS_MSG_LEN \
+(sizeof(rndis_msg) + \
+ RNDIS_VLAN_PPI_SIZE + \
+ RNDIS_TSO_PPI_SIZE + \
+ RNDIS_CSUM_PPI_SIZE)
+#define HN_RNDIS_MSG_BOUNDARY PAGE_SIZE
+#define HN_RNDIS_MSG_ALIGN CACHE_LINE_SIZE
+
+#define HN_TX_DATA_BOUNDARY PAGE_SIZE
+#define HN_TX_DATA_MAXSIZE IP_MAXPACKET
+#define HN_TX_DATA_SEGSIZE PAGE_SIZE
+#define HN_TX_DATA_SEGCNT_MAX \
+(NETVSC_PACKET_MAXPAGE - HV_RF_NUM_TX_RESERVED_PAGE_BUFS)
+
+struct hn_txdesc {
+ SLIST_ENTRY(hn_txdesc) link;
+ struct mbuf *m;
+ struct hn_softc *sc;
+ int refs;
+ uint32_t flags; /* HN_TXD_FLAG_ */
+ netvsc_packet netvsc_pkt; /* XXX to be removed */
+
+ bus_dmamap_t data_dmap;
+
+ bus_addr_t rndis_msg_paddr;
+ rndis_msg *rndis_msg;
+ bus_dmamap_t rndis_msg_dmap;
+};
+
+#define HN_TXD_FLAG_ONLIST 0x1
+#define HN_TXD_FLAG_DMAMAP 0x2
+
/*
* A unified flag for all outbound check sum flags is useful,
* and it helps avoiding unnecessary check sum calculation in
@@ -174,21 +209,34 @@
static int hn_trust_hosttcp = 0;
TUNABLE_INT("dev.hn.trust_hosttcp", &hn_trust_hosttcp);
+#if __FreeBSD_version >= 1100045
+/* Limit TSO burst size */
+static int hn_tso_maxlen = 0;
+TUNABLE_INT("dev.hn.tso_maxlen", &hn_tso_maxlen);
+#endif
+
+/* Limit chimney send size */
+static int hn_tx_chimney_size = 0;
+TUNABLE_INT("dev.hn.tx_chimney_size", &hn_tx_chimney_size);
+
/*
* Forward declarations
*/
static void hn_stop(hn_softc_t *sc);
static void hn_ifinit_locked(hn_softc_t *sc);
static void hn_ifinit(void *xsc);
static int hn_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data);
-static int hn_start_locked(struct ifnet *ifp);
+static void hn_start_locked(struct ifnet *ifp);
static void hn_start(struct ifnet *ifp);
static int hn_ifmedia_upd(struct ifnet *ifp);
static void hn_ifmedia_sts(struct ifnet
[Differential] [Closed] D4977: hyperv/hn: Use m_copydata for chimney sending.
This revision was automatically updated to reflect the committed changes.
Closed by commit rS294701: hyperv/hn: Use m_copydata for chimney sending.
(authored by sephe).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D4977?vs=12412&id=12669#toc
REPOSITORY
rS FreeBSD src repository
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D4977?vs=12412&id=12669
REVISION DETAIL
https://reviews.freebsd.org/D4977
AFFECTED FILES
head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
CHANGE DETAILS
diff --git a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
--- a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
+++ b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
@@ -756,7 +756,6 @@
struct hv_device *device_ctx = vmbus_get_devctx(sc->hn_dev);
netvsc_dev *net_dev = sc->net_dev;
netvsc_packet *packet;
- struct mbuf *m_head, *m;
struct ether_vlan_header *eh;
rndis_msg *rndis_mesg;
rndis_packet *rndis_pkt;
@@ -767,8 +766,6 @@
int ether_len;
uint32_t rndis_msg_size = 0;
uint32_t trans_proto_type;
- uint32_t send_buf_section_idx =
- NVSP_1_CHIMNEY_SEND_INVALID_SECTION_INDEX;
if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=
IFF_DRV_RUNNING)
@@ -778,6 +775,7 @@
bus_dma_segment_t segs[HN_TX_DATA_SEGCNT_MAX];
int error, nsegs, i, send_failed = 0;
struct hn_txdesc *txd;
+ struct mbuf *m_head;
IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head);
if (m_head == NULL)
@@ -940,24 +938,21 @@
/* send packet with send buffer */
if (packet->tot_data_buf_len < sc->hn_tx_chimney_size) {
+ uint32_t send_buf_section_idx;
+
send_buf_section_idx =
hv_nv_get_next_send_section(net_dev);
if (send_buf_section_idx !=
NVSP_1_CHIMNEY_SEND_INVALID_SECTION_INDEX) {
- char *dest = ((char *)net_dev->send_buf +
- send_buf_section_idx *
- net_dev->send_section_size);
+ uint8_t *dest = ((uint8_t *)net_dev->send_buf +
+ (send_buf_section_idx *
+ net_dev->send_section_size));
memcpy(dest, rndis_mesg, rndis_msg_size);
dest += rndis_msg_size;
- for (m = m_head; m != NULL; m = m->m_next) {
- if (m->m_len) {
- memcpy(dest,
- (void *)mtod(m,
vm_offset_t),
- m->m_len);
- dest += m->m_len;
- }
- }
+
+ m_copydata(m_head, 0, m_head->m_pkthdr.len,
+ dest);
packet->send_buf_section_idx =
send_buf_section_idx;
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, royger, decui_microsoft.com, honzhan_microsoft.com,
howard0su_gmail.com, delphij, adrian, network
Cc: freebsd-net-list
diff --git a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
--- a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
+++ b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
@@ -756,7 +756,6 @@
struct hv_device *device_ctx = vmbus_get_devctx(sc->hn_dev);
netvsc_dev *net_dev = sc->net_dev;
netvsc_packet *packet;
- struct mbuf *m_head, *m;
struct ether_vlan_header *eh;
rndis_msg *rndis_mesg;
rndis_packet *rndis_pkt;
@@ -767,8 +766,6 @@
int ether_len;
uint32_t rndis_msg_size = 0;
uint32_t trans_proto_type;
- uint32_t send_buf_section_idx =
- NVSP_1_CHIMNEY_SEND_INVALID_SECTION_INDEX;
if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=
IFF_DRV_RUNNING)
@@ -778,6 +775,7 @@
bus_dma_segment_t segs[HN_TX_DATA_SEGCNT_MAX];
int error, nsegs, i, send_failed = 0;
struct hn_txdesc *txd;
+ struct mbuf *m_head;
IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head);
if (m_head == NULL)
@@ -940,24 +938,21 @@
/* send packet with send buffer */
if (packet->tot_data_buf_len < sc->hn_tx_chimney_size) {
+ uint32_t send_buf_section_idx;
+
send_buf_section_idx =
hv_nv_get_next_send_section(net_dev);
if (send_buf_section_idx !=
NVSP_1_CHIMNEY_SEND_INVALID_SECTION_INDEX) {
-char *dest = ((char *)net_dev->send_buf +
-send_buf_sectio
Re: ipfw NAT /etc/rc.firewall question
On Sun, 24 Jan 2016 17:41:17 -0700, Russell L. Carter wrote:
> Hi,
>
> I am making myself learn better how ipfw works. I am curious about
> the optimal location of the NAT rule definition code. My immediate
> application is a generic NATing gateway with an outside iface armored
> up and an inside iface permitting general anarchy. The usual services
> will be accessible to both sides. I plan to use kernel nat.
> Looking at /etc/rc.firewall:
>
> In the "open" | "client" section, natd/kernel nat are configured prior
> to other rules.
>
> In the "simple" section, natd only is configured after a bunch of
> rules, and before a bunch more.
Yes. The omission of kernel nat configuration (as well as just natd) in
'simple' is something I submitted patches for (to ipfw@) several times,
several years ago, to no avail. If using 'simple', you need to manually
add the kernel nat section, but omit the rulenumber (50). My patch just
made this a function setup_nat(), called with or without a rulenmber.
> My question is, right after the natd configuration, are a bunch of
> rules that specify deny rules for problematic addresses. Here's the
> beginning and end of the section I'm curious about:
>
> ${fwcmd} add deny all from "table($BAD_ADDR_TBL)" to any via ${oif}
> if [ -n "$inet6" ]; then
> # Stop unique local unicast address on the outside interface
> ${fwcmd} add deny all from fc00::/7 to any via ${oif6}
> ${fwcmd} add deny all from any to fc00::/7 via ${oif6}
> ...
> ${fwcmd} add deny all from ff05::/16 to any via ${oif6}
> ${fwcmd} add deny all from any to ff05::/16 via ${oif6}
> fi
>
> Reading the comment before the nat configuration and also many
> comments provided by the goog, suggests it's better to define as many
> rules as possible before the nat config.
In general I'd say the opposite is what's more usually suggested and
implemented, but as ever, 'it depends ..'
> But these rules are placed after. Can someone explain to me why this
> is better|required? I suspect I am missing something possibly
> important.
>
> This is stable/10.
With 'open' and 'client' the nat rules are placed right after those in
setup_loopback and setup_ipv6_mandatory so NAT is performed very early.
With 'simple' we are the gateway for our inside network, so we need to
block a) traffic from the outside from (e.g.) 192.168.0.0/16 when we're
internally using addresses in that range - or any of the others listed -
as coming in from outside these are (far from uncommon) bogons; and b)
block any traffic outbound to the internet that (still) has an internal
address, or any other bogus address we or any of our client boxes might
try sending from.
So we need to check inbound traffic (still TO our external address)
before performing NAT, and check outbound traffic after NAT (now FROM
our external address), which is what the placement of those rules either
side of NAT does.
Seems to me that all those ipv6 addresses could go into that table too,
simplifying that section to a couple of rules, but since I don't well
enough (ie hardly at all) understand ipv6 addressing, I'll leave that.
cheers, Ian
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
