[Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

[hselasky (Hans Petter Selasky)]

hselasky accepted this revision.
hselasky added a comment.
This revision is now accepted and ready to land.

This looks usable.

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

To: rrs, gnn, rwatson, adrian, sbruno, lstewart, imp, hselasky
Cc: emaste, delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

[emaste (Ed Maste)]

emaste added a subscriber: emaste.

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

To: rrs, gnn, rwatson, adrian, sbruno, lstewart, hselasky, imp
Cc: emaste, delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 137089] [lagg] lagg falsely triggers IPv6 duplicate address detection

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=137089

Hiren Panchasara  changed:

   What|Removed |Added

 CC||hi...@freebsd.org

--- Comment #2 from Hiren Panchasara  ---
Is this still an issue? Is anybody running into this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)

[rrs (Randall Stewart)]

rrs added a comment.

Hans:

We have discussed that, and *no* it will *not* return the incorrect thing once
it can't be stopped. There is code in the callout_reset_sbt_on() that makes sure
zero is returned. The only way that zero will *not* be returned is if the 
PENDING
flag is set. That won't happen if the callout is the one waiting on a lock. So
the answer will be 0, and the new callout will be scheduled at the end
of the current one. However if before that can return (the callout) yes you will
get a 1, since the rescheduled callout from the first one that set the 
migration 
will see the subsequent migration flag and return one since that *was* 
rescheduled.

The exec_cancel flag is only valid or looked at in the case where the lock is 
set
on the callout.

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

To: rrs, gnn, rwatson, adrian, sbruno, lstewart, hselasky, imp
Cc: delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Netmap support for Linux Containers (veth)

[Luke McHale]

Hello Dr. Luigi Rizzo,

Thank you for your quick reply!  I’m glad to see veth is already in the works.  
While I am new to netmap, we are aiming to utilize it in several of our 
projects.  I currently have two tasks, including:
- patch veth
- patch eTSEC (gianfar) controller

Since these tasks are gating our current work, we would really appreciate any 
insight/pointers you may have and if possible, access to a repository with 
preliminary veth modifications.  Any assistance you can provide in 
jump-starting our efforts would be greatly appreciated!

Thank you,
Luke


> On Jan 28, 2015, at 7:21 PM, Luigi Rizzo  wrote:
> 
> On Wed, Jan 28, 2015 at 5:11 PM, Luke McHale  wrote:
>> Hello Dr. Luigi Rizzo and netmap contributors,
>> 
>> I am looking to integrate netmap capabilities into linux’s veth (Virtual
>> Ethernet device) for netmap support within linux containers.  Does a patch
>> currently exist?  If not, do you have any intuition as to what it would take
>> to add netmap capability?  I am new to the netmap framework and I would
>> appreciate any help you can provide toward patching veth for netmap.
>> 
> 
> we do have an initial version of netmap support for veth (Linux; in
> FreeBSD would be epair),
> 
> 
> Hopefully we will be able to complete and distribute the veth code shortly.
> 
> If you are not familiar with netmap internals it may be easier to wait
> for our code than start developing your own.
> 
> As a temporary workaround you can surely use VALE switches or
> netmap pipes to connect different containers.
> 
> cheers
> luigi

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Updated] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

[imp (Warner Losh)]

imp added a comment.

For the commit, I'd separate out the timeout fix from the kernel testframework.

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

To: rrs, gnn, rwatson, adrian, sbruno, lstewart, hselasky, imp
Cc: delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1661: Add some security-related config parameters

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1660: Add support for mac-addr parameter

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1659: Register ixl as an SR-IOV-capable driver during attach

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

can't wait to see the infrastructure in place :)

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Netmap support for Linux Containers (veth)

[Luigi Rizzo]

On Wed, Jan 28, 2015 at 5:11 PM, Luke McHale  wrote:
> Hello Dr. Luigi Rizzo and netmap contributors,
>
> I am looking to integrate netmap capabilities into linux’s veth (Virtual
> Ethernet device) for netmap support within linux containers.  Does a patch
> currently exist?  If not, do you have any intuition as to what it would take
> to add netmap capability?  I am new to the netmap framework and I would
> appreciate any help you can provide toward patching veth for netmap.
>

we do have an initial version of netmap support for veth (Linux; in
FreeBSD would be epair),


Hopefully we will be able to complete and distribute the veth code shortly.

If you are not familiar with netmap internals it may be easier to wait
for our code than start developing your own.

As a temporary workaround you can surely use VALE switches or
netmap pipes to connect different containers.

cheers
luigi
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1658: Add sysctls for per-VF hardware counters

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

BRANCH
  review_D1658

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Netmap support for Linux Containers (veth)

