ISOUtil.hex2byte appending 0 to left of my message - jpos

I am trying to create a JPOS web service using JAVA. Here is the code I am using.
GenericPackager packager;
packager = new GenericPackager("ISO_8583_1987.xml");
org.jpos.util.Logger logger = new org.jpos.util.Logger();
logger.addListener(new SimpleLogListener(System.out));
((LogSource)packager).setLogger(logger, "debug");
ISOMsg isoMsg = new ISOMsg();
isoMsg.setPackager(packager);
isoMsg.unpack(b);
printISOMessage(isoMsg);
The problem is all the way in the beginning on hex2byte method.
Length of everything up until Datafield 19 is in multiples of 2. Datafield 19 in my packager is IFB_NUMERIC with length 3. When I send message 02000000200000000000177 (Only datafield 19 set), hex2byte appends 0 to the left to make the message length even. Because of that, MTI comes as 0020 instead of 0200. This also messes up the bitmap since the bit set for field 17-18-19-20 is not bitmap for 21-22-23-24. As expected, when I run this, unpack method shows bit 23 as 017. This of course works fine if I send message 020000002000000000001770 (additional 0 at the end).
Should I be using something other than ISOUtil.hex2byte?

Related

How to send an RTS 802.11 packet using Scapy (and get a CTS response)

I'm quite new to Scapy, and I'm trying to craft an RTS packet and send it to an AP, in order to get a CTS response. However, I'm having a really hard time figuring out the proper way to do it (being a beginner in networking and 802.11 packets doesn't help either).
This is the code I have for now:
bytes = struct.pack("<H", 123) # 123 microseconds
timeval = struct.unpack(">H", bytes)[0]
pkt = RadioTap()/Dot11(addr1 = target_addr, addr2 = my_addr, type = 1, subtype = 11, ID = timeval)
I know that type must be equal to 1 since it's a Control packet, and that subtype must be equal to 11 because it's an RTS packet. However, when I send the packet with either sr() or srp() or sr1() I either get no response back (Scapy waits for a response but nothing gets back so it just continues waiting) or I get the exact message I sent.
This question mentions adding a Dot11Elt() layer at the end, however that changes nothing in my case.
This is the type of response I get back:
And if I open the 0th element of the response tuple with Wireshark, I get:
I've hidden the MAC addresses, but they are the sameas those I put in the packet I sent to the AP (target_addr and my_addr). I'm expecting to get back a CTS with my_addr as "destination address".
What am I doing wrong?

cell clicked works locally but not on remote shiny server --DT

