On Mon, Jun 6, 2011 at 6:02 PM, Martin T wrote:
> I made a RJ45 hardware loopback connector(connected Tx- with Rx+ and
> Tx+ with Rx-), connected this to my eth2 port, configured
> 192.168.88.0/24 to eth2 and executed:
>
> "ping -i0.1 -c3 192.168.88.88"
>
> ..while running tcpdump like this:
>
.
On Jun 6, 2011, at 3:02 PM, Martin T wrote:
> As you can see, every second I sent and received one frame. The
> question is, why is the frame, which I receive, 18 bytes longer than
> the one I sent? I mean what are those 144 0-bits at the end of the
> each frame back from the hardware loop?
Padd
I made a RJ45 hardware loopback connector(connected Tx- with Rx+ and
Tx+ with Rx-), connected this to my eth2 port, configured
192.168.88.0/24 to eth2 and executed:
"ping -i0.1 -c3 192.168.88.88"
..while running tcpdump like this:
root@martin-desktop:~# tcpdump -n -i eth2 -e -v -XX
tcpdump: list
thanks anyway, Aaron :)
On Mon, Jun 6, 2011 at 7:39 PM, Aaron Turner wrote:
> On Mon, Jun 6, 2011 at 1:55 AM, Adam Katz wrote:
> > my ip and tcp checksums should be correct, but i'll check it out.
> > Could you point me in the direction of an ACTIVE mailing list with
> traffic
> > shaping guys?
On Jun 6, 2011, at 11:23 AM, Raman Muthukrishnan wrote:
> We are using natty (linux 2.6.38) release, and we are facing the issue
> with pcap/bpf.h. You have addressed the issue in Jan 2011.
> But I am unable to find a release package with that fix. Do you know if
> one is available?
None are av
Hi Guy Harris,
We are using natty (linux 2.6.38) release, and we are facing the issue
with pcap/bpf.h. You have addressed the issue in Jan 2011.
But I am unable to find a release package with that fix. Do you know if
one is available?
Thanks,
Raman
Re: Linux system headers 2.6.36 and pcap/bp
On Jun 6, 2011, at 10:39 AM, Flavio Truzzi wrote:
> Anyone?
As Darren Reed asked:
stack trace?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Anyone?
On Sun, Jun 5, 2011 at 12:26 AM, Flavio Truzzi wrote:
> class Sniffer
> {
> public:
> Sniffer();
> void processPacket(const u_char* instance, const pcap_pkthdr *pkthdr);
>
>
> private:
> char* dev;
> char errbuff[PCAP_ERRBUF_SIZE];
> pcap_t *handle;
> struct pcap_p
On Mon, Jun 6, 2011 at 1:55 AM, Adam Katz wrote:
> my ip and tcp checksums should be correct, but i'll check it out.
> Could you point me in the direction of an ACTIVE mailing list with traffic
> shaping guys? The ones I found were pretty much abandoned.
Not really... like I said before, I didn't
2011/6/6 mold2010 :
> The root cause of this problem is found. It is because the MTU of the
> receiving NIC is set to 9000, which is greater than 1500. Since some packets
> have ethernet FCS and trailer, that makes the packet has a 1520 whole size.
> The tcpreplay can not recognize the FCS and t
The root cause of this problem is found. It is because the MTU of the receiving
NIC is set to 9000, which is greater than 1500. Since some packets have
ethernet FCS and trailer, that makes the packet has a 1520 whole size. The
tcpreplay can not recognize the FCS and trailer in the IP packet end,
my ip and tcp checksums should be correct, but i'll check it out.
Could you point me in the direction of an ACTIVE mailing list with traffic
shaping guys? The ones I found were pretty much abandoned.
thanks!
On Sun, Jun 5, 2011 at 7:59 PM, Aaron Turner wrote:
> On Sun, Jun 5, 2011 at 12:29 AM,
12 matches
Mail list logo