[Luke McHale]

Hello Dr. Luigi Rizzo and netmap contributors,

I am looking to integrate netmap capabilities into linux’s veth (Virtual 
Ethernet device) for netmap support within linux containers.  Does a patch 
currently exist?  If not, do you have any intuition as to what it would take to 
add netmap capability?  I am new to the netmap framework and I would appreciate 
any help you can provide toward patching veth for netmap.

http://lxr.free-electrons.com/source/drivers/net/veth.c 


Thank you,
Luke McHale
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1657: Allow VFs to run while the PF is admin down

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

BRANCH
  review_D1657

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1656: Handle VFLR events from VFs

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

Looks good. Again, will need real world testing when we have infrastructure.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1655: Add support for GET_STATS VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

BRANCH
  review_D1655

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1654: Add support for CONFIG_PROMISCUOUS_MODE VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

No problems

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1653: Add support for ADD/DEL_VLAN VC messages

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

No issues.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1652: Add support for ADD/DEL_ETHER_ADDRESS VC messages

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

Good.

BRANCH
  review_D1652

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1651: Add support for ENABLE/DISABLE_QUEUES VC messages

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1650: Add support for CONFIG_IRQ_MAP VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1649: Add support for CONFIG_VSI_QUEUES VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

Don't see any problems.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Requested Changes To] D1648: Add stubs for deprecated VC messages

[jfvogel (Jack Vogel)]

jfvogel requested changes to this revision.
jfvogel added a comment.
This revision now requires changes to proceed.

Let's not mention Linux in our comments, either say nothing or think of 
something else :)

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1647: Add support for GET_VF_RESOURCES VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

seems fine

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1646: Add support for RESET_VF VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1645: Add support for VERSION VC message

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1644: Add infrastructure for handling the VC msg channel from VFs

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

Fine

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1641: Implement PCI SR-IOV initialization methods

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

Don't see any issues, of course the proof will come in the actual use when we
have the infrastructure :)

BRANCH
  review_D1641

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1642: Implement PCI SR-IOV method to initialize individual VFs

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
This revision is now accepted and ready to land.

BRANCH
  review_D1642

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Accepted] D1643: Implement resetting a VF

[jfvogel (Jack Vogel)]

jfvogel accepted this revision.
jfvogel added a comment.
This revision is now accepted and ready to land.

See no problems.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

[delphij (Xin Li)]

delphij added a subscriber: delphij.

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

To: rrs, gnn, rwatson, imp, adrian, sbruno, lstewart, hselasky
Cc: delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)

[hselasky (Hans Petter Selasky)]

hselasky added a comment.

Did you upload the correct patch?

INLINE COMMENTS
  sys/kern/kern_timeout.c:674 I don't mean inside the if (c_lock != NULL) { }
  There should be an else case after it.
  if (c_lock != NULL) {
   ... 
  } else {
 /* The callout cannot be stopped now */
cc_exec_cancel(cc, direct) = true;  /* XXX this piece is missing */
  }
  
  Because else callout_stop() will return (1) when cancel() == false, which is 
a lie. It cannot stop the MPSAFE callout in this case and has to let it run ???

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

To: rrs, gnn, rwatson, imp, adrian, sbruno, lstewart, hselasky
Cc: neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Updated, 895 lines] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

[rrs (Randall Stewart)]

rrs updated this revision to Diff 3503.
rrs added a comment.

This addresses all of the concerns of Hans.
I still need help with getting MK_TESTKERN to properly be
placed in the /mk infrastructure, I have pending queries to GNN and JHB on 
this...

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D1711?vs=3498&id=3503

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

AFFECTED FILES
  sys/amd64/conf/GENERIC
  sys/conf/files
  sys/conf/options
  sys/kern/kern_testfrwk.c
  sys/kern/kern_timeout.c
  sys/modules/Makefile
  sys/modules/callout_test/Makefile
  sys/modules/callout_test/callout_test.c
  sys/sys/callout.h
  sys/sys/callout_test.h
  sys/sys/kern_testfrwk.h

To: rrs, gnn, rwatson, imp, adrian, sbruno, lstewart, hselasky
Cc: neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

FreeBSD & Netmap Advocacy on Nanog

[Eduardo Meyer]

Hello,

I don't know who follows NANOG, but a recent discussion raised a positive
position much likely suitable to the advocacy mailing list, concerning
FreeBSD Netmap vs Intel DPDK and so on.

I believe it's worth sharing this guy's point of view and case:

http://mailman.nanog.org/pipermail/nanog/2015-January/072864.html

I quite agre with those statements, and I specially agree with this
excerpts:

