problem using ng_patch

h bagade bagadeh at gmail.com
Sat Aug 11 08:37:30 UTC 2012


On Sat, Aug 11, 2012 at 12:57 PM, Nikolay Denev <ndenev at gmail.com> wrote:

> On Aug 11, 2012, at 11:07 AM, h bagade <bagadeh at gmail.com> wrote:
>
> > Hi all,
> >
> > I want to use the node ng_patch, to set the ToS field of special class of
> > packets. I try to test the function by a simple test scenario and
> > encountered problem using it. I have no idea why the problem occurs.
> >
> > Here I explain the test scenario I've used.
> >
> > I have a topology like this:
> >
> >
> |A:192.168.8.8|<---->|192.168.8.26--(B)--192.168.7.26|<---->|C:192.168.7.20|
> > --------------------------------
> > A, C: two end stations
> > B: a router
> > --------------------------------
> > netgraph settings:
> > kldload ng_ipfw
> > ngctl mkpeer ipfw: patch 300 in
> > ngctl name ipfw:300 tos
> > ngctl msg tos: setconfig {count=1 csum_flags=1 ops=[ {mode=1 value=0x05
> > length=1 offset=1}]}
> > --------------------------------
> > ipfw rule:
> > ipfw add 20 netgraph 300 icmp from any to 192.168.7.20
> >
> > This configuration works well and when A pings C or C pings A, the
> packets
> > destined to 192.168.7.20(station C) gets the ToS: 0x05.
> > The problem occurs when I change the ipfw rule to the following;
> >
> > ipfw add 20 netgraph 300 icmp from 192.168.7.20 to any
> >
> > By this rule, neither A can ping C nor C can ping A! the packets sent to
> > ng_patch node never comes back to the next ipfw rule!
> >
> > I don't know what's the difference between these two scenarios (only the
> > checking from destination address is changed to source address), but it's
> > what I saw in my tests. I really hope to understand what's happening.
> >
> > Any hints or comments would help
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
> Hi,
>
> Do you have "sysctl net.inet.ip.fw.one_pass=0" set?
>
> Regards,
>
>
yes, As I described I've two scenarios, one work but the other doesn't, and
the only difference is on ipfw rule!


More information about the freebsd-net mailing list