Ping works, TCP/IP transfers fail

Hello,
We are developing an embedded Linux board with ethernet. I am running
a 2.4.9 era kernel on the board. We just got our first batch of 10
boards back from manufacturing. 3 of the 10 boards have a weird
ethernet problem (they all have the exact same software loaded on to
them). I am having a weird problem where TCP/IP over the ethernet
connection (eth0) does not seem to work: I can't ssh into the board, I
can't mount the board, I can't scp to the board. When I log into the
board from the serial console, I can't ssh to any external boards, etc.


However, ping works just fine...no dropped packets. Additionally, when
I plug in an 802.11 card into the Compact Flash socket on our board, we
have full TCP/IP capability: we can ssh over 802.11, we can mount,
etc. This seems to vindicate any weirdness with software relating to
the TCP/IP stack itself.

The potential culprit here is the hardware surrounding the ethernet
hardware, but if this were true, I don't know how ICMP requests would
be working in both directions.

Anyone ever see anything like this before? The board is actually
running an Intel SA-1110 StrongARM processor, if it makes a difference.

TIA,

John O.

On 2005-05-18, jro <(E-Mail Removed)> wrote:
> can't mount the board, I can't scp to the board. When I log into the
> board from the serial console, I can't ssh to any external boards, etc.
> However, ping works just fine...no dropped packets. Additionally, when

It sounds like a problem with the MTU of the connection. Small packets
(ping) can pass but bigger packets are fragmented and goes banana.

Check the MTU of the NIC, eventually, try to resize it to a smaller
value (and the same on the other end of the connection).

Davide

--
Caller: I just installed Windows 95 on my computer.
Tech Support: And...?
Caller: It's not working.
Tech Support: You already said that.

Hi,

perhaps You should try to send a "bigger" ping-packet to verify...



"jro" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) oups.com...
> Hello,
> We are developing an embedded Linux board with ethernet. I am running
> a 2.4.9 era kernel on the board. We just got our first batch of 10
> boards back from manufacturing. 3 of the 10 boards have a weird
> ethernet problem (they all have the exact same software loaded on to
> them). I am having a weird problem where TCP/IP over the ethernet
> connection (eth0) does not seem to work: I can't ssh into the board, I
> can't mount the board, I can't scp to the board. When I log into the
> board from the serial console, I can't ssh to any external boards, etc.
>
>
> However, ping works just fine...no dropped packets. Additionally, when
> I plug in an 802.11 card into the Compact Flash socket on our board, we
> have full TCP/IP capability: we can ssh over 802.11, we can mount,
> etc. This seems to vindicate any weirdness with software relating to
> the TCP/IP stack itself.
>
> The potential culprit here is the hardware surrounding the ethernet
> hardware, but if this were true, I don't know how ICMP requests would
> be working in both directions.
>
> Anyone ever see anything like this before? The board is actually
> running an Intel SA-1110 StrongARM processor, if it makes a difference.
>
> TIA,
>
> John O.
>

Hello all,
Thanks for the responses thus far...I tried reducing the MTU on my
target Linux board, but it didn't make any difference. Interesting
thought though...I may play around with this some more. However,
assuming the MTU did have something to do with it, I don't think it
makes sense that the 802.11 connection is able to get through just
fine. I'm assuming the packet assembly/fragmentation code is common
regardless of physical layer (i.e., eth0 or wlan0 in my case). Do I
have this right, or am I missing something here?

John

Well...after lots more investigation, porting of tcpdump to our target
platform (packets matched byte for byte with what was being sent), and
finally sprinkling printk()s all throughout the TCP/IP code in the
kernel, we figured out what was happening. It turns out that the
packets were getting handed from IP to TCP just fine, but then TCP was
silently throwing them away because they were getting handed up to IP
from a multicast session. The connection established on wlan0
(802.11b) was not multicast, and thus worked fine.

The reason that the session was set to multicast is because we had
arbitrarily set our MAC addresses on the boards for testing. It turns
out that the least significant bit of the highest-order MAC address
byte has special meaning. If it is set to 1, then all traffic coming
in on this interface will be considered as multicast traffic. The
boards that had failed all had their MAC addresses set with this bit
set to 1. Changing it back to 0 fixes the issue.

So it wasn't really software or hardware...just inexperience. I still
don't totally understand why TCP decides to silently throw away packets
if the connection is a multicast one...but it sure does. As a side
note, we picked up a copy of "The Linux TCP/IP Stack" at our local
Borders, and this helped immensely in understanding what the heck the
TCP/IP code is doing.

Fun fun fun...

John

jro wrote:
> Hello all,
> Thanks for the responses thus far...I tried reducing the MTU on my
> target Linux board, but it didn't make any difference. Interesting
> thought though...I may play around with this some more. However,
> assuming the MTU did have something to do with it, I don't think it
> makes sense that the 802.11 connection is able to get through just
> fine. I'm assuming the packet assembly/fragmentation code is common
> regardless of physical layer (i.e., eth0 or wlan0 in my case). Do I
> have this right, or am I missing something here?
>
> John

> I still
> don't totally understand why TCP decides to silently throw away packets
> if the connection is a multicast one...but it sure does.

TCP is a point-to-point protocol. Even when data are only transfered in
one direction, acknowledgements are required in the other direction.
It's not immediately clear how one would extend this to multicast.