"I honestly hope a fraction of this million dollar donated to FreeBSD
Foundation from WhatsApp founder goes on research and enhancements for
Netmap technology.

It's the most promising networking technology I have seen in the last
years, and it goes straight to what FreeBSD does best: networking
performance. It's not a coincidence that since the beginning of Internet,
top Internet traffic servers, from Yahoo! to WhatsApp and Netflix, run
FreeBSD.

I don't know how important decisions can be addressed concerning adding to
a Netmap stack a superset of full forwarding capability along with lagg(4),
vlan(4), Q-in-Q, maybe carp(4) and other lightweight but still very
kernel-path choppy features. But I hope FreeBSD engineers take good
decisions on assigning those issues. And address time, funds and goals to
Netmap.

For now, however, if you really want a relatively new and innovative
technology with actual code to use and run, ready and available, this is my
suggestion: FreeBSD+Netmap."

I completely agree Netmap is promising, innovative and adds incomparable
potentials for FreeBSD in the future and hope FreeBSD (Foundation &
Project) gives some extra attention future netmap enhancements.

I also agree Netmap has proven itself with more usable code, utilities and
samples provided by Professor Luigi Rizzo than Intel DPDK and Linux stuff
(aka DNA).


-- 
===
Eduardo Meyer
pessoal: dudu.me...@gmail.com
profissional: ddm.farmac...@saude.gov.br
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problems with IP fragments

[Wolff, Nicholas (Nick)]

We use the following for udp fragments specifically this issue actually.

# udp frags (large dnssec responses)
add 02030 allow udp from any to me frag



On 1/28/15, 1:08 PM, "Lev Serebryakov"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>On 28.01.2015 21:04, Freddie Cash wrote:
>
>>> Looks like "IP Fragments Filtered", but I don't understand — why
>>> and where?!
>>> 
>>> I'm using ipfw on both hosts, but I don't have any special rules
>>> about IP fragments at all! And as these systems are in
>>> completely different networks, with different uplinks and FreeBSD
>>> versions!
>>> 
>> 
>> ​IPFW doesn't deal with IP fragment reassembly by default.
>  Oh, I see. And as second fragment is not "UDP" (it doesn't have UDP
>header!), it doesn't pass through stateful firewall... I see now.
>Thank you.
>
>> You can add something like the following to the start of the IPFW
>> ruleset to work around it (one for each NIC):
>> 
>> ​$IPFW add reass ip from any to any in recv $NIC0 ​$IPFW add reass
>> ip from any to any in recv $NIC1 ...
>> 
>
>
>- -- 
>// Lev Serebryakov
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2.0.22 (MingW32)
>
>iQJ8BAEBCgBmBQJUySWbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
>ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
>QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP/WUP/RJUv19sCqjt3/a/TNH/b6vs
>8IcjQA3rD4i1NgUWn1w0Olro4SlzkbqDFzv/ShvNA5TSH6NbhJpaBkO9dno8nwDB
>8K1GuTqYnDqAIexHw+br/dkcTLrah4h80tiucn0fSs12qOFaN5zJGchLDpxeEEg5
>Okncf/0Ef20ooaUfRXwcD+C0gmaYkiWZ2+VcmbqsZvT3gvdAiEXpPJjqp3agUr/4
>aTGriLZwo6OHTZdW7FQuKIV+4KO2piga+pF1lZKb78VOwgEYhw3yISuFzddIdaUd
>T+Uj/qDjYgjqyxt+cSXIpnsY4jKQ6fR3EOoERgv5VXtRdunHC/6i9vygp6cga3rj
>EZNAFlc+6ecmX9yPCdV5ScCvjh8lYZKuQivYNMauwI8o+Jud3dHJTCtl3zaVl18C
>b2Y7+6gNY/oM78H1b63R79DVf+ohSmlLHW+hSqXfYcrqmT+ocCfOK13ybEoV93N1
>nTMEDom83lvMhbDm9HHSBYbMyDKKPf6bX4VX2aZbjL+3u5VBclgKHMIS2U5VUBm/
>h7fWIPys/XVs+eHNACkye0qh/7bHQ0GarMhJ27nHA+qrkbnmzqT1Ush7bQXyrgVJ
>MfzU/JI/1u5Dw558innRMLP+3FnjjiITth/ZQCVzNXndVai4vpVXfzNdCRhNGQgV
>kIJ0H5+AoXwiL5qLYR1x
>=MY36
>-END PGP SIGNATURE-
>___
>freebsd-net@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-net
>To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)

[rrs (Randall Stewart)]

rrs added a comment.

Moving the tests to a sub-dir sounds like a good idea as well.. Thanks Hans..

