| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1309788416.26180.63.camel@mojatatu> Date: Mon, 04 Jul 2011 10:06:56 -0400 From: jamal <hadi@...erus.ca> To: Adam Katz <adamkatz0@...il.com> Cc: netdev@...r.kernel.org Subject: Re: libpcap and tc filters On Mon, 2011-07-04 at 16:24 +0300, Adam Katz wrote: > ok, I checked now and the packets sent by tcpreplay are identical to > the ones captured originally by wireshark. Ok - thanks for removing that variable. > I'm using the stock ubuntu 10.04 kernel that wasn't compiled with > CONFIG_CLS_U32_PERF so sudo tc -s filter ls dev eth1 shows nothing > useful (and i'm not sure that recompiling the entire kernel is worth > it to tell me what I already know - that these packets missed the > filters... but i'm willing to do it if you think that'll help). Not necessary as long as you can tell where the packets end up. > Anyway, I suspect the problem to be something else - I suspect that > the packets sent using tcpreplay simply skip the filters in the kernel > and are being injected somewhere afterwards. But this theory is > problematic since I find it strange that the packets do end up in the > default queue after all - hence they ARE seen by tc and they don't > skip tc entirely. I am not sure off top of my head why that would happen. I will try later to install tcpreplay and reproduce your test. cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists