How to detect CDP by tcpdump - protocols

I would like to ask you for help: Does somebody know how to detect Cisco Discovery Protocol via tcpdump?
Currently I'm using following command, but I'm not sure by this:
tcpdump -i eth0 -nn "ether[20:2]==0x2000"
Some hints are appreciated. Thank you ...
Charkh

I normally use this filters
tcpdump -nvi bce0 -s 1500 ether dst 01:00:0c:cc:cc:cc
replace bce0 with your network interface.
This will output the hole CDP information, received from ether the switch or the host itself (if you have a cdpd running on the host)
This will output Switch-Name, Port, Switch Type, Software, VLAN and so on...
the output will look similar to this:
$tcpdump -nvi bce0 -s 1500 ether dst 01:00:0c:cc:cc:cc
tcpdump: WARNING: bce0: no IPv4 address assigned
tcpdump: listening on bce0, link-type EN10MB (Ethernet), capture size 1500 bytes
11:43:24.327197 DTPv1, length 39
Domain TLV (0x0001) TLV, length 18, domain-internal
Status TLV (0x0002) TLV, length 5, 0x81
DTP type TLV (0x0003) TLV, length 5, 0xa5
Neighbor TLV (0x0004) TLV, length 10, 6c:50:4d:06:64:01
11:43:44.820865 CDPv2, ttl: 180s, checksum: 692 (unverified), length 477
Device-ID (0x01), length: 40 bytes: 'my-switch.mydomain.net'
Version String (0x05), length: 247 bytes:
Cisco IOS Software, CBS30X0 Software (CBS30X0-IPBASEK9-M), Version 12.2(58)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2011 by Cisco Systems, Inc.
Compiled Thu 05-May-11 03:57 by prod_rel_team
Platform (0x06), length: 20 bytes: 'cisco WS-CBS3020-HPQ'
Address (0x02), length: 13 bytes: IPv4 (1) 1.2.3.4
Port-ID (0x03), length: 18 bytes: 'GigabitEthernet0/1'
Capability (0x04), length: 4 bytes: (0x00000028): L2 Switch, IGMP snooping
Protocol-Hello option (0x08), length: 32 bytes:
VTP Management Domain (0x09), length: 13 bytes: 'doman-internal'
Native VLAN ID (0x0a), length: 2 bytes: 358
Duplex (0x0b), length: 1 byte: full
AVVID trust bitmap (0x12), length: 1 byte: 0x00
AVVID untrusted ports CoS (0x13), length: 1 byte: 0x00
Management Addresses (0x16), length: 13 bytes: IPv4 (1) [IP]
unknown field type (0x1a), length: 12 bytes:
0x0000: 0000 0001 0000 0000 ffff ffff

I use the following command:
tcpdump -nn -v -xx -i eth? -s 1500 -c 1 'ether dst 01:00:0c:cc:cc:cc and (ether[24:2] = 0x2000 or ether[20:2] = 0x2000)'
Where eth? is your ethernet adapter.
It can be used with IBM SEA over trunked connections or over standard copper connections.

Related

Can't flash with avrisp mkII in avrdude Version 6.0.1

