Bill Richardson wrote:
From BigIP
tcpdump -r test.pcap -nn host 172.21.89.75 -d
...
As I suspected, they appear to interpret "host XXX" as "host XXX or
(vlan and host XXX)".
That has the advantage that it works with both untagged and VLAN-tagged
packets.
It has the disadvantag
From BigIP
tcpdump -r test.pcap -nn host 172.21.89.75 -d
(000) ldh [12]
(001) jeq #0x8100 jt 2jf 14
(002) ldh [16]
(003) jeq #0x800 jt 4jf 8
(004) ld [30]
(005) jeq #0xac15594b jt 25 jf 6
(006) ld [34]
(007) jeq #0xac155
Bill Richardson wrote:
With that I mind I wonder what F5 did to
libpcap to get tcpdump to work? They must have made some changes?
What happens if you do
tcpdump -r test.pcap -nn host 172.21.89.75 -d
on the BigIP?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to
I created the test.pcap file on one of my Centos 4.5 systems and took
that same file and got the same results on 5 different systems. The only
one that would show me both sides of the conversation was the F5 BigIP.
Once I found out it was VLAN tagging related I was able to see the other
side of
> ...and 4 bytes long, as per the earlier discussion, or just 1 byte (or
2 bytes)?
We may as well make it just 1 byte since it only can specify 2 alternative
values!
> So what's the format of the packet data in your proprietary
encapsulation type?
This is still to be confirmed - I was only t
