netdev - Re: data received but not detected

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Jun 2008 21:54:40 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Travis Stratman <tstratman@...cinc.com>
Cc:	netdev@...r.kernel.org
Subject: Re: data received but not detected

On Fri, Jun 20, 2008 at 12:41:04PM -0500, Travis Stratman (tstratman@...cinc.com) wrote:
> > Please also clarify this bit again: you see packets in tcpdump running
> > on receiving (frozen) host, but do not see them in userspace? After this
> > freeze happend system recvmsg/poll calls do not respond until some
> > activity on NIC happend? I.e. recv/poll 'unfreeze' only when something
> > is received (arp, icmp reply) or after sending too?
> 
> I see the packets being sent in tcpdump from the sending application,
> but they don't show up in the receiving side until something else comes
> in behind them. For example if you look at the client and server trace
> that I sent yesterday side by side you will see how the timings line up.
> The same packets are shown in each trace. Data needs to be received by
> the board to unlock it, sending does not seem to have any effect.

So, packets are actually received by the host, since you see them in the
receiving host tcpdump, but they do not reach socket queue. Please check
UDP_MIB_INERRORS mib. You can do that via netstat -s.

-- 
	Evgeniy Polyakov
--
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