INLINE COMMENTS
  sys/kern/kern_timeout.c:674 Hans, no *you must* set it to false here in the 
soft clock so you can recognize if
  it is requested to be stopped (if possible).  The return codes are all 
correct if
  the c_lock is set or not.
  sys/kern/kern_timeout.c:1059 Sure I can do that.. I will ALT-Q it and see if 
I can get it better formatted 
  sys/modules/callout_test/callout_test.c:58 Sure thats a good ideas since they 
are only used in the module.
  sys/modules/callout_test/callout_test.c:69 ahh yes, it surely is. I had been 
testing it in a branch that did not have the define in callout.h and
  it must have slipped in.. good catch!
  sys/modules/callout_test/callout_test.c:254 Yes it is, since the MOD_QUIESCE 
may unload the model.. or it may not.
  sys/sys/callout_test.h:1 Good catch I will fix it ;-)
  sys/sys/kern_testfrwk.h:43 That sounds fine.. I was just copying how the 
callout code did it (which was
  without typedef) but we can do that too ;-)

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

To: rrs, gnn, rwatson, imp, adrian, sbruno, lstewart, hselasky
Cc: neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Requested Changes To] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by othe

[hselasky (Hans Petter Selasky)]

hselasky requested changes to this revision.
hselasky added a comment.
This revision now requires changes to proceed.

See comments given.

INLINE COMMENTS
  sys/kern/kern_timeout.c:674 cc_exec_cancel(cc, direct) should be true when 
c_lock == NULL, because the callback cannot be stopped then.
  sys/kern/kern_timeout.c:1059 Is this comment be properly formatted with 
regard to filling lines till end of line? ALT+Q in emacs??
  sys/modules/callout_test/callout_test.c:58 Should these variables all be 
static?
  sys/modules/callout_test/callout_test.c:69 Possibly this define is redundant.
  sys/modules/callout_test/callout_test.c:254 Is this check really needed?
  sys/sys/callout_test.h:1 Upper case inclusion guard.
  sys/sys/callout_test.h:1 Missing copyright for header file.
  sys/sys/kern_testfrwk.h:43 Should this function be typedefed:
  
  typedef void (kern_testframework_func_t)(struct kern_test *);

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

To: rrs, gnn, rwatson, imp, adrian, sbruno, lstewart, hselasky
Cc: neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Updated] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

[hselasky (Hans Petter Selasky)]

hselasky added a comment.

Hi,

Should the callout_test module be put in a separate directory?

sys/modules/test_frwk
sys/modules/test_frwk/callout

When more tests are added that makes it easy exclude them from the build.

--HPS

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

To: rrs, gnn, rwatson, imp, adrian, sbruno, lstewart, hselasky
Cc: neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problems with IP fragments

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 28.01.2015 21:04, Freddie Cash wrote:

>> Looks like "IP Fragments Filtered", but I don't understand — why
>> and where?!
>> 
>> I'm using ipfw on both hosts, but I don't have any special rules 
>> about IP fragments at all! And as these systems are in
>> completely different networks, with different uplinks and FreeBSD
>> versions!
>> 
> 
> ​IPFW doesn't deal with IP fragment reassembly by default.
  Oh, I see. And as second fragment is not "UDP" (it doesn't have UDP
header!), it doesn't pass through stateful firewall... I see now.
Thank you.

> You can add something like the following to the start of the IPFW
> ruleset to work around it (one for each NIC):
> 
> ​$IPFW add reass ip from any to any in recv $NIC0 ​$IPFW add reass
> ip from any to any in recv $NIC1 ...
> 


- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUySWbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP/WUP/RJUv19sCqjt3/a/TNH/b6vs
8IcjQA3rD4i1NgUWn1w0Olro4SlzkbqDFzv/ShvNA5TSH6NbhJpaBkO9dno8nwDB
8K1GuTqYnDqAIexHw+br/dkcTLrah4h80tiucn0fSs12qOFaN5zJGchLDpxeEEg5
Okncf/0Ef20ooaUfRXwcD+C0gmaYkiWZ2+VcmbqsZvT3gvdAiEXpPJjqp3agUr/4
aTGriLZwo6OHTZdW7FQuKIV+4KO2piga+pF1lZKb78VOwgEYhw3yISuFzddIdaUd
T+Uj/qDjYgjqyxt+cSXIpnsY4jKQ6fR3EOoERgv5VXtRdunHC/6i9vygp6cga3rj
EZNAFlc+6ecmX9yPCdV5ScCvjh8lYZKuQivYNMauwI8o+Jud3dHJTCtl3zaVl18C
b2Y7+6gNY/oM78H1b63R79DVf+ohSmlLHW+hSqXfYcrqmT+ocCfOK13ybEoV93N1
nTMEDom83lvMhbDm9HHSBYbMyDKKPf6bX4VX2aZbjL+3u5VBclgKHMIS2U5VUBm/
h7fWIPys/XVs+eHNACkye0qh/7bHQ0GarMhJ27nHA+qrkbnmzqT1Ush7bQXyrgVJ
MfzU/JI/1u5Dw558innRMLP+3FnjjiITth/ZQCVzNXndVai4vpVXfzNdCRhNGQgV
kIJ0H5+AoXwiL5qLYR1x
=MY36
-END PGP SIGNATURE-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problems with IP fragments (was: Problems with DNSSEC -- answer in fragmented UDP doesn't work)

[Freddie Cash]

On Wed, Jan 28, 2015 at 9:53 AM, Lev Serebryakov  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 28.01.2015 20:38, Matthew Seaman wrote:
>
> > What do you get if you run the reply size test at DNS-OARC ?
> >
> > https://www.dns-oarc.net/oarc/services/replysizetest
>  0 lines (empty answer) at CURRENT, only "rst.x1013.rs.dns-oarc.net."
> on 9.3.
>
>  Looks like "IP Fragments Filtered", but I don't understand — why and
> where?!
>
>  I'm using ipfw on both hosts, but I don't have any special rules
> about IP fragments at all! And as these systems are in completely
> different networks, with different uplinks and FreeBSD versions!
>

​IPFW doesn't deal with IP fragment reassembly by default.

You can add something like the following to the start of the IPFW ruleset
to work around it (one for each NIC):

​$IPFW add reass ip from any to any in recv $NIC0
​$IPFW add reass ip from any to any in recv $NIC1
...

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

[neel (Neel Natu)]

neel added a subscriber: neel.

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

To: rrs, gnn, rwatson, imp, hselasky, adrian, sbruno, lstewart
Cc: neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Problems with IP fragments (was: Problems with DNSSEC -- answer in fragmented UDP doesn't work)

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 28.01.2015 20:38, Matthew Seaman wrote:

> What do you get if you run the reply size test at DNS-OARC ?
> 
> https://www.dns-oarc.net/oarc/services/replysizetest
 0 lines (empty answer) at CURRENT, only "rst.x1013.rs.dns-oarc.net."
on 9.3.

 Looks like "IP Fragments Filtered", but I don't understand — why and
where?!

 I'm using ipfw on both hosts, but I don't have any special rules
about IP fragments at all! And as these systems are in completely
different networks, with different uplinks and FreeBSD versions!

> This should help you eliminate restrictions on the size of DNS 
> responses, rather than it being a DNSSEC specific problem.
  Yes, it is EDNS more-than-one-UDP-dataggram problem, not
DNSSEC-specific one.

> If you're on 10.x or above, try enabling local_unbound -- beware
> that there's a bug that prevents resolution of RFC1918 and other
> special IP ranges on 10.0, fixed in 10.1.  Using a local unbound as
> a forwarder should give you the ability to tweak exactly how it
> talks to your upstream DNSes so that the answers get through more
> reliably.
 Unfortunately, I need recursive resolver for my network and
authoritative server (with views!) on one host. unbound could not do
that, so I'm using bind from ports on CURRENT.

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUySIiXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePUt4P/3Ubd77zLlazBQ8ZiQ/hS/O6
Y/t8lAMmRW2OiNO4FU0EuakSj3WxvEITTjVcX46o/K7ZBYGxa6r5Zq5OWw1rVlii
KfDesQQHZzCV9WyJI4bp84FyaxFlKzEsBVTbVU8YNvKrBtJqhfL7iGr1aM5Xgvag
j6KffsfVkozC8c/WKLHDKriFbR9NzTO1t1DWcWymS3a2PT/Ih1USycb+bZ+xDqFB
TXICX0+OZ9h956RP2gGsSdpEvJAP5OTW+daoaDfvHjTdrx77SyfAxHQop7ROEy7n
5blMTVMHBs1iK/hfAfuiXkCAVpAssqOrLEk5mb+SdX5OgwOR79kshE/hyYeN28gg
wUjX6FuAnb8HRvv4HNGqe82ptevammeWUSYrFuM2xzQqdfJOElTF3VDfk6FN+iT5
yCdVv2Oqsg6ZPB2dosWK5aWMUeVn5BYdwWD6Z3jrRFGONJ3V1pS17TpLL/bEd4Ta
u8A/tIbCLvfzNSrmrs4iXCRRfx1wDpFE+cvL5PXTlS3A8qf4Nm2EgOgv92Oz9862
0TJ/WvxvXn6QdSMXDvgMmk2DhclU3/L7aJy/of4QR1zwdJFwjuQSuhCjek/w1vw0
9wB8mjnVu0kIXa9z1FigI0X2fYF9rIB6YLca0N3SsGydm5p6zHFqIXNcYwTjHUg+
WOu4W9yfm0X10XHI3VdV
=+8Zi
-END PGP SIGNATURE-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problems with DNSSEC -- answer in fragmented UDP doesn't work

[Matthew Seaman]

On 01/28/15 17:13, Lev Serebryakov wrote:
> 
>  I could not resolve names with DNSSEC (for example, in freebsd.org
> domain) on two of my installations, one with FreeBSD 11 and other with
> FreeBSD 9.3.
> 
>  Symptoms are the same: answer is sent as fragmented IP/UDP packet and
> second part of answer is never arrived. For example, this doesn't work
> for me ("timeout" and only first part of fragmented packet on wire
> according to tcpdump):
> 
> % dig +dnssec www.freebsd.org @72.52.71.1
> 
> ; <<>> DiG 9.9.5 <<>> +dnssec www.freebsd.org @72.52.71.1
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> %
> 
>  Problem is, latest bind (9.9 from ports) send such requests over UDP,
> not TCP.
> 
>  Is it Ok? Is it misconfiguration of my networks (I have such problem
> in tow different installations) or something?

What do you get if you run the reply size test at DNS-OARC ?

https://www.dns-oarc.net/oarc/services/replysizetest

This should help you eliminate restrictions on the size of DNS
responses, rather than it being a DNSSEC specific problem.

Most queries nowadays are expected to run over UDP, even if the response
is too big to fit into a single UDP packet, by means of the EDNS
mechanism.  The old 'try UDP, and failing that, try again using TCP'
style should still work though, although TCP is only used routinely for
AXFR or IXFR type queries -- meaning that certain people may forget to
allow TCP queries via port 53 when setting up firewalls...

If you're on 10.x or above, try enabling local_unbound -- beware that
there's a bug that prevents resolution of RFC1918 and other special IP
ranges on 10.0, fixed in 10.1.  Using a local unbound as a forwarder
should give you the ability to tweak exactly how it talks to your
upstream DNSes so that the answers get through more reliably.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

[Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

[erj (Eric Joyner)]

erj added a subscriber: erj.

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

To: rrs, gnn, rwatson, imp, hselasky, adrian, sbruno, lstewart
Cc: erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Problems with DNSSEC -- answer in fragmented UDP doesn't work

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


 I could not resolve names with DNSSEC (for example, in freebsd.org
domain) on two of my installations, one with FreeBSD 11 and other with
FreeBSD 9.3.

 Symptoms are the same: answer is sent as fragmented IP/UDP packet and
second part of answer is never arrived. For example, this doesn't work
for me ("timeout" and only first part of fragmented packet on wire
according to tcpdump):

% dig +dnssec www.freebsd.org @72.52.71.1

; <<>> DiG 9.9.5 <<>> +dnssec www.freebsd.org @72.52.71.1
;; global options: +cmd
;; connection timed out; no servers could be reached
%

 Problem is, latest bind (9.9 from ports) send such requests over UDP,
not TCP.

 Is it Ok? Is it misconfiguration of my networks (I have such problem
in tow different installations) or something?

- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUyRjSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePWP8P/Rnxgs5mAXzYTlYqa5S0e8H/
22bKyBIzqGiv6Ha33/qWLSl+bjVbMfYYJU8DHMv0kHp00JK1W5ezmq9GRm1OeDWS
EP/03Etrm2BInQM486GOXFsp2k1MGR/+GbrzXfCs/WZj1zbrNIZ6aqQ9WOOlnukJ
eEsTO7rBUiuW6PbCAHSvzw7BBWDX59+Mj2KgjEesL+E/CxMGQy2iskB8eLSDrgpJ
EXqB5mGYEgyTDRcQ+EZnYGowMUEU5ZWoS2uKJkH5M+9ok9uj/58z3hYxUy0Yr93K
VNaSfjZcvKB+Yfj/mOG+WbrBgz/kJmryyh676WBI0BvIEBKEo+3gcPJVZBnCxsed
fUvZxC/ARDHOljIQHglax1GWMRT1RR8idpAZoGvVxDEtygyfYLFhwIWITdffyR6G
CUY16Sjp1tWa6wADjal+pz1tE9V8n67tkNbGtZcwF7N2bAMfAmMTVG0LuOyWZWgC
DU2kOEX6lU6/Y/M+oY73yXzMf/fGdO6RI1SpVhBOiIBeRK7901JXng/IXAcV3k9D
tjw8C8lHoClU0gbNJuiEXFwWXIB6cUg0/55V4cuBFdHhqShBWdaVaLE/N5HSDhrp
ISoD+mcoBZs+QlP7gF2w+G+qvOq5BZB2Np/5WETs5Sk8HlFaWz2pseGN2t8AetvZ
iAvOQuKF2Kq+dg3dzOGj
=83vn
-END PGP SIGNATURE-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 895 lines] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

[rrs (Randall Stewart)]

rrs created this revision.
rrs added reviewers: gnn, rwatson, imp, hselasky, adrian, sbruno, lstewart.
rrs added a subscriber: freebsd-net.

REVISION SUMMARY
  The callout code had two specific bugs within it after the new CPU migration
  feature was added.
  1) The callout_active() call at times could lie to the KPI user, this is 
because
  during a migration the ACTIVE flag would have been removed so that 
  the semantics were broken. This could cause problems for KPI users 
  since the active flag is a key feature used by those declaring themselves 
MPSAFE
  and using there own lock (think TCP).
  2) There was a bug in the callout code where if a migration was going on and
  two calls were made to callout_reset (the first starting the migration) 
