905B and truncated packets when udp checksum=NONE (dhcp remedy?)

Patrik Vahtras smetruck@smetrux.myip.org
Sun Jan 30 21:09:33 2000

Other udps works fine.
My card:  11/26/1998, division 6, product QR
My cable modem barfs these packets:

19:11:10.875480 truncated-ip - 4 bytes missing! > udp 1438 [ttl 1]
kernel: Receiving packet size 1476 status a80085c4

   and now the same thing using 3com's driver

23:53:33.904083 > udp 1438 [ttl 1]
23:53:33 smetrux kernel: Framelength 1480  Status a80085c8

Their driver always puts a full sized frame in skb regardless of the ip
size. That would be a workaround but it doesn't explain the status: 5c4
vs. 5c8

after days of agony I found it was the media status 88c0 vs. 88c4
so I changed (0.99L) around line 392:

-Media_10TP = 0x00C0,  /* Enable link beat and jabber for 10baseT. */
+Media_10TP = 0x00C4,  /* Enable link beat and jabber for 10baseT. */
and now:
23:43:50.975920 > udp 1438 [ttl 1]
23:43:51.685984 > udp 1438 [ttl 1]

What does the "4" mean?
>From 3com's source:
#define MIISELECT_10BT_ANE      0x0004

ANE - auto negotiate ?
What has this got to do with udp checksum?
I consider this a hardware bug.

I hope that this discovery will help me get rid of symptoms I have with:

1. dhcpcd 

It is stupid enough to pick up the packet and complain about its size
before checking if it is the correct port and then immediatly send
out another requset for renewal.

dhcpcd[236]: corrupted IP packet of size=1462 and ip_len=1466 discarded 
last message repeated 11 times

It works most of the time but after a few days it gets stuck. I don't know
if this will help though.

2. pump
Never browsed its source but it works even worse.

I am about to try out ISC's dhclient that uses kernel socket filtering
which should be the way to go.

I am on the list but if you want to mail me and I am down use

To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-bug-request@beowulf.org