Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Thu Apr 24, 2014 3:44 am

All times are UTC [ DST ]




Post new topic Reply to topic  [ 158 posts ]  Go to page 1, 2, 3, 4, 5 ... 11  Next
Author Message
PostPosted: Fri Nov 03, 2006 7:23 pm 
Offline
Site Admin

Joined: Fri Aug 04, 2006 2:37 am
Posts: 1652
Location: United States of America
Per Georg requests... :) He're is the thread for creating a custom firmware updater. This is an continuation of the thread http://buffalo.nas-central.org/forums/index.php?action=vthread&forum=16&topic=1501 that sort of divided into two subtopics: telnet/root-enabled fw and custom updater. So the updater portion is continuing here. Thanks :)

_________________
http://www.opifer.net


Top
 Profile  
 
PostPosted: Sat Nov 04, 2006 9:11 pm 
Offline
Newbie

Joined: Sat Nov 04, 2006 7:41 pm
Posts: 18
Location: United States of America
Hello,

I just recently got a Linkstation Pro and after a little trouble updated it with Firmware 1.03 got telnet w/o root password going. I logged the session with ethereal.

Some information about the Version 1.03 updater that is on the NA site as part of the 1.03 firmware update.
In the lsupdater.ini file changing VersionCheck under the Flags section from 1 to 0 will disable the version check so an updated box will show up in the inital scan. The box can not be updated again as the program still checks the dates on the box.
Code:
[Flags]
VersionCheck = 0


The following dump is mixed hex and text. xx 23 5b... are hex and 2006/08 or LS-GL are text.
The sequence:
Code:
1. Computer broadcasts UDP packet to 255.255.255.255 port 22936
20 00 00 00 08 00 01 00 20 80
00 00  = Payload Size (No Payload)
00 00 00 00
00 c0 9f xx xx xx Source Mac Address
ff ff ff ff ff ff     Destination Mac Address
00 00 00 00
 
 
2. LinkStation Pro responds with UDP packet to 255.255.255.255 (Port is the port used by the computer query)
20 00 00 00 09 00 01 00 20 c0
20 01   = Payload Size
00 00 00 00
00 16 01 xx xx xx  =  Source Mac Address
00 c0 9f xx xx xx   = Destination Mac Address
00 00 00 00
--Payload--
xx xx a8 c0   = IP Addess of the box with most significant byte last   01 02 a8 c0 is 192.168.2.1
00 ff ff ff       = Net Mask with most significant byte last
00 00 00 00 64 fe aa 48
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Host Name (16 bytes) Null Terminated String
00
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Workgroup (15 bytes) Null Terminated String
00
LS-GL(IESADA)  = Product ID Null Terminated String
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 25 02 00 00 00 00 00 00 00 00 d6
07 0b 00 04 00 0c 00 2f 00 08 00
xx xx a8 c0  = Default Gateway
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01   = Major Version?
00   = Minor Version?
00 00
09 00 00 00 = Product ID Number? 00000009
2006/06/28 09:42:00   = Root FS Timestamp Null Terminated String
00 00 00 00 00
HDD 0.42  = Hard Disk Driver or Hardware Detection Driver Version?  Second part of Version string (1.00-0.42)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 08 01
FLASH 0.00  = Firmware Subversion Null Terminated String
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2006/06/11 14:33:21 = Kernel Timestamp Null Terminated String
00 00 00 00 00
00 16 01 xx xx xx  LSE Mac Address
 00 00 00
 
After update the LinkStation Pro sent:
20 00 00 00 09 00 01 00 20 c0
20 01 = Payload Size
00 00 00 00
00 16 01 xx xx xx  = Source Mac Address
00 c0 9f xx xx xx  = Dest Mac Address
00 00 00 00
-- Payload --
xx xx a8 c0   = IP Addess of the box with most significant byte last   01 02 a8 c0 is 192.168.2.1
00 ff ff ff       = Net Mask with most significant byte last
00 00 00 00 19 f6 8f 1e
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Host Name (16 bytes) Null Terminated String
00
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Workgroup (15 bytes) Null Terminated String
00
LS-GL(IESADA)  = Product ID Null Terminated String
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 25 02 00 00 00 00 00 00 00 00 d6
07 0b 00 03 00 16 00 35 00 11 00
xx xx a8 c0  = Default Gateway
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01   = Major Version?
03   = Minor Version?
00 00
09 00 00 00 = Product ID Number? 00000009
2006/10/16 16:03:19   = Root FS Timestamp Null Terminated String
00 00 00 00 00
HDD 0.47  = Hard Disk Driver or Hardware Detection Driver Version?  Second part of Version string  (1.03-0.47 )
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 08 01
FLASH 0.00   = Firnware Subversion Null Terminated String
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
2006/08/08 17:16:01   = Kernel Timestamp Null Terminated String
00 00 00 00 00
00 16 01 xx xx xx  MAC Address
00 00 00


This appears to be a status information query and response. More fields could be figured out by changing settings on the LS Pro, and then use the firmware updater to generate the query while logging with ethereal.

73 Eric


Top
 Profile  
 
PostPosted: Sun Nov 05, 2006 1:51 am 
Offline
Newbie

Joined: Sat Nov 04, 2006 7:41 pm
Posts: 18
Location: United States of America
Hello,

I do not know if the focus is to modify the existing windows exe or build a new one.

I looked at the ethereal log file some more. The LinkStation Pro (LSP) listens on Port 22936.
This port seems to be used for everything dealing with updating.

Find Phase
1. Computer sends an UDP Packet from Computer IP Port nnn to 255.255.255.255 Port 22936
Appears to be an information query

2. LSP sends an UDP Packet from LSP IP Port 22936 to 255.255.255.255 Port nnn (same as computer)
Contains information structures (Network and version)

Update Phase
1. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Appears to be an information query

2. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Contains information structures (Network and version)

3. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Appears to be a sending data structure Possibly a password

4. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Appears to be an ack, possibly indicating Password is good)

5. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Structure that has a command string "cat /proc/buffalo/firmware"

6. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Output of command:
PRODUCTNAME=LS-GL(IESADA)
VERSION=0.08
SUBVERSION=FLASH 0.00
PRODUCTID=0x00000009
BUILDDATE=2006/06/11 14:33:21
BOOTVER=1.01

7. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Structure that has a command string "cat /etc/initrd_ver"

8. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Output of command:
VERSION=0.09
SUBVERSION=RAM 0.00
PRODUCTID=0x00000009
BUILDDATE=2006/06/11 14:51:39

9. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Mostly 00 bytes

10. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Appears to be an ack

11. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Data structures including string "!/boot/uImage.buffalo"

12. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Appears to be an ack

13. TCP Session starts from the Computer IP Port nnn to LSP IP Port 22936
Appears to be the kernel

After the TCP session ends, there are a couple more UDP packets between the computer and LSP, then another TCP session to upload the next file. At the end there are some more UDP packets. After the LSP is rebooted the computer sends a query ocassionally until the LSP responds.

73 Eric


Top
 Profile  
 
PostPosted: Sun Nov 05, 2006 4:54 am 
Offline
Site Admin

Joined: Fri Aug 04, 2006 2:37 am
Posts: 1652
Location: United States of America
EricC wrote:
I do not know if the focus is to modify the existing windows exe or build a new one.

Depending on how difficult the steps, ideally, we would probably just modify the Buffalo updater exe...then again, it looks as if we'd have a lot of stuff to change, so we might have to just build our own "linkstationwiki updater". Basically, we're trying to bypass the version checks and make it optional to save/restore settings. Obviously, some of that will depend on the flasher on the box itself. Nice info, it's much appreciated. :)

_________________
http://www.opifer.net


Top
 Profile  
 
PostPosted: Sun Nov 05, 2006 8:37 pm 
Offline
Developer

Joined: Wed Oct 25, 2006 6:05 pm
Posts: 613
Location: Germany
@jonli, thanks for the special Wink
@Eric, thanks for the details of the update process!