the second
  call would possibly corrupt the linked list (if it was the active callout 
about to execute) and
  thus we would spin forever in soft clock and this would result in a 
panic, spin lock held to long.

TEST PLAN
  I have added the kernel test framework and a callout_test module. This
  allows us to pound on the callout code with multiple threads resetting, 
draining
  and stopping callouts all at about the same time. This test without the fixes 
would
  lock up and panic with a spin lock held to long vs now it does not.
  
  I have also begun testing this on Netflix Caches to further validate that it 
does no harm
  and instead gets rid of a panic or two ;-)

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

AFFECTED FILES
  sys/amd64/conf/GENERIC
  sys/conf/files
  sys/conf/options
  sys/kern/kern_testfrwk.c
  sys/kern/kern_timeout.c
  sys/modules/Makefile
  sys/modules/callout_test/Makefile
  sys/modules/callout_test/callout_test.c
  sys/sys/callout.h
  sys/sys/callout_test.h
  sys/sys/kern_testfrwk.h

To: rrs, gnn, rwatson, imp, hselasky, adrian, sbruno, lstewart
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Jails, VIMAGE, and VLANs

[William Katsak]

Hello,
I am having a very frustrating issue with VIMAGE jails using VLANs on 
10.1-RELEASE. I posted this earlier to the FreeBSD forum, then realized 
that this is probably a better place.


