-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Bob Brusa
Sent: Tuesday, September 22, 2009 12:45 PM
To: wireshark-users@xxxxxxxxxxxxx
Subject: [Wireshark-users] [wirshark-users]missing packet in promiscuous
capture mode
Hi
I am debugging the DHCP implementation of an embedded board. It should
receive its address from a ZyXEL P-661HW-D3 ADSL router. Using wireshark,
I can see that my board starts the DHCP-process, but I can not see any
answer of the ZyXEL to my boards requests. The funny thing however is,
that the debugging output of my board reports receipt of such an answer -
only to drop it because it claims a checksum error. This explains why the
DHCP process is not successful, but it does not explain why I do not see
this packet on wireshark. I have used filters of various kind - including
inspection by eye, packet for packet. This packet the board reports is
not
in the list of captured packet of wireshark.
The topology of my LAN is as follows:
Zyxel___Planet switch___Planet switch ____ myboard
FSD 1600 FSD 800 |____PC #1 running wireshark
|____JTAG debugger
|____PC #2
Does the switch play a dirty trick? Unlikely, because I see the packets
from my board and all those other packets going to/from the PC and JTAG
debugger. And the DHCP-process for the two PCs was successful. Thanks for
advice.
Robert
Am 22.09.2009, 18:54 Uhr, schrieb <Tim.Poth@xxxxxxxxxxx>:
If I'm not mistaken the reply from the DHCP server will go back to the
requesters mac address and not a broadcast address, a switch will only
forward traffic to all ports if it is a broadcast, if box A talks to box
B directly, box C will never see a thing which is that I think you are
seeing.
I think you need to find yourself a nice dumb hub or to port spanning /
mirroring on the switch.
Hope that helps
tim
Hi Tim
Thanks for the input. It is as you say. I installed an old hub instead of
the switch and now I can see the DHCPoffer. This makes it clear: The
checksum is the problem - most probably inside the tcpip-stack I am using:
lwip with ecos.
Robert