WRT350N - Revision history

Michael: Added side note

2008-01-30T00:14:20Z

Added side note

Michael: I like smaller pictures

2007-08-29T16:32:00Z

I like smaller pictures

Jpicotte at 22:49, 12 July 2007

2007-07-12T22:49:12Z

Jpicotte at 22:48, 12 July 2007

2007-07-12T22:48:05Z

Jpicotte at 22:47, 12 July 2007

2007-07-12T22:47:33Z

Jpicotte at 19:09, 6 July 2007

2007-07-06T19:09:59Z

Jpicotte at 19:09, 6 July 2007

2007-07-06T19:09:07Z

Jpicotte at 19:08, 6 July 2007

2007-07-06T19:08:37Z

Jpicotte: New page: Image:Example.jpg "The Satellite"

2007-07-06T18:34:34Z

New page: Image:Example.jpg "The Satellite"

New page

[[Image:Example.jpg]]
"The Satellite"

← Older revision		Revision as of 00:14, 30 January 2008
Line 7:		Line 7:
	A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1. From there, a blank image was tftp'd (using put) to the router during booting. The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating. At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.		A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1. From there, a blank image was tftp'd (using put) to the router during booting. The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating. At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.
	Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped. Apparently, beating the device with empty images through tftp does the trick.		Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped. Apparently, beating the device with empty images through tftp does the trick.
		+
		+	It should also be noted that you must make sure the router has boot_wait=on for this to work.

← Older revision		Revision as of 16:32, 29 August 2007
Line 1:		Line 1:
−	[[Image:WRT350N.png\|thumb\|~~900px~~\|left\|The Satellite]]	+	[[Image:WRT350N.png\|thumb\|150px\|left\|The Satellite]]

	== Caveats out of the box ==		== Caveats out of the box ==

@@ Line 3: / Line 3: @@
 == Caveats out of the box ==
 This router claims to use CFE version 1.0.37 before booting into linux.  Although, it appears slightly different than the version on the lab's WRT54GL's.  Most noticeably, CFE does not recognize the ethernet hardware when first booting.  Recognizing NVRAM settings and communicating with the network is reserved for after linux is up.  This made the device unable to load the XINU code using the "boot -elf..." command.
-A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784]
+A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784 WRT350N bricked]
 A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1.  From there, a blank image was tftp'd (using put) to the router during booting.  The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating.  At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.
 Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped.  Apparently, beating the device with empty images through tftp does the trick.

@@ Line 2: / Line 2: @@
 == Caveats out of the box ==
-This router claims to use CFE version 1.0.37 before booting into linux.  Although, it appears slightly different than the version on the lab's 54GL's.  Most noticeably, CFE does not recognize the ethernet hardware when first booting.  Recognizing NVRAM settings and communicating with the network is reserved for after linux is up.  This made the device unable to load the XINU code using the "boot -elf..." command.
+This router claims to use CFE version 1.0.37 before booting into linux.  Although, it appears slightly different than the version on the lab's WRT54GL's.  Most noticeably, CFE does not recognize the ethernet hardware when first booting.  Recognizing NVRAM settings and communicating with the network is reserved for after linux is up.  This made the device unable to load the XINU code using the "boot -elf..." command.
 A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784]
 A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1.  From there, a blank image was tftp'd (using put) to the router during booting.  The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating.  At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.
 Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped.  Apparently, beating the device with empty images through tftp does the trick.

← Older revision		Revision as of 22:47, 12 July 2007
Line 1:		Line 1:
	[[Image:WRT350N.png\|thumb\|900px\|left\|The Satellite]]		[[Image:WRT350N.png\|thumb\|900px\|left\|The Satellite]]
		+
		+	== Caveats out of the box ==
		+	This router claims to use CFE version 1.0.37 before booting into linux. Although, it appears slightly different than the version on the lab's 54GL's. Most noticeably, CFE does not recognize the ethernet hardware when first booting. Recognizing NVRAM settings and communicating with the network is reserved for after linux is up. This made the device unable to load the XINU code using the "boot -elf..." command.
		+	A tip from the OpenWRT forums gives a little insight: [http://forum.openwrt.org/viewtopic.php?pid=47784]
		+
		+	A network cable was run from a front-end machine capable of communicating with the router at its default address of 192.168.1.1. From there, a blank image was tftp'd (using put) to the router during booting. The inability to verify this image as valid causes the device to drop to a CFE prompt--this time with the network communicating. At this point, one can use the standard procedure of ifconfig and boot commands as per WRT54GL protocol.
		+	Strangely, just as this procedure grew tedious, the WRT350N CFE prompt changed its disposition, and began communicating with the server as hoped. Apparently, beating the device with empty images through tftp does the trick.

← Older revision		Revision as of 19:09, 6 July 2007
Line 1:		Line 1:
−	[[Image:WRT350N.png\|thumb\|900px\|~~center~~\|The Satellite]]	+	[[Image:WRT350N.png\|thumb\|900px\|left\|The Satellite]]

← Older revision		Revision as of 19:08, 6 July 2007
Line 1:		Line 1:
−	[[Image:~~Example~~.~~jpg~~]]	+	[[Image:Satellite.png\|thumb\|900px\|center\|The Satellite]]
−	~~"The Satellite"~~