Well, with Heinz script I think, understanding the updater becomes less important. The standard updater works for our needs (we know how to enable telnet and get our own updates on the box). On the other side. There's no harm to get and understand as much information as possible. Anyway without a box there is little that I can acutally do at the moment. So another look at the updater:

At 0040c480 starts the routine readint the lsupdater.ini file. At least most of it (given are the standard values that are used if the value is not defined in the ini).

Code:
 
[Application]
Title = Buffalo LS-GL updater
WaitReboot = 180 (0xB4) #Int
WaitFormat = 180 (0xB4) #Int
WaitChange = 180 (0xB4) #Int
 
[Target]
Password = password #string; could that be the root-pswd?? Or is it for the (scrambled) rsync
Name = LS-GL     # string; name shows up in searching respective not found message window; Must it ma tch the device name?
 
[Flags]
VersionCheck = 0 #Int
 
[SpecialFlags]
Debug = 0    #Int; enables debug-mode in the updater (via context-menu in title bar)


So three new values (WaitFormat, WaitChange and Debug). If you set Debug to 1 you get a nice new entry in the context menu at the title-bar of the updater. There you can choose if you want to

- update: Kernel, Boot, initrd, rootfs (separately)
- config: version check, rebuild partitition table, delete user config, force update
- destination of firmware: /boot
- IP-Address/DHCP

The first two set of options might make live somewhat easier.

_________________
acp_commander users note: from ver. 0.4 on the correct ACP authentication method is used, avoiding possible side effects.
Download: http://sourceforge.net/project/showfile ... _id=167037


Top
 Profile  
 
PostPosted: Sun Nov 05, 2006 8:50 pm 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
This is rather neat. Updating the kernel ,initrd and rootfs is good. To remove any un-necessary flashing of the flash is a good choice. This will aid development.

_________________
LS used as PVR and streaming source


Top
 Profile  
 
PostPosted: Sun Nov 05, 2006 9:59 pm 
Offline
Newbie

Joined: Sat Nov 04, 2006 7:41 pm
Posts: 18
Location: United States of America
Hello,

I was looking at the debug entry and only got as far as noting that it also disabled the version check during the find phase, I did not think of checking the context menu.

I approached it by breakpointing the readprivateprofile function entry points in the debugger and seeing what was passed. I have 0x3c as the default value for wait change.

If an user can force upload of the same version of files then it eliminates the need for a custom uploader. Although it would be nice to have a tool under linux to query and update the box. I hate to have to switch between linux and windows.

I finally got ftp setup on my LSP and use it like it was intended. It is fast on my gigabit network. I was thinking of getting wget going on the box so I can use it as an personal mirror site of SuSE updates. So I am looking at setting up cross compiling on my notebook.

73 Eric


Top
 Profile  
 
PostPosted: Mon Nov 06, 2006 9:28 pm 
Offline
Developer

Joined: Wed Oct 25, 2006 6:05 pm
Posts: 613
Location: Germany
Having the debug option - is there anything left we *need* from an updater? If all that works as the debug dialog suggests, the update process should be pretty that what we need: Selection of what to update and bypass of version checking (but I've only a quite rough idea of uboot/kernel development - so forgive me if I'm wrong).

The other side is further understanding the update process maybe for a linux/mac updater as Eric suggests?


As far as I understand it at the moment, the udp traffic is handled by /usr/local/sbin/lsprcvd. That seems to initiate a rsfwds-session on port 8873. Somewhere I read that this seems to be a rsyncd with openssh encryption. Strings shows that also lsprcvd uses openssh. As these are using openssh - shouldn't be there gpl-sources (maybe from the other *stations)?

\usr\local\bin\ls_sonar seems to be the linux scanner for linkstations see also BufBackupSonar.pm in www section.
\usr\local\bin\rsbackup.pl is the backup script used by the web-interface. Guess prinicipially the updater works similar for the tcp-part Eric describes. In line 332 the script seems to read a passwd from a temp-file. Could be interesting - or is it a passwd you have to enter in the web-interface?

_________________
acp_commander users note: from ver. 0.4 on the correct ACP authentication method is used, avoiding possible side effects.
Download: http://sourceforge.net/project/showfile ... _id=167037


