> just add the following line -
> skb->pkt_type = PACKET_HOST;
That's being done by default in the sk_buff constructors,
and nobody's changing that default. Plus, if that were
the problem (vs say memory corruption, for which there
is no evidence at all) then TCP would never work at
all (not the symptom :-).
I just got a report of a symptom, likely related, where
tcpdump shows the ACK is getting sent and then dropped.
(Below, it's not even getting sent.) And in fact, I just saw
this version a few moments ago myself.
I've seen this problem with this driver off and on since
about test8; it might have been there in test6/test7 when
the driver was first developed (it's still "experimental")
without being noticed ("intermittent"), but in any case
this is rather perplexing. What do folk do when trying
to get TCP to tell them what's up? Enabling TCP_DEBUG
or NETDEBUG is no help at all.
> > PROBLEM: TCP connections won't establish -- sometimes.
> > The same driver executable may work one day, fail the next.
> > If I watch things with "tcpdump" what I'll see is TCP setup packets
> > (say for FTP, SSH, rpcinfo) arriving ... but no acks getting sent
> > back. Meanwhile, "ping" traffic flies (both directions) without any
> > problems at all. A while back I computed checksums of packets
> > on both sides (tx/rx) and they were the same ...