I have had problems with this programming board. It is set up correctly seems to be an AVRISP MKII.
I received the following error messages upon flashing with avrdude:
(trusty)chandran#localhost:~$ avrdude -c avrispmkii -p t85 -vv
avrdude: Version 6.0.1, compiled on Oct 21 2013 at 15:55:32
Copyright (c) 2000-2005 Brian Dean, h ttp://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/chandran/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : avrispmkii
avrdude: usb_open(): cannot read serial number "error sending control
message: Connection timed out"
avrdude: usbdev_open(): Found AVRISP mkII, serno: [unknown]
avrdude: usbdev_recv_frame(): usb_bulk_read(): error submitting URB: No
such file or directory
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_recv_frame(): usb_bulk_read(): error submitting URB: No such file or directory
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_getsync(): timeout communicating with programmer
AVR Part : ATtiny85
Chip Erase delay : 4500 us
PAGEL : P00
BS2 : P00
RESET disposition : possible i/o
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 6 4 0 no 512 4 0 4000 4500 0xff 0xff
flash 65 6 32 0 yes 8192 64 128 4500 4500 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00
Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
avrdude: usbdev_recv_frame(): usb_bulk_read(): error submitting URB: No such file or directory
It is hard to identify the issue since my version of the programming board doesn't have such great documentation.
Thanks in advance!
This bug was causing the problems. I simply reverted to the previous version of avrdude (5.11.1) and it worked. By now there is an even newer version of avrdude (6.3), this bug might no longer be a problem in latest version.
Here are some steps:
Revert to an older version of avrdude either by using sudo apt-get install <package-name>=<package-version-number> OR sudo apt-get install <package-name>=<package-version-number>
Check if it works: avrdude -p <your part name> -c <your programmer name (avrispmkII)>
You might have to specify a port. Use something like ''watch ls /dev/tty*'' to find your device if you get an error like this one:
(trusty)chandran#localhost:~$ avrdude -c avrispmkII -p t85
avrdude: ser_open(): can't open device "/dev/ttyS0": No such file or directory
avrdude done. Thank you.
Here is what it will look like when you get it right:
(trusty)chandran#localhost:~$ avrdude -c avrispmkII -p t85 -P usb -vv
avrdude: Version 5.11.1, compiled on Oct 30 2011 at 10:37:28
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/chandran/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : avrispmkII
avrdude: usb_open(): cannot read serial number "No error"
avrdude: usbdev_open(): Found AVRISP mkII, serno: [unknown]
avrdude: usbdev_open(): using read endpoint 0x83
AVR Part : ATtiny85
Chip Erase delay : 4500 us
PAGEL : P00
BS2 : P00
RESET disposition : possible i/o
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 6 4 0 no 512 4 0 4000 4500 0xff 0xff
flash 65 6 32 0 yes 8192 64 128 4500 4500 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00
Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
Hardware Version: 0
Firmware Version Master : 1.255
Vtarget : 3.3 V
SCK period : 8.00 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e930b
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK
avrdude done. Thank you.
If this doesn't fix your problem, you might want to look at some other solutions:
https://electronics.stackexchange.com/questions/78302/avrisp-mkii-not-reading-device-signature/189488
https://electronics.stackexchange.com/questions/67757/why-does-my-avrisp-mkii-programmer-not-work
AVRISP MKII doesn't work with AVRDUDE on Linux
https://electronics.stackexchange.com/questions/74298/how-does-avrdude-with-avr-isp-mkii-respond-when-no-target-board-is-connected
Good luck!

Cannot talk to atmega328p over AVRisp mkII

I have similar issue as here(AVRISPmkII connection status: Unknown status 0x00) but different setup and changing bitcklock didn't help.
The current setup is atmega328p with external oscillator 16MHz connected to ISP interface of avrisp mkII programmer but whatever I do It keeps on showing the same output all the time:
mike#asus:~/wireless-temp-sens/tests$ sudo avrdude -p atmega328p -P usb -c avrispv2 -U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xfe:m -v
avrdude: Version 6.0.1, compiled on Oct 21 2013 at 17:07:18
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/mike/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : avrispv2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200209719
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : STK500V2
Description : Atmel AVR ISP V2
Programmer Model: AVRISP mkII
Hardware Version: 1
Firmware Version Master : 1.23
Vtarget : 4.9 V
SCK period : 2053.39 us
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Any help is appreciated!
Problem resolved! Don't remember what was the reason exactly. I guess clock crystal didn't have proper connections on a breadboard. So, I would say:
Check your wiring
Check your wiring
Check your wiring

how does the tcp packet “size” reported by tcpdump correlate to the actual IP packet sent?

When I run a tcpdump – what exactly does the number reported between the () after the lowest and highest sequence number mean?
If it correlates to the IP packet sent, how can it be larger than
the mtu of 1500?
On the receive side of this flow tcpdump always
sees packets of 1448 or smaller – where are these packets being
defragmented and reassembled? Can I see that with tcpdump?
Is there any relationship between this number and the size of the tcp socket
buffer?
I.e: Typical tcpdump on the sender:
11:47:18.278352 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3263771:3272459(8688) ack 1 win 54
11:47:18.278371 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3272459:3282595(10136) ack 1 win 54
11:47:18.278620 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3282595:3298523(15928) ack 1 win 54
11:47:18.278727 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3298523:3301419(2896) ack 1 win 54
11:47:18.278731 IP 1.1.1.36.41034 > 1.1.1.37.60960: P 3301419:3301719(300) ack 1 win 54
11:47:18.777160 IP 1.1.1.36.41034 > 1.1.1.37.60960: P 3301719:3301723(4) ack 1 win 54
11:47:18.777175 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3301723:3303171(1448) ack 1 win 54
And the receiver:
11:47:18.277895 IP 1.1.1.36.41034 > 1.1.1.37.60960: P 990413:990417(4) ack 1 win 54
11:47:18.277948 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 990417:991865(1448) ack 1 win 54
11:47:18.277953 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 991865:993313(1448) ack 1 win 54
11:47:18.277958 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 993313:994761(1448) ack 1 win 54
11:47:18.278028 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 994761:996209(1448) ack 1 win 54
That is the length of the data, as you can see if you substract the two sequence numbers (after accounting +1 for SYN and FIN flags, if they are present in the packet).
As to why it's greater than the MTU, either your netword card can send jumbo-frames (quite normal on 1Gbps cards), or your card can accept large segments and divide them on hardware (called LSO/GSO or some similar acronym I cannot seem to recall).
Edit: See Large Segment Offload on Wikipedia.

