Buffalo NAS-Central Forums
http://forum.buffalo.nas-central.org/

LS-GL Custom Updater Thread - ACP-Commander
http://forum.buffalo.nas-central.org/viewtopic.php?f=19&t=1693
Page 7 of 11

Author:  lb_worm [ Fri Dec 15, 2006 11:45 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

LS1 communication is slightly different. I have code something similar on my box (in C) box but never progressed any further.

Author:  Georg [ Fri Dec 15, 2006 11:49 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

No, my bad handling of the received answer packets. It looks for a null-terminated string starting at the 40th byte and println's it. If there is 0x00: Blank line.
If you get "**no message**" it is actually that what linkstation sends back (eg. successfull "telnetd" has no cmd-line output).
No communication with the LS would result in an exception.
I'm also looking for a FF:FF:FF:FF in the first part of the packet, wich seems to indicate an error (in some answer packtes). Then you'd get something like "Failure".

Maybe they use a slighltly different format of the packets? If you send nonsense to the LS-PRO it simply won't answer -> exception. As you get blank lines there is some sort of answer coming in. But again there could be a different behaviour between LS-PRO and LS1.

Author:  Georg [ Fri Dec 15, 2006 11:51 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

mindbender, if catching the answer packets is a problem, try something like '-c "cat /etc/shadow > /root/test.txt"' and look for the output there.

Author:  lb_worm [ Fri Dec 15, 2006 11:53 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

So, mindbender/georg, how is the testing going with Georg's neat comms software. Nearly ready for a serious test?

Author:  Georg [ Fri Dec 15, 2006 11:55 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

There is that bug issue, read my PM?

Author:  mindbender [ Fri Dec 15, 2006 3:25 pm ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

well....both bugs work, the acp-commander-bug triggers the clientUtil_server-bug and telnet is running :)

but i cannot execute remote commands.

i only get "**no message**"-lines.

i thought maybe i just do not see them, but i tested this with

Code:
java -jar acp-commander -t ls-pro -c "touch /test"


..../test did not exist afterwards. but as telnet was there this was not a big problem.

georg...could you upload the source? i would like to have a look at it. a custom updater really is possible now.

Author:  lb_worm [ Fri Dec 15, 2006 4:40 pm ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

If you can make this be drivable from an external file: we can put bash (routed via telnet) commands into an input file which which the acp-commander executes? We could have special acp-commander commands too like delay(30) which allows 30 seconds before executing the next command? This would allow us to do reboots etc?

Author:  Georg [ Fri Dec 15, 2006 6:51 pm ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

uploading the java file to http://buffalo.nas-central.org/download/uploads/LS_Pro_temporary/LSCustomUpdater/

Hmm, mindbender for me it's working. First command creates /test, second removes it again.
Code:
 
>java -jar acp_commander.jar -t linkstation -c "touch /test"
ACP_commander out of the linkstationwiki.net project.
Used to send ACP-commands to Buffalo linkstation(R) LS-PRO.
 
Using random connID value = AA3A1BBDCF69
Using target:   linkstation/192.168.0.150
**no message**
**no message**
 
>java -jar acp_commander.jar -t linkstation -c "rm /test"
ACP_commander out of the linkstationwiki.net project.
Used to send ACP-commands to Buffalo linkstation(R) LS-PRO.
 
Using random connID value = B2FF3A8ECFF6
Using target:   linkstation/192.168.0.150
**no message**
**no message**
@lb_worm... you could also put the file (script) into /mnt/disk1/share and call it via acp_commander or telnet (if the -c option is unreliable.)

Author:  Georg [ Fri Dec 15, 2006 9:38 pm ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

Added some info to the wiki.

Just ran a test. As suspected acp_commander works independently of the admin password. Back door. :p

Author:  mindbender [ Sat Dec 16, 2006 12:34 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

i am thinking about adding an optional java-gui to acp_commander.

the cool stuff about java is that the same gui/binary will work on all systems...

and then we could add our own way of updating via the acp_command_shell.

that sounds cool.

if the process on the LS1 also has a similar bug?

jonli447
could you update the title of this thread from
"LS-GL Custom Updater Thread"
to
"LS-GL Custom Updater Thread - ACP-Commander"
?

i have no clue why this damn arm-sections are not administratable....

Author:  Georg [ Sat Dec 16, 2006 8:37 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

@mindbender, that's why I suggested java. The first version with hard coded packets acutally had a gui. Even had a "log"-window showing the commands in blue, errors in red and ls-answers in black. Neat, but the rest ....
For the current purpose I thought a command line tool would be fine.

The suggestion to use the CSV sounds good, do I need a special account?

I think next steps should be to create some classes e.g:
ACPpacket
byte [] buf;
set/get PcktVersion, ACPcmdtype, ConnectID, MAC, (optdatalength), optdata

ACPspacket extends ACPpacket
setCmd
makeCmd (cmdline)
makeAuth (password) // encryption?
makeDiscover
makeAuthBug

ACPrpacket extends ACPpacket
getCmd // cmd word at [8],[9]
getResult // Error code
getAnswer // string starting form
getOptLength
getOptData
getMAC, PktVersion, ConnID
.... // what is needed to decrypt the packets

and the "main" class
ACPClient
InetAddress targetLS;
DatagramSocket ACPsocket;
Integer status // nothing, waiting for reply, timeout, error

set/get MAC, ConnID, target, sockettimeout
sendCmd (cmdline)
sendAuth
sendDiscover
sendAuthBug
...
getAnswerPkt
onReceive (ACPrpacket _AnswerPkt, ACPcmdtype _cmd) // called, when a packet is received _cmd is the originally
// sent cmd, might be handy for analysing the answer.
onDiscover (ACPrpacket _AnswerPkt // called, when a discover answer is received, e.g to fill a list

We should put the receiving part in an own thread, started when a packet is sent so that is not blocking (needed for gui). The application can then either check for the status (could make it blocking again) or it could define onReceive, onDiscover events, that are called by the receivethread on receiving a packet.

Ok, my daughter wants to play with me ;)

Author:  lb_worm [ Sat Dec 16, 2006 9:26 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

You are correct, the rx should be in its own thread so as not to block. I think that if it had a web front end then it would be universal, if you want to go that route?

Author:  mindbender [ Sat Dec 16, 2006 12:41 pm ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

Georg wrote:
The suggestion to use the CSV sounds good, do I need a special account?


i will setup the cvs-repository at sourceforge.

you will have to register a user there....for write access of course which i will grant you (and others who would like to help) then.

Author:  lb_worm [ Thu Jan 04, 2007 11:26 am ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

Any updates?

Author:  mindbender [ Thu Jan 04, 2007 12:57 pm ]
Post subject:  Re: LS-GL Custom Updater Thread - ACP-Commander

i am in contact with the sourceforge team...

i just read that they offer svn instead of CVS...i submitted a request that we would like to have svn instead of CVS and we need a module called "acp_commander".

i hope they will answer soon.

Page 7 of 11 All times are UTC+01:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/