[Bug 216304] Adding xn0 to bridge0 causes kernel panic

2017-01-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216304

Mark Linimon  changed:

   What|Removed |Added

 CC|freebsd-am...@freebsd.org   |
   Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee 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: Resource Links are Broken

2017-01-21 Thread Jennifer Moyer
Hi again!

I just wanted to follow-up on my previous email and see if you can
help me with finding the right person who can fix those broken
resources on your site.
Would that be you?

Thanks and have a great day!
___
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: pf & NAT issue

2017-01-21 Thread Kristof Provost

On 21 Jan 2017, at 5:21, Bakul Shah wrote:

I finally had some time to look at the sources & noticed
/sys/netpfil/pf/pf.c:pf_purge_thread now runs 10 times a
second instead of once a second, which gave me the idea of
increasing "interval" timeout by a factor of 10 and this seems
to have mostly fixed the problem. But I don't know where the
actual problem is.  The logic is too complicated to understand
in a few minutes so I didn't try to find the root cause at the
moment.  [But I don't understand why pf times out normal
connections. Long lasting idle connections are perfectly fine.


Have you tried increasing the state limit? This sounds like your states 
are
being cleaned up, which might happen because you’re running close to 
the limit.



And fragment GC should not be coupled with connection state
expiry]

I think that’s simply because they both need a timeout and it’s more 
efficient

to handle both at the same time than to set two timers.

Regards,
Kristof
___
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: RFC: ethctl

2017-01-21 Thread Hooman Fazaeli

On 2017-01-20 07:28, Kevin Bowling wrote:

Greetings,

I'm casting a wide net in cc, try to keep the noise minimal but we need
some input from a variety of HW vendors.

I have heard from several vendors the need for a NIC configuration tool.
  Chelsio ships a cxgb/cxgbetool in FreeBSD as one example.  There is
precedence for some nod toward a basic unified tool in Linux ethtool.

 From your perspective,
1) What are the common requirements?
2) What are specialized requirements? For instance as a full TCP offload
card Chelsio needs things others wont
3) What should it _not_ do?  Several of you have experience doing Ethernet
driver dev on many platforms so we should attempt to avoid repeating past
design mistakes.

I expect we can achieve some level of inversion so the device specific code
can live close to the driver and plug into the ethctl framework.  It should
be general enough to add completely new top level commands, so vendors can
implement HW specific features.  On the other hand, we should attempt to
hook into common core for features every NIC provides, with a focus on
iflib.

I will fund Matt Macy to do the overall design and implementation.

Regards,
Kevin Bowling, on behalf of Limelight Networks for this effort
___
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"


I always wished FreeBSD had a device-independent tool/API which could be used 
to query a
device's Ethernet specific statisticssuch ascollisions, 
symbol/sequence/CRC/alignment errors,
missed packets, giants & runts,link state IRQs, mbuf allocation fails, ... 
which are
valuable for monitoring and diagnostics (BTW, I am aware that some drivers 
export a
few counters via sysctl interface, but what I am talking about is a 
standardized set
of counters available for _all_ Ethernet devices).


--
Best regards
Hooman Fazaeli

___
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] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE

2017-01-21 Thread ale (Alex Dupre)
ale created this revision.
ale added reviewers: network, julian.
ale added subscribers: freebsd-net-list, mandree.
ale set the repository for this revision to rS FreeBSD src repository.
Herald added a subscriber: imp.
Herald added a reviewer: manpages.

REVISION SUMMARY
  Add support for user-supplied Host-Uniq tag in Netgraph PPPoE.
  A few ISP filter PADI requests based on such tag, to force the use of their 
own routers.
  The custom Host-Uniq tag is passed in the NGM_PPPOE_CONNECT control message, 
so it can be used with FreeBSD ppp(8) without any other change.

TEST PLAN
  I've tested the three possible Host-Uniq tags (auto-generated as before, long 
plain string and long binary string) with my own ISP connection.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D9270

AFFECTED FILES
  share/man/man4/ng_pppoe.4
  sys/netgraph/ng_pppoe.c

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: ale, #network, #manpages, julian
Cc: mandree, imp, freebsd-net-list
diff --git a/sys/netgraph/ng_pppoe.c b/sys/netgraph/ng_pppoe.c
--- a/sys/netgraph/ng_pppoe.c
+++ b/sys/netgraph/ng_pppoe.c
@@ -226,9 +226,11 @@
 	const struct pppoe_tag	*tags[NUMTAGS];
 	u_int			service_len;
 	u_int			ac_name_len;
+	u_int			host_uniq_len;
 
 	struct datatag		service;
 	struct datatag		ac_name;
+	struct datatag		host_uniq;
 };
 typedef struct sess_neg *negp;
 