TCP messages getting coalesced

I have a Java application that is writing to the network. It is writing messages in the region of 764b, +/- 5b. A pcap shows that the stream is getting IP fragmented and we can't explain this.
Linux 2.6.18-238.1.1.el5
A strace shows:
(strace -vvvv -f -tt -o strace.out -e trace=network -p $PID)
1: 2045 12:48:23.984173 sendto(45, "\0\0\0\0\0\0\2\374\0\0\0\0\0\3\n\0\0\0\0\3upd\365myData"..., 764, 0, NULL, 0) = 764
2: 15206 12:48:23.984706 sendto(131, "\0\0\0\0\0\0\2\374\0\0\0\0\0\3\n\0\0\0\0\3upd\365myData"..., 764, 0, NULL, 0 <unfinished ...>
3: 2046 12:48:23.984811 sendto(46, "\0\0\0\0\0\0\2\374\0\0\0\0\0\3\n\0\0\0\0\3upd\365myData"..., 764, 0, NULL, 0 <unfinished ...>
4: 15206 12:48:23.984893 <... sendto resumed> ) = 764
5: 2046 12:48:23.984948 <... sendto resumed> ) = 764
I am seeing packets larger than the MTU when I capture the network, which is causing fragmentation.
4809 5.848987 10.0.0.2 -> 10.0.0.5 TCP 40656 > taiclock [ACK] Seq=325501 Ack=1 Win=46 Len=1448 TSV=344627654 TSER=270108068 # First Fragment
4810 5.848991 10.0.0.5 -> 10.0.0.2 TCP taiclock > 40656 [ACK] Seq=1 Ack=326949 Win=12287 Len=0 TSV=270108081 TSER=344627643 # TCP ack
4811 5.849037 10.0.0.2 -> 10.0.0.5 TCP 40656 > taiclock [PSH, ACK] Seq=326949 Ack=1 Win=46 Len=82 TSV=344627654 TSER=270108081 # Second Frag
Questions:
1) It appears the server trying to batch the two sendto() into one IP packet, which is larger than the MTU and is therefore getting fragmented. Why?
2) Looking at the strace output for PID 2046, is the figure after the equal sign <... sendto resumed> line a total for what was sent? I.e. 764b was sent in total for line 3 and line 5? Or is 764 bytes being sent per line?
3) Are there any options I can pass to strace to log all of the sendto() output? Can't seem to find anything..
To answer your questions, in order:
1) It is perfectly normal for multiple send calls to be coalesced when using TCP as it is a stream protocol so does not preserve user level send boundaries in any way. I don't see any evidence of IP fragmentation (which would be bad) in your trace, just of TCP segmentation (which is completely normal).
2) Yes, that is the size - more specifically it is reporting the value that the system call returned after it resumed.
3) You can use "-e write=all" or "-e write=" to get strace to report the whole of the written data.

wireshark and tcpdump -r: strange tcp window sizes

I'm capturing http traffic with tcpdump and am interested in TCP slow start and how window sizes increase:
$ sudo tcpdump -i eth1 -w wget++.tcpdump tcp and port 80
When I view the dump file with Wireshark the progression of window sizes looks normal, i.e. 5840, 5888, 5888, 8576, 11264, etc...
But when I view the dump file via
$ tcpdump -r wget++.tcpdump -tnN | less
I get what seem to be nonsensical windows sizes ( IP addresses omitted for brevity ):
: S 1069713761:1069713761(0) win 5840 <mss 1460,sackOK,timestamp 24220583 0,nop,wscale 7>
: S 1198053215:1198053215(0) ack 1069713762 win 5672 <mss 1430,sackOK,timestamp 2485833728 24220583,nop,wscale 6>
: . ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . 1:1419(1418) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: P 1419:2002(583) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . ack 1419 win 133 <nop,nop,timestamp 2485833824 24220604>
: . ack 2002 win 178 <nop,nop,timestamp 2485833830 24220604>
Is there a way to get normal / absolute window sizes on the command line?
The window sizes are correct - they're just unscaled.
The connection initiator has set a wscale (window scaling factor) of 7, so its subsequent win values must be multiplied by 128 to get the window size in bytes. Thus the win 46 indicates a window of 5888 bytes.
The connection recipient has set a wscale of 6, so its win values must be multiplied by 64. Thus win 133 indicates a window of 8512 bytes, and win 178 indicates 11392 bytes.
Also, if the tool (wireshark or tcpdump, it doesn't matter) doesn't see the syn, it has to print the unscaled value, which can fool you

Resources