I already solved my problem but I'd like to share the solution since I spend the whole morning trying to fix it and did not find a good answer.

The WRT150N v1.1 got bricked after an unsuccessful openwrt upgrade form 8.09 to 10.3.1.

After power-cycling the router, having waited for it to come back for 15 min, I noticed that the power LED was blinking and there was strange ping to 192.168.1.1 (not the address it had before the upgrade) with ms ranging from 10 to 1000 (usually around 300). Apparently it turned out that linksys routers have some kind of failsafe so you can upload via tftp.

So on linux I tried uploading via tftp the openwrt bin file and it did not work out (the firmware uploaded successfully and router apparently restarted but it did not boot). There is not WRT150N firmware on the linksys website, but I read somewhere that WRT160N v1 was compatible (it turned out to be).
I tried tftp-ing it and it did not work.

After that I decided to try with tftp utility from linksys but I was unable to find it linked on the website (thankfully they still had it in http://downloads.linksys.com/downloads/Tftp.exe). Using this utility and the WRT160N v1 firmware I managed to bring the device back to life. After the upload the web interface even stated that it is WRT150N, however I have not tested the rest of the functionality.
I uploaded the openwrt via the web interface and had a happy end.

TLDR:
- if you have blinking power LED and strange ping to the router at 192.168.1.1 (avg > 100 ms)
- find a windows machine (linux's tftp did not work for me)
- download the linksys tftp utility (http://downloads.linksys.com/downloads/Tftp.exe)
- download the WRT160N v1 .bin firmware (notice 160) http://downloads.linksys.com/downloads/ … S_code.bin
- connect the router to the PC via a LAN port
- set IP for the PC 192.168.1.2/24
- power-cycle the router
- ping
- upload the firmware
- wait
- go to http://192.168.1.1 and login with admin, admin
- upload new openwrt firmware

What command did you use with the Linux's tftp tool (the one that didn't work)?

$ tftp 192.168.1.1 <<<'put firmware.bin'

Also I tried the more verbose:

$ tftp 192.168.1.1
> verbose
> mode binary
> connect 192.168.1.1
> put firmware.bin

It showed that the firmware was uploaded successfully and the router seemed to restart, but it did not accept it (I tried power-cycling, syncing the upload with a ping, ...).

The first command was likely to fail because not using binary mode (you missed "-m binary"). The second should work, no idea why it has failed. Too bad you didn't have serial console attached

This is interesting.  In the past, I have tried to tftp (from linux) during the 1-3 seconds that CFE waits for a tftp upload after boot, but was never successful (Linksys E3000).  I will have to try this with the Linksys Tftp.exe to see if it behaves any differently (the next time I flash).

I should have done a traffic dump, but I did not expect it to work - this was actually my last attempt before giving up for the day.
Unfortunately, since I do not have a jtag cable, I do not want to toy too much with the router.

I did a quick test with socat and it turns out that the linksys tool does not follow the TFTP spec ( https://www.ietf.org/rfc/rfc1350.txt ) and basically appends an extra 0x00 to the WRQ.
There might be more differences but it has to be tested against a real router.

P.S. @Zajec my linux tftp client does not support a "-m" switch (debian testing, the tftp package)

I also had problems uploading files with windows tftp utility to linksys wrt160nl.
I have PL2303 converter and know what happens on console.
Router accepts less than 1 Kb then stops reception, then it flashes this broken chunk and next time it doesnt boot.
Linksys tftp server is somehow broken when using windows tftp.
I solved the problem another way.
I used server located on my pc and downloaded the image to RAM at offset 0000000C. Then i erased the flash manually with erase command and copied image from RAM to flash with cp.b.
It worked.
Correct address and length I figured out from output of regular update procedure (which was flashing broken 734 bytes chunk).

Things become much easier when you have access to console.
I bough my PL2303 just for 10$. Linksys have serial connector with pins, so you dont need any soldering. Everything is easy

Did you use linksys's tftp utility or just a windows tftp client?
Because if it was just a windows tftp client then it might suffer from the same problem as the one on linux (in other words - the "problem" of following the tftp specification).

I used only windows tftp client utility with the bad result I described above. Didnt know about linksys tftp. So i used tftp client on the router (with special U-boot command from serial console) instead of tftp server. This tftp client worked well with WinAgents tftp server running on windows PC.

If you enter a password in the Linksys TFTP utility,  it shows up as clear text just prior to the extra "0x00"; the extra "0x00" seems to be the null terminator for the password (non-standard).

Now that you mentioned that, I managed to find that the dd-wrt guys have a special program that simulates the linksys tftp's behavior and list it in the troubleshooting guide for the WRT54G2
( http://www.dd-wrt.com/wiki/index.php/Li … leshooting ) - http://www.dd-wrt.com/dd-wrtv2/download … tp.tar.bz2

I hate it when companies do not follow standards...

I bricked a wrt150n that was saved from electronic waste, so I came across this old post.

Finaly, I made it work under ubuntu with :

atftp --trace --verbose --option "mode octet" --option "timeout 60" -p -l openwrt-15.05.1-brcm47xx-legacy-linksys-wrt150n-squashfs.bin 192.168.1.1

Got it to reboot and root login in telnet.
However, it is a old router and only 16mb of ram (1064k free) makes it impossible to "opgk upgrade"
So manual compiling of an image with wanted apps is required.
Just running top will raise load over 2.2 to 3.21 !