On Wed, Mar 06, 2013 at 09:25:21AM +0100, Andre Oppermann wrote:
> I'm trying to create a stack graph to see which parts of the network
> stack are involved in handling your packet.
Ask people if they're using multiple pfil hooks (even just having
ipfilter loaded counts, for instance).
If that's
On Tue, Aug 13, 2013 at 04:11:37PM +0400, ar...@artem.ru wrote:
> There is a router with 3 interfaces:
>
> IF1: PROVIDER A
> IF2: PROVIDER B
> IF3: LAN
>
> Clients served via NAT. There are about 15 clients.
>
> Now, what i need to do:
>
> By default all traffic from all clients goes to PROVID
On Thu, Aug 08, 2013 at 01:11:58PM +0100, Karl Pielorz wrote:
> Is there any way from rc.conf of creating a carp interface in the
> 'down' state - i.e. INIT?
I think any interface configured with ifconfig_* in rc.conf will cause
an explicit additional "ifconfig up" call from /etc/network.subr.
F
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 *)
On Mon, Jul 09, 2012 at 06:13:53PM +0700, Eugene Grosbein wrote:
> tcpdump shows no errors in fragment's checksums.
> Still, they were not reassembled.
I fed your two fragments (with libdnet) to ip_input.c ip_reass() with
debug printfs added, it reassembles them fine, even when in reversed order:
On Tue, Jul 10, 2012 at 07:27:04PM -0700, Chris Benesch wrote:
> The only thing I notice is that the ones coming from HE have the DF flag
> set? Am I on the wrong path? Have no idea how to get this to work.
The problem isn't fragmentation (those DF packets are not large enough to
require fragme
On Thu, Jul 26, 2012 at 08:35:29AM +, m s wrote:
> hi all. I want to use tcpdump just for input or just for outout
> packet.isthis possible ? if no is there any other command that do
> this?
If filtering by source MAC (or IP) is not enough, you can patch tcpdump
to hack in '-a in|out' using p
On Tue, Nov 13, 2012 at 11:06:04PM -0800, Sean Chittenden wrote:
> Where does it say that it shouldn't be used? Which RFC & ?? There are plenty
> of RFCs and I haven't exhaustively read things, so I reserve the right to be
> wrong & corrected, but I haven't seen anything that says, "do not use
On Fri, Dec 17, 2010 at 06:32:49AM +, Jayster wrote:
> I have tried both PF and IPFW. Different posts around the web claim Multiple
> Gateway solutions using both of them. I have tried each of the recommended
> setups, but had no luck. If you read the last responses to each of those
> posts
On Thu, Dec 23, 2010 at 05:47:14PM +0330, Mohammad Hedayati wrote:
> Suppose we've created a stream socket between two nodes. What happens
> if you write large chunks of data into the socket but the other pair
> doesn't read that for presumably long time?! Does the connection fail
> or data is mis
On Sun, Jan 16, 2011 at 01:41:22PM +0100, Paul Schenkeveld wrote:
> There is an ARP request which is replied to by the carp master (test).
> the ping to the carp address does not even appear on the sis4 interface
> of test1.
Everything looks fine, except for the fact that the ping (echo request)
On Tue, Mar 01, 2011 at 02:49:29PM +0530, Saurav Dasgupta wrote:
> TCP session is up. By default the rx buffer window size is 64k.Traffic flow
> is fine. When the buffer size is increased while connection is up, rx buffer
> window size is updated automatically with the new value.
> But if we dec
On Fri, Mar 18, 2011 at 04:43:59PM +0100, Viktor Petersson wrote:
> Mar 7 14:42:57 nas0 kernel: carp0: MASTER -> BACKUP (more frequent
> advertisement received)
This could mean that the master is receiving its own CARP advertisements
back, and, thinking they come from another host, backs
What if your modified (shortened) packet does get lost? If you
messed with the tcpcb in the way you intend, how do you plan on
getting retransmission working, when it's needed?
Or what if you enlarge a packet, are you sure it won't violate
the MTU?
It seems you're doing this on wrong side of the
On Tue, May 17, 2011 at 03:16:51PM +0200, Cole wrote:
> Also the goal im working for is to be able to use
> this on a box doing routing to hopefully get some sort of compression
> working between 2 end points. So most of the data would not actual be
> generated from userland processes.
But on a r
On Tue, Mar 16, 2010 at 03:19:51PM -0400, kevin wrote:
> I would like to assist in diagnosing this issue so if anyone wants me to
> check anything or test, please let me know. I would really like to
> understand this problem.
What are your settings for
$ sysctl -a | grep bridge.pfil
Have you
In your setup, the data is flowing from the iperf client (sender) on
NPX4 to the iperf server (receiver) on NPX1.
Apply the queue on the interface on NPX3 where the data is flowing
out, i.e. the interface facing NPX1. Queueing applies to outgoing
packets of an interface, not incoming packets.
It
When filtering statefully, there is no need for a specific rule allowing
ICMPv6 errors like ICMP6_PACKET_TOO_BIG. These ICMPv6 messages contain, as
payload, the header of the original packet that triggered the error. pf
extracts that inner header and searches for a matching state entry. If a
matchi
On Tue, Aug 21, 2007 at 03:37:52PM +0200, Jacek Zapala wrote:
> Attached.
Thanks, I'll study them.
Since you're using TCP window scaling, could you try disabling that
(sysctl net.inet.tcp.rfc1323=0 on either peer), and see if it affects
things? Just to make sure that's not a part of the problem.
On Tue, Aug 21, 2007 at 04:16:51PM +0200, Jacek Zapala wrote:
> I have disabled this on sending side (FreeBSD) and it started to work!
Ah, so it's related to window scaling. Headaches again ;)
Is the following a correct view of your setup:
src $int_if pf $ext_if router dst
Whe
Could you possibly try the patch below, and see if it fixes the problem
(with rfc1323 enabled again)?
We're accessing th_flags from the TCP header embedded in the ICMPv6
packet, even though we only pulled up the first 8 bytes of the mbuf,
because the sender doesn't have to provide more of the head
On Tue, Aug 21, 2007 at 06:17:48PM +0200, Jacek Zapala wrote:
> I have applied the patch and it looks like it has helped.
Great, thank you!
> But I'm not sure if I understood well - you suspect that only 8 bytes of
> tcp header are copied from the original tcp packet to the icmp message
> by the
On Tue, Aug 28, 2007 at 11:29:31AM +0200, Gergely CZUCZY wrote:
> On a dual-carp scenario on two gateways when both the internal and
> the external IFs are carp(4)'d in a master-slave way and a link
> disconnects only on one side, would this trigger a carp failover
> of the other interface also?
On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote:
> rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 10101
> netsed tcp 10101 0 0 s/FOO/BAR
> The traffic from XP gets redirected just fine to netsed, which replaces the
> bytes just fine. BUT the changed packets
On Fri, Nov 09, 2007 at 12:59:46AM +0100, Max Laier wrote:
> Daniel, do you spot anything strange with these skip steps (or otherwise)?
The problem is the lack of IP reassembly in this configuration.
In pf_test_fragment(), a rule with r->flagset ("flags S/SA") is skipped.
Generally, stateful fi
Pawel, could you provide a tcpdump -nvvvSXpi for an entire
connection, from handshake to the point where it stalls? Please include
the corresponding 'BAD state'/'State failure' messages and output of
pfctl -vvss related to the connection (ideally all for the same
connection, so timestamps are comp
Pawel kindly supplied a tcpdump of an entire connection. We identified
the point where pf drops the packet because it sees a violation of the
advertised sequence window.
I think we can show that there is some problem with the TCP code,
possibly related to SACK. Hence, I'd like to ask anyone famila
On Fri, Nov 26, 2004 at 10:33:54PM +0200, Andrew Degtiariov wrote:
> I have ipcad installed on 2 PC's running 5.3-RELEASE and 5-STABLE from
> Nov 21. ipcad (ports/net-mgmt/ipcad) provides ability to control them
> by rsh (ipcad implement rsh server by yourself). While using pf with
> primitive rul
On Mon, Dec 13, 2004 at 05:43:26PM +0100, Max Laier wrote:
> > I'm glad to see any constructive comments on plan.
>
> Sorry, I don't see the point. If you are going to penalize the common case
> for
> this I will object.
On the other hand, if there was a simple (and cheap) way to disable
packe
On Sun, Mar 06, 2005 at 04:45:30PM -0500, Charles Sprickman wrote:
> For fun I'm going to post a full tcpdump of an ftp session from one box to
> the other, maybe someone can spot something there? It's attached and
> bzip'd. It's a tcpdump of both hosts transferring a 1MB tarfile.
I can only
On Mon, Mar 07, 2005 at 02:04:01PM -0500, Charles Sprickman wrote:
> Very interesting, thank you for that read of the tcpdump output. If you
> have the time, could you post back a few lines of the tcpdump with
> comments so that I might learn a little about what's going on? I don't
> have the
On Tue, Mar 08, 2005 at 02:04:20AM -0500, Charles Sprickman wrote:
> http://home.manymonkeys.com/tcpdump/
> Observing this showed that the os-x to fbsd transfer went at about 200KB/s
> and the os-x to obsd transfer went at about 2.6MB/s.
In the osx-fbsd case we see the same problem again. This
According to RFC 793 (the original TCP specification), the client may
(even should) wait at least one second before retransmitting any
segment.
However, RFC 2001 describes Fast Retransmission, where the third
acknowledgment for the same segment should be interpreted as an
indication of packet loss
On Tue, Mar 08, 2005 at 08:11:00AM -0600, Mark Tinguely wrote:
> The server is not telling the client that a packet has been lost.
> The first two ACKs are correct duplicate ACKs, but the remaining
> ACKs coming from he server have window adjustments, so the
> client does not treat them as duplica
On Mon, Jun 13, 2005 at 09:23:50PM +, Marcel Moolenaar wrote:
> Synopsis: Unaligned Reference with pf on 5.4/IA64
>
> Responsible-Changed-From-To: freebsd-net->freebsd-pf
> Responsible-Changed-By: marcel
> Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005
> Responsible-Changed-Why:
> Mo
On Wed, Jun 15, 2005 at 02:23:24PM -0700, Marcel Moolenaar wrote:
> That entirely depends. If a struct ip pointer is constructed without
> any form of casting, then one can assume that alignment is guaranteed.
> The compiler guarantees to do so, except of course in this case:
> the structure is de
On Sun, Nov 27, 2005 at 02:21:02PM -0800, Julian Elischer wrote:
> yes, which means it might unexpectedly fail.
I don't see how it can be done with TCP, assuming both peers are behind
NATing firewalls (like pf).
Some tricks to consider are:
Let one peer send a SYN through the firewall towards t
On Mon, Jan 02, 2006 at 06:51:32PM +0100, Attila Nagy wrote:
> Any ideas?
RFC1323 support includes TCP window scaling (wscale), which affects pf
stateful filtering. There have been bugs with that in the past, but the
code in 6.x should contain all fixes for them. Maybe you found a new
one.
When
On Tue, Jan 03, 2006 at 09:45:51AM +0100, Daniel Hartmeier wrote:
> To rule this out, make sure you either don't create state at all, or
> create state on the first SYN when you do (look for any "pass" rules
> which don't also include "keep state"). pfctl
[ I'm CC'ing Crist, maybe he can explain why -e behaves like it does ]
On Fri, Aug 18, 2006 at 11:57:56PM +0300, Rostislav Krasny wrote:
> I've tried the new "-e" traceroute option on today's RELENG_6 and
> found following problem:
>
> > traceroute -nq 1 -e -P TCP -p 80 216.136.204.117
As I und
40 matches
Mail list logo
