Ok, I understood, but create a dummy device to sniff it in a operation server I think it is not the best solution.
But, I have never thought about -j LOG, kkkkkkkkkkk if I do a filter by the mark, and -j LOG, I think it's sufficient. thanks!! Lucas. 2008/9/29 Mariusz Kruk <[EMAIL PROTECTED]> > On pon, 2008-09-29 at 05:34 -0700, Djingo Cacadril wrote: > > Lucas Mocellin <[EMAIL PROTECTED]> wrote on Thursday, September > > 25, 2008 7:57:16 PM > > > > > I marked some packets with iptables (-j MARK), and I want to "see" > > this set. > > > > > > I tried to search google, but nothing related. tcpdump doesn't seems > > help with that. > > > > The MARK target _associates_ a mark with the packet in the kernel data > > structures. That is, the packet itself is not modified. The sniffers > > tcpdump and ethereal only see the packages as they come in / go out > > through the wire. Even if you MARK a packet that is subsequently sent > > out on the wire, only the packet itself, not associated kernel > > datastructures are available to the sniffers. > > > > Guessing wildly, there may be a way of creating an extraordinary > > loopback device and have the router forward marked packets through > > that device, and have the sniffers sniff that device. Lots of research > > required, I guess. > > There is a possibility to do a 'routing thru a loop'. > http://lists.netfilter.org/pipermail/netfilter/2005-April/059970.html > It's extremely ugly solution (even though it's mine ;->), but I think > you'd need it if you want to inspect the actual connection. Just routing > the packets away thru a dummy device wouldn't solve the problem since no > connections could be made. > OTOH, if you don't need to browse the payload, you could just stick with > -j LOG. > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > >
