[Olsr-users] Modified Ubiquiti bootloader?

[Markus Kittenberger]

this feature is since a long while in all/most ubiquity devices,..

doing false positives aswell,.. )-;

Markus

p.s. hmm is this anyhow olsrd related? (-;

On Thu, Jul 7, 2011 at 1:23 AM, Ben West <(spam-protected)> wrote:

> I just got a response from someone on the ROBIN forum saying that the
> new POE-24-1 Ubiquiti injectors have a little reset button that
> magically puts the access point on the other end of the cat5 into TFTP
> recovery mode.  I did notice said reset button on the injectors I
> have, but I don't have a chance to test it (at least not w/o
> disrupting someone's wifi session).
>
> Has anyone else tried this feature?
>
> On Wed, Jun 29, 2011 at 7:08 PM, Ben West <(spam-protected)> wrote:
> > Apologies if the cross-post is too off-topic.  Curious if anyone has had
> > success modifying the Ubiquiti bootloader ...
> >
> > ---------- Forwarded message ----------
> > From: Ben West <(spam-protected)>
> > Subject: Re: Modified Ubiquiti bootloader?
> >
> > Sorry for dredging up an old topic, but I a query I posted to the UBNT
> forum
> > about modifying the config of their u-boot bootloader to remove the
> > dependence on the reset button went unanswered.
> > http://ubnt.com/forum/showthread.php?t=5117
> > Reposting here, in case anyone has made their own progress.
> > For some follow-up, I poked around a Nanostation M5 that I'd flashed with
> > OpenWRT. Looks like the device uses u-boot as bootloader, not Redboot.
> > Atheros AR71xx SPI Controller driver version 0.2.4
> > m25p80 spi0.0: mx25l6405d (8192 Kbytes)
> > 7 cmdlinepart partitions found on MTD device spi0.0
> > Creating 7 MTD partitions on "spi0.0":
> > 0x000000000000-0x000000040000 : "u-boot"
> > 0x000000040000-0x000000050000 : "u-boot-env"
> > 0x000000050000-0x000000150000 : "kernel"
> > 0x000000150000-0x0000007b0000 : "rootfs"
> > mtd: partition "rootfs" set to be root filesystem
> > mtd: partition "rootfs_data" created automatically, ofs=250000,
> len=560000
> > 0x000000250000-0x0000007b0000 : "rootfs_data"
> > 0x0000007b0000-0x0000007f0000 : "cfg"
> > 0x0000007f0000-0x000000800000 : "EEPROM"
> > 0x000000050000-0x0000007b0000 : "firmware"
> > Likewise, here are contents of u-boot-env, i.e. the u-boot configuration
> > options.
> > (spam-protected):~# cat /dev/mtd1
> > d
> >
> ��ethaddr=0xDE:0xAD:0xBE:0xEF:0xFF:0xeefilesize=690000fileaddr=80010000bootdelay=4baudrate=115200mtdids=nor0=ar7240-nor0partition=nor0,0mtddevnum=0mtddevname=u-bootserverip=192.168.1.254stdin=serialstdout=serialstderr=serialethact=eth0mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)bootcmd=bootm
> > 0x9f050000bootargs=console=ttyS0,115200 root=31:03 rootfstype=squashfs
> >
> init=/initipaddr=192.168.1.20u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)bootcmd=bootm
> >
> 0x9f050000(NVRAM),64k(ART)ethact=eth0partition=nor0,0mtddevnum=0mtddevname=u-boot
> > I see the options expecting a TFTP server at 192.168.1.254, with local IP
> > 192.168.1.20, and these are consistent with instructions provided for
> > firmware recovery.
> > http://www.ubnt.com/wiki/Firmware_Recovery
> > Any thoughts on a way to override u-boot's dependency on the reset
> button,
> > or is this effectively hard-coded/wired?
> > I see the bootdelay option, but nothing else that looks promising.  Even
> if
> > changing the u-boot config requires access to the on-board serial port,
> that
> > does at least provide one option for removing the requirement for the
> reset
> > button during re-flash.  That would still be very helpful when that reset
> > button sits at the top of a tall pole. ;)
> >
> > --
> > Ben West
> > (spam-protected)
> >
>
>
>
> --
> Ben West
> (spam-protected)
>
> --
> Olsr-users mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20110707/e0fba872/attachment.html>