Wireless Group Policy WLAN Radius Part 3 WLAN Radius Config WLAN Client Config Linksys BEFSR41 Firmware Linksys BEFSR41 101 Linksys WAP54G config More Linksys BEFSR config Security how-to Writing DNS Zonefiles Is ZoneAlarm Spyware? Linksys Wishlist Sendmail spamblock Bind


Privacy Feedback

Bug in firmware 1.37.

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:
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:
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:
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.

1. Introduction

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