Let me tell you about my issue:

If I set up my jails using a regular ethernet interface (em0), a bridge, 
and epairs, everything works beautifully. All networking works as expected.


However, if I try to do the exact same thing using a VLAN interface, 
everything ALMOST works, except for one thing:


I cannot communicate between the host and the jail.

I can ping in both directions, but nothing else. No TCP traffic seems to 
pass. To make it weirder, the jail can communicate perfectly with other 
machines on the VLAN, so the bridge itself seems to be (partially) working.


I've checked routing tables, firewalls, everything. Nothing seems to 
make sense, except that something is broken either inside the bridge or 
the VIMAGE code. Again, if I keep the config exactly the same, but use 
em0 instead of em0.100, everything works.


Does anyone have any ideas?

Thanks in advance.

-Bill

--
Here is the offending bridge config:

bridge1: flags=8843 metric 0 mtu 
1500

ether 02:f1:2d:eb:f9:01
nd6 options=1
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair5a flags=143
ifmaxaddr 0 port 13 priority 128 path cost 2000
member: epair4a flags=143
ifmaxaddr 0 port 12 priority 128 path cost 2000
member: em0.100 flags=143
ifmaxaddr 0 port 4 priority 128 path cost 2

--

William Katsak 
Ph.D. Student
Rutgers University
Department of Computer Science

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 151 lines] D1708: sfxge: Separate software Tx queue limit for non-TCP traffic

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Add separate software Tx queue limit for non-TCP traffic to make total
  limit higher and avoid local drops of TCP packets because of no
  backpressure.
  There is no point to make non-TCP limit high since without backpressure
  UDP stream easily overflows any sensible limit.
  
  Split early drops statistics since it is better to have separate counter
  for each drop reason to make it unabmiguous.
  
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  share/man/man4/sfxge.4
  sys/dev/sfxge/sfxge_port.c
  sys/dev/sfxge/sfxge_tx.c
  sys/dev/sfxge/sfxge_tx.h

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [Differential] [Request, 30 lines] D1707: sfxge: access statistics buffers under port lock

[Matthias Apitz]

