It appears that there is a bug in version 1.37 of the Linksys BEFSR11/41 firmware. There has been a number of reports on constantly flashing ACT lights on the router, even when no traffic should be on the network. Normal NetBIOS or NetBEUI traffic would not cause this constant flashing.
Using a packet sniffer, I was able to capture a large amount of this traffic. Below are the header information of three different packets showing the kinds of traffic that was passed through the router.
PASS:MAC: 00:20:78:C5:35:C6 => 01:00:5E:00:00:02 Sequence #1, Time:22:38:00.650, Protocol:IP, Size:60 IP :Source IP: 24.147.163.X, Destination IP: 18.104.22.168 Header Length: 20, Service Type: 0x00, Datagram Length: 28 Flags & Fragment.: 0x0000, Identification: 0x0100, TTL:128 Header Checksum: 0x9DB4, Protocol: ICMP ICMP:Type: 10[unknown], Code: 0 PASS:MAC: 00:20:78:C5:35:C6 => 01:00:5E:00:00:11 Sequence #5, Time:22:38:08.340, Protocol:IP, Size:78 IP :Source IP: 24.147.160.X, Destination IP: 22.214.171.124 Header Length: 20, Service Type: 0xC0, Datagram Length: 64 Flags & Fragment.: 0x0000, Identification: 0x0000, TTL:1 Header Checksum: 0x2004, Protocol: 46[unknown] PASS:MAC: 00:20:78:C5:35:C6 => 01:00:5E:00:00:02 Sequence #9, Time:22:38:28.220, Protocol:IP, Size:60 IP :Source IP: 24.147.167.X, Destination IP: 126.96.36.199 Header Length: 20, Service Type: 0x00, Datagram Length: 32 Flags & Fragment.: 0x0000, Identification: 0xEDB5, TTL:1 Header Checksum: 0x96AA, Protocol: IGMP
(I removed the last octet in the source IP, as there is no point in broadcasting that information here)
There only one thing in common in these three packets. The destination address is a multi-cast address.
The first packet is an ICMP packet, and it is a router solicitation message (Tamosoft: you really should know this...). The source is a neighbor of mine, the destination is a multicast address.
The second is an RSVP (Resource ReSerVation Protocol, see rfc2205) packet. One application that uses RSVP is MS NetMeeting.
This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93, RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path.
3.3 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as "raw" IP datagrams with protocol number 46. Raw IP datagrams are also intended to be used between an end system and the first/last hop router, although it is also possible to encapsulate RSVP messages as UDP datagrams for end-system communication, as described in Appendix C. UDP encapsulation is needed for systems that cannot do raw network I/O.
The third packet is a IGMP packet, again with a destination of a multicast address.
This is the only type of traffic that I found getting passed by the Linksys router. The computer in question was not the DMZ computer; in fact, these packets are broadcasts, so they are transmitted to all the computers on the LAN. Using a "dummy" IP address in the DMZ did not resolve this issue. The only resolution I have found is to revert back to version 1.36 of the firmware.
Linksys have been notified of this issue. Hopefully, it will be taken care of because I really liked the new features in the 1.37 version. However, I did not like this "feature"...
© 1999-2005 Lars M. Hansen