David Duchscher wrote:
On Jun 5, 2012, at 3:29 PM, Darren Reed wrote:
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 w
On Jun 5, 2012, at 3:29 PM, Darren Reed wrote:
> 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
*nod* sure, I just want to be sure that it's clearly documented what
the option does.
If it just does UDP for now and not TCP, then so be it, as long as
it's documented that way.
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
(also posted to FreeBSD forums)
I think I may be having an issue with window scaling (RFC 1323) and am hoping
that someone can enlighten me on what's going on.
Server: FreeBSD 9, apache22, serving a static 100MB zip file. 192.168.18.30
Client: Mac OS X 10.6, Firefox 192.168.17.47
Network: Only
On 6/6/12 11:54 AM, Michael Tuexen wrote:
> On Jun 6, 2012, at 7:17 PM, Adrian Chadd wrote:
>
>> Hi,
>>
>> For TCP, I've seen the network layer change things (eg setting bits on
>> incoming traffic to mark which interface it came in on), so you can't
>> guarantee the outbound ToS == inbound ToS.
>
On Jun 6, 2012, at 7:17 PM, Adrian Chadd wrote:
> Hi,
>
> For TCP, I've seen the network layer change things (eg setting bits on
> incoming traffic to mark which interface it came in on), so you can't
> guarantee the outbound ToS == inbound ToS.
I've not said that inbound == outbound... I just wa
Hi,
For TCP, I've seen the network layer change things (eg setting bits on
incoming traffic to mark which interface it came in on), so you can't
guarantee the outbound ToS == inbound ToS.
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.fr
Dear all,
anyone objecting to deliver IPV6_TCLASS, IPV6_HOPLIMIT and IPV6_PKTINFO cmsgs
(when
requested, of course) on IPV6 sockets, which have been marked to be not
IPV6_V6ONLY,
for each received IPV4 packet?
The reported tclass would be the TOS byte, the reported hlim would be the
received TT
On Jun 6, 2012, at 10:15 AM, Adrian Chadd wrote:
> Well,
>
> * Is it usable on a TCP socket?
No. The main application (I see) is to access the ECN bits. In the TCP case,
ECN is handled in the kernel, so there is no need to deal with them in
userland.
On the other hand, TCP is byte stream oriented
Well,
* Is it usable on a TCP socket?
* Is it usable on an outbound TCP socket (ie, where the receive end
has set the ToS bits on the received ToS), regardless of what you've
set for the sending ToS?
* Does the receive TOS change during the lifetime of a TCP connection?
If so, can this fetch it?
*
On Jun 6, 2012, at 8:50 AM, Adrian Chadd wrote:
> 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
> particula
11 matches
Mail list logo