El día Wednesday, January 28, 2015 a las 09:12:42AM +, arybchik (Andrew 
Rybchenko) escribió:

> arybchik created this revision.
> arybchik added a reviewer: gnn.
> arybchik added a subscriber: freebsd-net.
> 
> REVISION SUMMARY
>   Allow access to statistics data not only from sysctl handlers.
>   
>   Submitted by:   Boris Misenov 
>   Sponsored by:   Solarflare Communications, Inc.
> 
> BRANCH
>   /head
> ...

Hello,

My I kindly opt to move such state message to another list, or create
one for this purpose? This list, freebsd-net@, is more a discussion list
as it says:

About freebsd-net   
English (USA)

Discussions of networking in general and TCP/IP source code in particular.

Thanks in advance

matthias
-- 
Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211
1989-2014: The Wall was torn down so that we go to war together again.
El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez.
Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 30 lines] D1707: sfxge: access statistics buffers under port lock

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Allow access to statistics data not only from sysctl handlers.
  
  Submitted by:   Boris Misenov 
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_port.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 15 lines] D1706: sfxge: implemented parameter to restrict RSS channels

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Submitted by:   Artem V. Andreev 
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  share/man/man4/sfxge.4
  sys/dev/sfxge/sfxge.c
  sys/dev/sfxge/sfxge.h
  sys/dev/sfxge/sfxge_intr.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 2 lines] D1705: sfxge: Use SFXGE_MODERATION to initialize event moderation

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_ev.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 2 lines] D1704: sfxge: Pass correct address to free allocated memory in the case of load error

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Most likely is was just memory leak on the error handling path since
  typically efsys_mem_t is filled in by zeros on allocation.
  
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_dma.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 1 lines] D1703: sfxge: Remove unused esm_size member of the efsys_mem_t structure

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  esm_size is not even initialized properly when memory is allocated.
  
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/common/efsys.h

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 2 lines] D1702: sfxge: Do not bzero() DMA allocated memory once again

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  sfxge_dma_alloc() calls bus_dmamem_alloc() with BUS_DMA_ZERO flag, so
  allocated memory is already filled in by zeros

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_port.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 17 lines] D1701: sfxge: Add evq argument to sfxge_tx_qcomplete()

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  It removes necessity to get evq pointer by its index in soft context.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_ev.c
  sys/dev/sfxge/sfxge_tx.c
  sys/dev/sfxge/sfxge_tx.h

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Updated] D1692: sfxge: Change sfxge_ev_qpoll() proto to avoid EVQ pointers array access

[arybchik (Andrew Rybchenko)]

arybchik set the repository for this revision to rS (FreeBSD src repository).

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

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 16 lines] D1700: sfxge: fixed TSO code to cope with VLAN headers

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Submitted by:   Artem V. Andreev 
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_tx.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 20 lines] D1699: sfxge: Remove extra cache-line alignment and reorder sfxge_evq_t

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Remove the first member alignment to cacheline since it is nop.
  Use __aligned() for the whole structure to make sure that the structure
  size is cacheline aligned.
  Remove lock alignment to make the structure smaller and fit all members
  used on event queue processing into one cacheline (128 bytes) on x86-64.
  The lock is obtained as well from different context when event queue
  statistics are retrived from sysctl context, but it is infrequent.
  Reorder members to avoid padding and go in usage order on event
  processing.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge.h

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 14 lines] D1698: sfxge: Make it possible to build without EVQ statistics

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/common/efx_ev.c
  sys/dev/sfxge/common/efx_tx.c
  sys/dev/sfxge/sfxge.h
  sys/dev/sfxge/sfxge_ev.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 35 lines] D1697: sfxge: Expect required init_state on data path and in periodic calls

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_ev.c
  sys/dev/sfxge/sfxge_intr.c
  sys/dev/sfxge/sfxge_port.c
  sys/dev/sfxge/sfxge_rx.c
  sys/dev/sfxge/sfxge_tx.c

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Request, 2 lines] D1694: sfxge: Move txq->next pointer to part writable on completion path

[arybchik (Andrew Rybchenko)]

arybchik created this revision.
arybchik added a reviewer: gnn.
arybchik added a subscriber: freebsd-net.

REVISION SUMMARY
  In fact the pointer is used only if more than one TXQ is processed in
  one
  interrupt.
  It is used (read-write) on completion path only.
  Also it makes the first part of the structure smaller and it fits now
  into one 128byte cache line. So, TXQ structure becomes 128 bytes
  smaller.
  
  Sponsored by:   Solarflare Communications, Inc.

BRANCH
  /head

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

AFFECTED FILES
  sys/dev/sfxge/sfxge_tx.h

To: arybchik, gnn
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"