@@ -589,18 +591,20 @@
 pppoe_finduniq(node_p node, const struct pppoe_tag *tag)
 {
 	hook_p	hook = NULL;
-	union uniq uniq;
+	sessp	sp;
 
-	bcopy(tag + 1, uniq.bytes, sizeof(void *));
 	/* Cycle through all known hooks. */
 	LIST_FOREACH(hook, &node->nd_hooks, hk_hooks) {
 		/* Skip any nonsession hook. */
 		if (NG_HOOK_PRIVATE(hook) == NULL)
 			continue;
-		if (uniq.pointer == NG_HOOK_PRIVATE(hook))
+		sp = NG_HOOK_PRIVATE(hook);
+		if (sp->neg->host_uniq_len == ntohs(tag->tag_len) &&
+		bcmp(sp->neg->host_uniq.data, (const char *)(tag + 1),
+		 sp->neg->host_uniq_len) == 0)
 			break;
 	}
-	CTR3(KTR_NET, "%20s: matched %p for %p", __func__, hook, uniq.pointer);
+	CTR3(KTR_NET, "%20s: matched %p for %p", __func__, hook, sp);
 
 	return (hook);
 }
@@ -853,23 +857,67 @@
 			 * Set up the session to the correct state and
 			 * start it.
 			 */
-			int	i, acnlen = 0, acnsep = 0, srvlen;
+			int	acnpos, acnlen = 0, acnsep = 0;
+			int	hupos, hulen = 0, husep = 0;
+			int	i, srvpos, srvlen;
+			acnpos = 0;
 			for (i = 0; i < ourmsg->data_len; i++) {
 if (ourmsg->data[i] == '\\') {
 	acnlen = i;
 	acnsep = 1;
 	break;
 }
 			}
-			srvlen = ourmsg->data_len - acnlen - acnsep;
+			hupos = acnlen + acnsep;
+			for (i = hupos; i < ourmsg->data_len; i++) {
+if (ourmsg->data[i] == '|') {
+	hulen = i - hupos;
+	husep = 1;
+	break;
+}
+			}
+			srvpos = hupos + hulen + husep;
+			srvlen = ourmsg->data_len - srvpos;
 
-			bcopy(ourmsg->data, neg->ac_name.data, acnlen);
+			bcopy(ourmsg->data + acnpos, neg->ac_name.data, acnlen);
 			neg->ac_name_len = acnlen;
 
+			neg->host_uniq.hdr.tag_type = PTT_HOST_UNIQ;
+			if (hulen == 0) {
+/* Not provided, generate one */
+neg->host_uniq.hdr.tag_len = htons(sizeof(sp));
+bcopy(&sp, neg->host_uniq.data, sizeof(sp));
+neg->host_uniq_len = sizeof(sp);
+			} else if (hulen > 2 && ourmsg->data[hupos] == '0' &&
+			  ourmsg->data[hupos + 1] == 'x' && hulen % 2 == 0) {
+/* Hex encoded */
+static const char hexdig[16] = "0123456789abcdef";
+int j;
+
+neg->host_uniq.hdr.tag_len = htons((uint16_t)(hulen / 2 - 1));
+for (i = 0; i < hulen - 2; i++) {
+	for (j = 0;
+	 j < 16 &&
+	 ourmsg->data[hupos + 2 + i] != hexdig[j];
+	 j++);
+	if (j == 16)
+		LEAVE(EINVAL);
+	if (i % 2 == 0)
+		neg->host_uniq.data[i / 2] = j << 4;
+	else
+		neg->host_uniq.data[i / 2] |= j;
+}
+neg->host_uniq_len = hulen / 2 - 1;
+			} else {
+/* Plain string */
+neg->host_uniq.hdr.tag_len = htons((uint16_t)hulen);
+bcopy(ourmsg->data + hupos, neg->host_uniq.data, hulen);
+neg->host_uniq_len = hulen;
+			}
+
 			neg->service.hdr.tag_type = PTT_SRV_NAME;
 			neg->service.hdr.tag_len = htons((uint16_t)srvlen);
-			bcopy(ourmsg->data + acnlen + acnsep,
-			neg->service.data, srvlen);
+			bcopy(ourmsg->data + srvpos, neg->service.data, srvlen);
 			neg->service_len = srvlen;
 			pppoe_start(sp);
 			break;
@@ -1061,10 +1109,6 @@
 	node_p	node = NG_HOOK_NODE(hook);
 	priv_p	privp = NG_NODE_PRIVATE(node);
 	negp	neg = sp->neg;
-	struct {
-		struct pppoe_tag hdr;
-		union	uniq	data;
-	} __packed uniqtag;
 	struct  mbuf *m0;
 	int	error;
 
@@ -1080,11 +1124,8 @@
 	memcpy((void *)&neg->pkt->pkt_header.eh, &privp->eh,
 	sizeof(struct ether_header));
 	neg->pkt->pkt_header.ph.code = PADI_CODE;
-	uniqtag.hdr.tag_type = PTT_HOST_UNIQ;
-	uniqtag.hdr.tag_len = htons((u_int16_t)sizeof(uniqtag.data));
-	uniqtag.data.pointer = sp;
 	init_tags(sp);
-	insert_tag(sp, &uniq