Top
 Profile  
 
PostPosted: Mon Nov 06, 2006 10:00 pm 
Offline
Site Admin
User avatar

Joined: Mon Jul 11, 2005 7:19 am
Posts: 7702
Location: Austria, Vienna
in my personal opinion it should be the goal to create a telnet enabled ramdisk (which implements EM Mode).

then we need a failsave way to get into EM mode.....with a telnet + ftp enabled EM Mode we can simply upload the custom hddrootfs & untar it there.....

thats the exact thing i am working on all other boxes.

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!


Top
 Profile  
 
PostPosted: Tue Nov 07, 2006 5:40 am 
Offline
Site Admin

Joined: Fri Aug 04, 2006 2:37 am
Posts: 1652
Location: United States of America
mindbender wrote:
in my personal opinion it should be the goal to create a telnet enabled ramdisk (which implements EM Mode).

I've read your thread about this; I think that's a good idea too. I think though that we must have a backup prog for updating the custom firmware should the ramdisk fail for users. But, like I said, you are right in that a telnet enabled ramdisk should be the #1 goal as it would pull all of our objectives into one method (gaining remote EM acess, simple updating procedure, and simple and almost transparent way to reset root passwords).

_________________
http://www.opifer.net


Top
 Profile  
 
PostPosted: Tue Nov 07, 2006 7:01 am 
Offline
Site Admin
User avatar

Joined: Mon Jul 11, 2005 7:19 am
Posts: 7702
Location: Austria, Vienna
and having no weird untaring of any config files over our rootfs.

-> thats the main reason why i want to create this....we had severe problems with OpenLink/FreeLink where /etc/passwd was restored also beside much other stuff.

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!


Top
 Profile  
 
PostPosted: Wed Nov 08, 2006 8:37 pm 
Offline
Developer

Joined: Wed Oct 25, 2006 6:05 pm
Posts: 613
Location: Germany
Had a look at some of the programs in the file system - mostly by running strings on them. Hoped to gather some more information how the update process works, but didn't stick to only that. Compiled the information collected so far in a small doc that I uploaded to

http://buffalo.nas-central.org/download/uploads/LS_Pro_temporary/LSPro_Softw.rtf

Guess that most of the information is already available in another place...
Some of the programs seem to have a debug mode. The strings ls_sonar and clientUtil_server seem to confirm Erics analysis of the network traffic.

Miconapl is quite interesting. As lb_worm and mindbender explain it is used for communication with the hardware
http://buffalo.nas-central.org/forums/index.php?action=vthread&forum=19&topic=1556&page=0#msg15075

@mindbender: good luck for your exam!

_________________
acp_commander users note: from ver. 0.4 on the correct ACP authentication method is used, avoiding possible side effects.
Download: http://sourceforge.net/project/showfile ... _id=167037


Top
 Profile  
 
PostPosted: Sat Nov 11, 2006 6:09 am 
Offline
Site Admin

Joined: Fri Aug 04, 2006 2:37 am
Posts: 1652
Location: United States of America
Guys (especially Georg), I'd greatly appreciate if you could document any efforts made here in my wiki page under Custom Updater. I am trying to consolidate all of the development information so that the development team can easily sort the stuff out.

@Georg, I'm sorry that I spawned the idea of a custom updater (actually mindbender gave me the idea) and haven't been able to help you dissassemble the updater. I've been extremely busy w/ my wife, school, work, and computer crisis. I'll will look at your work in my spare time. Any time will you have to add your info to the wiki page will definately help me, mindbender, and others to sort all of this out. Again, sorry, but thanks.

_________________
http://www.opifer.net


Top
 Profile  
 
PostPosted: Sun Nov 12, 2006 4:25 am 
Offline
Newbie

Joined: Sat Nov 04, 2006 7:41 pm
Posts: 18
Location: United States of America
Hello,

I got a chance to do some more work with the LSP. In particular I wanted to use debug mode to dump the comunications on the LSP side.

I found that lsprcvd does not have anything to do with updating. I can stop it and the unit will be discovered and updated.

I looked at clientUtil_server. It is watched by daemonwatch so at first it kept restarting when I stopped it. After I stopped daemonwatch then I was able to stop clientUtil_server. With it stopped the box was not discovered. I then ran it with the -i eth0 -f -d parameters and got debug dumps off the console.

Code:
root@LS-GLFDC:/etc/init.d# clientUtil_server -f -d -i eth0
no fork
start at debug mode
clientUtil_server Ver.1.01
--- no fork
listen device name = eth0
>RecvFromSocket: --> cli=192.168.57.111 len=32
==========< ACPHeader >==========
0x22400: --<DumpAcphPacket>-- len=64
000: 20 00 00 00 08 00 01 00
008: 20 80 00 00 00 00 00 00
010: 00 C0 9F D9 B7 1D FF FF
018: FF FF FF FF 00 00 00 00
020: 00 00 00 00 00 00 00 00
028: 00 00 00 00 00 00 00 00
030: 00 00 00 00 00 00 00 00
038: 00 00 00 00 00 00 00 00
 
header_size=0x20        packet_version=0x10008
option_size=0   command=0x8020
connection_id=00:C0:9F:D9:B7:1D
destination_id=FF:FF:FF:FF:FF:FF
result=0
 
4555e5e7: ***** ACP_Discover_Reply
 
4555e5e7: ***** FillDiscoverReplyPacket
  gateway = 0x139a8c0
>SendDiscoverReply:0
>SendReplyPacket:cmd[c020] result[0] ip[ffffffff] datalen[288]
  host_name  = LS-GLFDC
  group_name = TEST
  product    = LS-GL(IESADA)
  flag       = 0
  IP Address = 0xe39a8c0
  optlen     = 288
==========< ACPHeader >==========
0x3bad0: --<DumpAcphPacket>-- len=64
000: 20 00 00 00 09 00 01 00
008: 20 C0 20 01 00 00 00 00
010: 00 16 01 41 0F DC 00 C0
018: 9F D9 B7 1D 00 00 00 00
020: C0 A8 39 0E FF FF FF 00
028: 00 00 00 00 76 94 19 38
030: 4C 53 2D 47 4C 46 44 43
038: 00 00 00 00 00 00 00 00
 
header_size=0x20        packet_version=0x10009
option_size=288 command=0xC020
connection_id=00:16:01:41:0F:DC
destination_id=00:C0:9F:D9:B7:1D
result=0
----< ACPHReply >----
ip=192.168.57.14        mask=255.255.255.0
flag=       0 []
key=38199476
hostname=[LS-GLFDC]
product=[LS-GL(IESADA)]
hardware_info=   0
capacity_high=       0
capacity_low=       0
y/m/d/h/m/s=2006/11/11 10:1:59
gateway=0139a8c0
DNS1=00000000 DNS2=00000000
WINS1=00000000 WINS2=00000000
VERSION=1.3
product_id=9
build_date=[2006/11/10 16:03:19]
sub_verion=[HDD 0.47]
FLASH_VERSION=0.8       FLASH_SUBVERSION=[FLASH 0.00]
FLASH_BUILDDATE=[2006/11/06 13:47:08]
starting_mode=1
eth0_mac=00:16:01:41:0F:DC
>SendPacket:src=5998 dst=450 ip=ffffffff len=320


73 Eric


Top
 Profile  
 
PostPosted: Sun Nov 12, 2006 9:43 am 
Offline
Developer

Joined: Wed Oct 25, 2006 6:05 pm
Posts: 613
Location: Germany
Eric, great that should help us to understand the traffic much better! I guess that the procedure to open the TCP-port is the same for the updater and the backup (rsync maybe with ssl) between two LS. Hope to get my box by end of the month.

_________________
acp_commander users note: from ver. 0.4 on the correct ACP authentication method is used, avoiding possible side effects.
Download: http://sourceforge.net/project/showfile ... _id=167037


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 158 posts ]  Go to page 1, 2, 3, 4, 5 ... 11  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Protected by Anti-Spam ACP
Protected by Anti-Spam ACP Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group