I have an application that listens for a cell click in a DT in any cell and then updates a plot accordingly. The program works perfectly when I runApp() locally. However when I depoloy the app on a shiny server, the click no longer triggers any actions. This discepancy does not exists for other action listeners such as a simple refresh button, as I have demonstrated in the code below. You can see how the discrepancy between remote and local does not exist for the refresh button condition input$refreshButton!=0, but there is a discrepancy using the length(input$table_cell_clicked)>0 trigger condition.
I have done some research into this error and this is what I know so far:
1) I am getting the warning "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience." in the console when the app is deployed remotely. I am told this has something to do with a setting in a file in my shiny server called javascript.min.js and jquery.min.js that says c.async="false" I have searched for every file on my serer with that name or containing the string async="false", and changed the setting to sync="true". However I did not find any files with the exact string c.async="true". I can see the file with this string in the browser console, which gives a location relative to server::port/, but I do not know where that file actually lives on my system, and I suspect it is just a file made on the fly by shiny services.
2) It is possible that this could be fixed with something related to the selectize functionality in some shiny inputs, which may cause the code to execute asynchronously(?). I have tried a few different things but couldn't get any to solve the problem.
3) There is a commonly known annoyance with shiny that it is generally hard to debug. In my case, it would be extremely helpful if I could see the output of the server.R functions as I would when using runApp() locally. Using a call to browser, options(shiny.trace = T) were both recommended, but when I add them to the code below, nothing apprears in the console output. I even tried using sink in order to save to output to some file on the remote server, and it rusn without error, but I do not see any file in the location indicated. If I could at least see the output of this file, or the request/response messages between the server and the client it would go a long way towards debugging this.
So the two questions are: how can I see these messages/output when the app is deployed remotely? And more importantly, how can I implement a fix so that all of my hard work on this project (unfortunately can't disclose any details) will not be a waste.
The basic code for my shiny app is below.
server.R:
server <- function(input, output, session) {
options(shiny.trace = T)
browser()
sink("~/outputfile.txt",append = T,type = "output",split = T)
end_date=as.character(as.Date(Sys.Date()-10))
library(DT)
library(data.table)
library(xtable)
library(zoo)
library(lattice)
library(RSQLite)
output$table = DT::renderDataTable({
thisTable = head(iris)
return(thisTable)
},server = T,options = list(target = 'cell'))
output$plot1 <- renderPlot({
cell= as.numeric(input$table_cell_clicked)
print(cell)
row = as.numeric(input$transtable_row_last_clicked)
print(paste0("last row clicked: ",row))
print(paste0("timestamp: ",Sys.time()))
(cell, file = "/home/plintilhac/cell_file.txt") ## causes error that dumps SND and REC messages to javascript console
# if (length(input$row_last_clicked)>0){ ##works remotely and locally
# if (input$refreshButton!=0){ ##works remotely and locally
if (length(cell)>0){ #works locally, but doesn't work remotely
plot(0,0,xlim = c(-1,1),ylim = c(-1,1))
}
else{return(plot(0,1,xlim = c(-1,1),ylim = c(-1,1)))}}
)
output$text1 <- renderText({
if (input$refreshButton!=0){
"clicked"
}
else{"unclicked"}
})
}
ui.R
shinyUI(
fluidPage(
fluidRow(plotOutput("plot1",click = "plot_click"),theme = "bootstrap.css"),
mainPanel(
DT::dataTableOutput('table'),
fluidRow(
actionButton("refreshButton", "refresh")
)
)
))
EDIT:
I was able to get some output by placing an erroneous line of code right after the cell variable is defined, causing the shiny server to dump output to the javascript console. At this time this is the only way I know how to capture any output. However, the output is quite informative, as it shows that the table_cell_clicked attribute is not being exported on the remote server at all, whereas other attributes such as row_last_clicked are.
here is the output I get when the server is run locally ithout the erroneous line (note it includes table_cell_clicked as a feature):
SEND
{"config":{"workerId":"","sessionId":"ef292cd0c98baee4afa504aa8330b49e"}}
RECV
{"method":"init","data":{"refreshButton:shiny.action":0,".clientdata_output_plot1_width":873,".clientdata_output_plot1_height":400,".clientdata_output_plot1_hidden":false,".clientdata_output_table_hidden":false,".clientdata_pixelratio":1.100000023841858,".clientdata_url_protocol":"http:",".clientdata_url_hostname":"d2rm01",".clientdata_url_port":"8787",".clientdata_url_pathname":"/p/4944/",".clientdata_url_search":"",".clientdata_url_hash_initial":"",".clientdata_singletons":"",".clientdata_allowDataUriScheme":true}}
SEND
{"errors":[],"values":{"table":{"x":{"filter":"none","container":"<table
class=\"display\">\n <thead>\n <tr>\n <th> </th>\n
<th>Sepal.Length</th>\n <th>Sepal.Width</th>\n
<th>Petal.Length</th>\n <th>Petal.Width</th>\n
<th>Species</th>\n </tr>\n
</thead>\n</table>","options":{"target":"cell","selectize":true,"columnDefs":[{"className":"dt-right","targets":[1,2,3,4]},{"orderable":false,"targets":0}],"order":[],"autoWidth":false,"orderClasses":false,"ajax":{"url":"session/ef292cd0c98baee4afa504aa8330b49e/dataobj/table?w=","type":"POST","data":"function(d)
{\nd.search.caseInsensitive = true;\nd.escape = true;\nvar encodeAmp
= function(x) { x.value = x.value.replace(/&/g, \"%26\"); }\nencodeAmp(d.search);\n$.each(d.columns, function(i, v)
{encodeAmp(v.search);});\n}"},"serverSide":true,"processing":true},"selection":{"mode":"multiple","selected":null,"target":"row"}},"evals":["options.ajax.data"],"deps":[{"name":"datatables","version":"1.10.7","src":{"file":"/home/plintilhac/R/x86_64-pc-linux-gnu-library/3.2/DT/htmlwidgets/lib/datatables/js","href":"datatables-1.10.7"},"meta":null,"script":"jquery.dataTables.min.js","stylesheet":null,"head":null,"attachment":null},{"name":"datatables-default","version":"1.10.7","src":{"file":"/home/plintilhac/R/x86_64-pc-linux-gnu-library/3.2/DT/htmlwidgets/lib/datatables/css/default","href":"datatables-default-1.10.7"},"meta":null,"script":[],"stylesheet":["dataTables.extra.css","jquery.dataTables.min.css"],"head":null,"attachment":null}]},"plot1":{"src":"data:image/png;[base64
data]","width":873,"height":400,"coordmap":[{"domain":{"left":-1.08,"right":1.08,"bottom":-1.08,"top":1.08},"range":{"left":58.9093125,"right":842.8269375,"bottom":325.745454545455,"top":57.8909090909091},"log":{"x":null,"y":null},"mapping":{}}]}},"inputMessages":[]}
RECV
{"method":"update","data":{"table_rows_selected":[],"table_rows_current":[],"table_rows_all":[],"table_state":null,"table_search":"","table_cell_clicked":{}}}
SEND {"progress":{"type":"binding","message":{"id":"plot1"}}} SEND
{"errors":[],"values":{"plot1":{"src":"data:image/png;[base64
data]","width":873,"height":400,"coordmap":[{"domain":{"left":-1.08,"right":1.08,"bottom":-1.08,"top":1.08},"range":{"left":58.9093125,"right":842.8269375,"bottom":325.745454545455,"top":57.8909090909091},"log":{"x":null,"y":null},"mapping":{}}]}},"inputMessages":[]}
RECV
{"method":"update","data":{"table_rows_current":[1,2,3,4,5,6],"table_rows_all":[1,2,3,4,5,6]}}
RECV {"method":"update","data":{"plot_click":null}} RECV
{"method":"update","data":{"table_cell_clicked":{"row":1,"col":2,"value":3.5},"table_rows_selected":[1],"table_row_last_clicked":1}}
SEND {"progress":{"type":"binding","message":{"id":"plot1"}}} SEND
{"errors":[],"values":{"plot1":{"src":"data:image/png;[base64
data]","width":873,"height":400,"coordmap":[{"domain":{"left":-1.08,"right":1.08,"bottom":-1.08,"top":1.08},"range":{"left":58.9093125,"right":842.8269375,"bottom":325.745454545455,"top":57.8909090909091},"log":{"x":null,"y":null},"mapping":{}}]}},"inputMessages":[]}
RECV {"method":"update","data":{"table_rows_selected":[]}}
while this is the output when it is run remotely with the erroneous line (note table_cell_clicked is not being received):
Loading required package: DBI
SEND {"errors":[],"values":{"table":{"x":{"container":"<table class=\"display\">\n <thead>\n <tr>\n <th> </th>\n <th>Sepal.Length</th>\n <th>Sepal.Width</th>\n <th>Petal.Length</th>\n <th>Petal.Width</th>\n <th>Species</th>\n </tr>\n </thead>\n</table>","options":{"target":"cell","selectize":true,"columnDefs":[{"className":"dt-right","targets":[1,2,3,4]},{"orderable":false,"targets":0}],"order":[],"autoWidth":false,"orderClasses":false,"ajax":{"url":"session/07190712bb533d7cf1929522b19e436a/dataobj/table?w=","type":"POST","data":"function(d) {\nd.search.caseInsensitive = true;\nd.escape = true;\n}"},"serverSide":true,"processing":true},"callback":null,"filter":"none","selection":"multiple"},"evals":["options.ajax.data"],"deps":[{"name":"datatables","version":"1.10.7","src":{"file":"/usr/local/lib/R/site-library/DT/htmlwidgets/lib/datatables/js","href":"datatables-1.10.7"},"meta":null,"script":"jquery.dataTables.min.js","stylesheet":null,"head":null,"attachment":null},{"name":"datatables-default","version":"1.10.7","src":{"file":"/usr/local/lib/R/site-library/DT/htmlwidgets/lib/datatables/css/default","href":"datatables-default-1.10.7"},"meta":null,"script":[],"stylesheet":["dataTables.extra.css","jquery.dataTables.min.css"],"head":null,"attachment":null}]},"plot1":{"src":"data:image/png;[base64 data]","width":1745,"height":400,"coordmap":[{"domain":{"left":-1.08,"right":1.08,"bottom":-1.08,"top":1.08},"range":{"left":58.9062532569046,"right":1714.82850442939,"bottom":325.745454545455,"top":57.8909090909091},"log":{"x":null,"y":null},"mapping":{}}]}},"inputMessages":[]}
RECV {"method":"update","data":{"table_rows_selected":[],"table_rows_current":[],"table_rows_all":[],"table_state":null,"table_search":""}}
RECV {"method":"update","data":{"table_rows_current":["1","2","3","4","5","6"],"table_rows_all":["1","2","3","4","5","6"]}}
RECV {"method":"update","data":{"table_rows_selected":["3"],"table_row_last_clicked":"3"}}
RECV {"method":"update","data":{".clientdata_output_plot1_width":463}}
SEND {"progress":{"type":"binding","message":{"id":"plot1"}}}
SEND {"errors":[],"values":{"plot1":{"src":"data:image/png;[base64 data]","width":463,"height":400,"coordmap":[{"domain":{"left":-1.08,"right":1.08,"bottom":-1.08,"top":1.08},"range":{"left":58.9256188605108,"right":432.81858546169,"bottom":325.745454545455,"top":57.8909090909091},"log":{"x":null,"y":null},"mapping":{}}]}},"inputMessages":[]}
RECV {"method":"update","data":{"plot_click":null}}
SEND {"config":{"workerId":"","sessionId":"7b20c500ee810e198324a75b6512a353"}}
RECV {"method":"init","data":{"refreshButton:shiny.action":0,"ss-net-opt-websocket":true,"ss-net-opt-xdr-streaming":true,"ss-net-opt-xhr-streaming":true,"ss-net-opt-iframe-eventsource":true,"ss-net-opt-iframe-htmlfile":true,"ss-net-opt-xdr-polling":true,"ss-net-opt-xhr-polling":true,"ss-net-opt-iframe-xhr-polling":true,"ss-net-opt-jsonp-polling":true,".clientdata_output_plot1_width":463,".clientdata_output_plot1_height":400,".clientdata_output_plot1_hidden":false,".clientdata_output_table_hidden":false,".clientdata_pixelratio":1.100000023841858,".clientdata_url_protocol":"http:",".clientdata_url_hostname":"d2rm01",".clientdata_url_port":"3838",".clientdata_url_pathname":"/testFunnel/",".clientdata_url_search":"",".clientdata_url_hash_initial":"",".clientdata_singletons":"",".clientdata_allowDataUriScheme":true}}
Error in source(file, ..., keep.source = TRUE, encoding = checkEncoding(file)) :
/srv/shiny-server/testFunnel/server.R:38:10: unexpected ','
37: #print(paste0("timestamp: ",Sys.time()))
38: (cell,

AWS multipart upload from inputStream has bad offfset

I am using the Java Amazon AWS SDK to perform some multipart uploads from HDFS to S3. My code is the following:
for (int i = startingPart; currentFilePosition < contentLength ; i++)
{
FSDataInputStream inputStream = fs.open(new Path(hdfsFullPath));
// Last part can be less than 5 MB. Adjust part size.
partSize = Math.min(partSize, (contentLength - currentFilePosition));
// Create request to upload a part.
UploadPartRequest uploadRequest = new UploadPartRequest()
.withBucketName(bucket).withKey(s3Name)
.withUploadId(currentUploadId)
.withPartNumber(i)
.withFileOffset(currentFilePosition)
.withInputStream(inputStream)
.withPartSize(partSize);
// Upload part and add response to our list.
partETags.add(s3Client.uploadPart(uploadRequest).getPartETag());
currentFilePosition += partSize;
inputStream.close();
lastFilePosition = currentFilePosition;
}
However, the uploaded file is not the same as the original one. More specifically, I am testing on a test file, which has about 20 MB. The parts I upload are 5 MB each. At the end of each 5MB part, I see some extra text, which is always 96 characters long.
Even stranger, if I add something stupid to .withFileOffset(), for example,
.withFileOffset(currentFilePosition-34)
the error stays the same. I was expecting to get other characters, but I am getting the EXACT 96 extra characters as if I hadn't modified the line.
Any ideas what might be wrong?
Thanks,
Serban

I figured it out. This came from a stupid assumption on my part. It turns out, the file offset in ".withFileOffset(...)" tells you the offset where to write in the destination file. It doesn't say anything about the source. By opening and closing the stream repeatedly, I am always writing from the beginning of the file, but to a different offset. The solution is to add a seek statement after opening the stream:
FSDataInputStream inputStream = fs.open(new Path(hdfsFullPath));
inputStream.seek(currentFilePosition);

Sending an object to a client computer after connection made

I have a program that currently works as a chat server. It's a turn based card game with a chat box to communicate with the opponent. The chat stuff all works over the connection, but I'm to the point where I need to start sending certain cards to the opponent, so that when I play a card, my opponent will see it on his screen. I want the client computer to receive the object or collection of objects, figure out what the card type is based on its properties, and then put the card in the correct location. The sending and receiving part is what I don't understand how to accomplish. From what I've read, this requires serialization and I just don't know where to begin with this. Please assist! I'm using visual studio.

Answering my own question again... I ended up creating a new class called card container which contains the cardType as a string and the card id as a int. There are also other properties for the card container so I know where the card goes. Then I serialized the card container (which is 'cc' in the following code) and sent it as follows:
Dim cc as new CardContainer
cc.id = card.id
cc.cardType = card.GetType.ToString
cc.discard = true
Dim bf As New BinaryFormatter
Dim ms As New MemoryStream
Dim b() As Byte
'serializes to the created memory stream
bf.Serialize(ms, cc)
'converts the memory stream to the byte array
b = ms.ToArray()
ms.Close()
'sends the byte array to client or host
SyncLock mobjClient.GetStream
mobjClient.GetStream.Write(b, 0, b.Length)
End SyncLock
The client listens on its TCPClient for anything at all and picks up the card with the following code:
Dim intCount As Integer
Try
SyncLock mobjClient.GetStream
'returns the number of bytes to know how many to read
intCount = mobjClient.GetStream.EndRead(ar)
End SyncLock
'if no bytes then we are disconnected
If intCount < 1 Then
MarkAsDisconnected()
Exit Sub
End If
Dim bf As New BinaryFormatter
Dim cc As New CardContainer
'moves the byte array found in arData to the memory stream
Dim ms As New MemoryStream(arData)
'cuts off the byte array in the memory stream after all the received data
ms.SetLength(intCount)
'the new cardContainer will now be just like the sent one
cc = bf.Deserialize(ms)
ms.Close()
'starts the listener again
mobjClient.GetStream.BeginRead(arData, 0, 3145728, AddressOf DoRead, Nothing)
Depending on what data the cardcontainer has determines which method the client now calls. For example, when this is received, the created cc is passed to my CardReceived method which then has a bunch of if, elseif statements. One of those would be
ElseIf cc.discard = true then
'makes a new card from the id and cardType properties
dim temp as new object = MakeCard
'discard method will find the correct card in the Host's known hand and discard it to the correct pile
Discard(temp)

MQ window to Unix special chars

I am using .net client to post mesages to MQ server which is hosted on Unix. It is added some control character before the messages. Like below
**^CD**<request>
The Queue connection is through SSL Table channel connection.
The code i am using is
MQQueueManager queueManager = new MQQueueManager ;
int openOptions = MQC.MQOO_OUTPUT + MQC.MQOO_BIND_NOT_FIXED + MQC.MQOO_FAIL_IF_QUIESCING;
MQQueue Queue = queueManager.AccessQueue("TestQueue", openOptions);
MQMessage queueMessage = new MQMessage();
queueMessage.WriteUTF("<request>");
MQPutMessageOptions MessageOptions = new MQPutMessageOptions();
Queue.Put(queueMessage, MessageOptions);
please let me know what cause this special chars

From IBM's own doco on WriteUTF:
This method takes an ActiveX string and writes it into the message data buffer at the current position in UTF format. The data written consists of a 2-byte length followed by the character data. DataOffset is incremented by the length of the string if the method succeeds.
If you don't want that length, consider using WriteString instead (follow that doco link above and just go up a couple of lines in the navigation pane)..

Resources