Hi,
I have a small system running FreeBSD 8.2 that does NAT using ipfw and
natd to systems attached to two interfaces: em0 and wlan0. I have a
dhcpd daemon issuing leases on those interfaces. The system has an em1
interface plugged into a cable modem where it obtains a DHCP lease from
On 2013/01/31 16:45, Eggert, Lars wrote:
Hi,
I have a small system running FreeBSD 8.2 that does NAT using ipfw and
natd to systems attached to two interfaces: em0 and wlan0. I have a
dhcpd daemon issuing leases on those interfaces. The system has an em1
interface plugged into a cable modem
Hi,
On Jan 31, 2013, at 10:42, Kevin Lo ke...@kevlo.org wrote:
Use ipfw nat instead. It uses the libalias(3) in kernel and avoids
gigantic natd(8) overhead.
I tried that, but it froze the system.
Lars
___
freebsd-net@freebsd.org mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2013 11:31 PM, Eitan Adler wrote:
The patch is maleformed in the PR. Perhaps you could attach and
resend?
Gladly.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined -
On 01/31/13 00:45, Eggert, Lars wrote:
Hi,
I have a small system running FreeBSD 8.2 that does NAT using ipfw and
natd to systems attached to two interfaces: em0 and wlan0. I have a
dhcpd daemon issuing leases on those interfaces. The system has an em1
interface plugged into a cable
The following reply was made to PR kern/169438; it has been noted by GNATS.
From: George Kontostanos gkontos.m...@gmail.com
To: bug-follo...@freebsd.org, sakuma.takay...@jp.fujitsu.com
Cc:
Subject: re:kern/169438: [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work
Date: Thu, 31 Jan 2013
Old Synopsis: compatibility with EG20T PCH chipset ATOM E6xx series
New Synopsis: no ethernet detected on system with EG20T PCH chipset ATOM E6xx
series
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Jan 31 17:29:11 UTC 2013
I will not commit this patch, this is shared code used by all the different
OS's we do
drivers for, and it is unnecessary in any case, because the latest version
of the internal
code has this resolved So, I will soon do some updates to the e1000
drivers anyway
and as part of that I will sync
Hi Jack,
On Thu, Jan 31, 2013 at 12:03 PM, Jack Vogel jfvo...@gmail.com wrote:
I will not commit this patch, this is shared code used by all the different
OS's we do
drivers for, and it is unnecessary in any case, because the latest version
of the internal
code has this resolved So, I
I am testing the driver code witht he ralink nic. Yes the frame
aggregation works, since i get higher throughput. I am actually tryign to
know how many frames (MPDU's) are aggregated each time in an AMPDU.
Regarding the MPDU density - i was wondering how it should affect the Frame
aggregation.
Hi,
So the 30 second version:
* the maximum aggregation size in 802.11n is 65536 bytes, including
the between-frame delimiters;
* mpdu density defines how big those delimiters are - they're
calculated either in bytes or as a function of the currently selected
rate and duration, which ends up
I see that BPFIF_LOCK() in bpf_mtap() is getting invoked, even though
I am not tracing the interface. Is this expected?
-vijay
PS: I am running 8.2.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To
12 matches
Mail list logo
