[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another Ethernet problem for Thomas :)
- Date: Wed, 30 Jan 2008 14:56:05 +0200
- From: leonp at plris.com (Leon Pollak)
- Subject: Another Ethernet problem for Thomas :)
On Wednesday, 30 ?January 2008, Thomas Doerfler wrote:
> Leon Pollak schrieb:
> Here is the simple solution:
> Today we have detected some spurious UDP packets arriving on our
> firewall. They all had a counter value of ZERO and came from the domain
> "plris.com". So now I know how they were sent. Leon, if you like, I can
> send them back as attachment in a separate email :-)
Yes, yes!!! Please!!!
> So now you got me, I have no idea what can actually be the reason for
> this (Oh, just a hint, it is a software problem).
> What I would do:
> - check, that the statistics counters of the driver are coded properly,
> so they really count all packets sent, all tx errors etc.
> - compare the number of packets sent with the number of packets tcpdump
> can count (using the rtems_bsdnet_show_if_stats() function)
> additionally you might want to use the following functions to get more
> statistics output:
> ~ rtems_bsdnet_show_icmp_stats();
> ~ rtems_bsdnet_show_ip_stats();
> ~ rtems_bsdnet_show_inet_routes();
> ~ rtems_bsdnet_show_tcp_stats();
> ~ rtems_bsdnet_show_udp_stats();
> - check, that no mbufs are lost over time:
> ~ rtems_bsdnet_show_mbuf_stats();
I am rather weak in this area. IMHO, there were no such errors and counters
Now, I have noticed the strange (IMHO) event, may be it has something in
common with my problem...
tcpdump shows that after unit start there is the following packet:
arp who-has 192.168.50.133 tell 192.168.50.133
where 192.168.50.133 is the address of the unit.
Is this normal?
Tracking down, I saw that the arp request appears in rtems_bsdnet_setup which
calls rtems_bsdnet_ifconfig(ifp->name, SIOCSIFADDR, &address).
> - Just a guess (no, not again!): Does the packet loss only occur, when
> you have waited some minutes after the last transmission? maybe some
> switch/arp cache/xxx has lost routing information then and needs one
> packet to get things working again?
Can it be so!?
Well, after some thoughts I how can it be, because tcpdump shows:
arp who-has 192.168.50.57 tell 192.168.50.133
(my unit to my pc)
as the first packet. Thus it should be lost, not my UDP packet, no?