On 5 June 2012 15:11, Michael Tuexen wrote:
> Why should it get lost? If there are no objections, I'll commit it. If there
> are, we'll see if we can resolve it.
Oh sweet, you can do that? Yes, I really would like to see this
particular feature in FreeBSD.
Thanks so much for coding it up!
Do y
On Jun 5, 2012, at 11:37 PM, Adrian Chadd wrote:
> Hi,
>
> can you please wrap this up in a PR so it's not lost?
Why should it get lost? If there are no objections, I'll commit it. If there
are, we'll see if we can resolve it.
Best regards
Michael
>
> thanks,
>
>
> Adrian
>
> On 5 June 2012
Hi,
can you please wrap this up in a PR so it's not lost?
thanks,
Adrian
On 5 June 2012 13:33, Michael Tuexen wrote:
> Dear all,
>
> there is currently no way to receive the TOS byte of a received UDP/IPv4
> packet.
> The attached patch adds a socket option (IP_RECVTOS) which you can use
> t
Dear all,
there is currently no way to receive the TOS byte of a received UDP/IPv4 packet.
The attached patch adds a socket option (IP_RECVTOS) which you can use
to get a cmsg of type (IP_RECVTOS) which contains the TOS byte. Much like
IP_RECVTTL does for TTL. Any comments/objections? If there are
In IPFilter, the "map-block" ipnat rule serves exactly the
purpose that you are looking for. It provides address
translation of network addresses for N:M and uses ports
to multiplex them in.
Thus a /16 can be nat'd to a /8 with the other 8 bits
used in the port number.
The results of the NAT'd pa
The problem is that you have a port range of 0 in an
ipnat.conf line. Quick solution is to ensure that all
ipnat.conf lines specify a range of ports of greater than 0.
Otherwise patch below applies.
Darren
--- /tmp/ip_nat.c.orig 2012-06-06 04:31:31.0 +1000
+++ /tmp/ip_nat.c 2012-0
Synopsis: [ipfilter] Fatal trap in ipfilter/ipnat
State-Changed-From-To: open->feedback
State-Changed-By: darrenr
State-Changed-When: Tue Jun 5 18:31:16 UTC 2012
State-Changed-Why:
Responsible-Changed-From-To: freebsd-net->darrenr
Responsible-Changed-By: darrenr
Responsible-Changed-When: Tue J
> Quoting from pfil(9)
>
> When a filter is invoked, the packet appears just as if it ``came off the
> wire''. That is, all protocol fields are in network byte order. [...]
pfil(9) is already out of date with respect to FreeBSD as
FreeBSD passes both ip_len and ip_off through in host byte
or
To echo comments made on tech-net for NetBSD...
---
As much as I dislike the patch you created, I can't see any other way
to elegantly solve the problem. The reason that I don't like the change
is that it seems silly to have to put the packet in two different mbufs
after having put it all in one.
Hi. Perhaps a naive question - why dont we have BUCKET_MAX beyond 128?
I would think that allocating a full page for buckets would be more
efficient and also reduce the number of bucket allocations needed for
other UMA zones.
On a related note is there a reason why zone_clust does not use
UMA_ZONE
I'm trying to set up a IPv6 router (running -current) on my home
network. My ISP gives me a /128 via PPP and I have a /48 allocation,
which I use to give em0 and tun0 public addresses in different subnets
(tun0 is assigned the address via ppp.linkup).
I've added all the IPv6 settings to rc.conf
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On
Behalf Of Adrian Chadd
Sent: Sunday, June 03, 2012 11:12 AM
To: Bjoern A. Zeeb
Cc: Jack F Vogel; FreeBSD Networking Mailing List
Subject: Re: ixgbe(4) intr and pps problems in at least HEAD
Quoting from pfil(9)
When a filter is invoked, the packet appears just as if it ``came off the
wire''. That is, all protocol fields are in network byte order. [...]
This should be extended to include the guarantee that the mbuf begins
with a contiguous IP header, i.e. mtod(*mp, struct ip *)
13 matches
Mail list logo
