When pinging a uip device via SLIP, I get a packet in the uart that looks something like:
uip_buf[0] 0x45
uip_buf[1] 0x0
uip_buf[2] 0x0
uip_buf[3] 0x3c
uip_buf[4] 0x1
uip_buf[5] 0x20
uip_buf[6] 0x0
uip_buf[7] 0x0
uip_buf[8] 0x80
uip_buf[9] 1
uip_buf[10] 0xb5
uip_buf[11] 0x51
uip_buf[12] 0xc0
uip_buf[13] 0xa8
uip_buf[14] 0x1
uip_buf[15] 0x1
uip_buf[16] 0xc0
uip_buf[17] 0xa8
From the code, this ethernet header is supposed to be composed of a dest addr, src addr, and a type. However, in order for the packet to be processed, the type must be 0x0008, but apparently it's 0xa8c0 (uip_buf [13:12] or uip_buf [17:16]. Thus the comparison always fails:
if(BUF->type == HTONS(UIP_ETHTYPE_IP)) // 0xa8c0 != 0x0008
The line that does the comparison came from an ethernet implementation... Is it possible the type field is different when transmitted via SLIP?
Yes, there are differences. SLIP does not have the ethernet header, since serial lines don't have a bus architecture: instead, there are exactly two end points, so each end already knows who it's talking to.
IP packets still need to be distinguished, so there are some magic byte values and substitutions that allow this to be done. Details at the wikipedia page: