UDP packet does not arrive - networking

I'm not sure if this is the right place to ask this question. If not, i will remove it...
Anyway, i have made driver for enc28j60 for LPC1788 and I'm trying to send UDP message to it from iOS. Sending fails.
Communication starts by iOS sending the ARP request. On LPC i make response and send it to iOS MAC address. I have read RFC for ARP and created packet by the specification, but for some reason i dont see the response in network sniffer.
That would for sure indicate that my response routine does not work, if there was not this case when i send udp message from OSX (nc -u xxx.xxx.xxx.xxx port) that comes correctly to LPC.
The difference that i observed is that OSX sends the request which is 42bytes long and gets 60bytes long response with last 18bytes of 0's (padding bytes), and iOS sends the 60byte long request with last 4bytes as 90 eb 58 96.
I tried to respond with all padding zeros, and with copying those 4 bytes, but neither approach worked.
OSX ARP(req, res) and UDP package is visible in sniffer.
iOS ARP req is visible in sniffer and nothing else.
Any idea ?
EDIT:
IOS code:
CFSocketRef sock = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_DGRAM, IPPROTO_UDP, 0, NULL, NULL);
if ( sock == NULL) {
NSLog(#"CfSocketCreate Failed");
}else{
struct sockaddr_in remoteAddress;
memset(&remoteAddress, 0, sizeof(remoteAddress));
remoteAddress.sin_family = AF_INET;
remoteAddress.sin_len = sizeof(remoteAddress);
remoteAddress.sin_port = htons(1200);
remoteAddress.sin_addr.s_addr = inet_addr("192.168.5.8");
char data[] = "test";
NSData *message_data = [NSData dataWithBytes:&data length:4];
NSData* remoteAddressData = [NSData dataWithBytes:&remoteAddress length:sizeof(remoteAddress)];
CFSocketError er = CFSocketSendData(sock, (__bridge CFDataRef)(remoteAddressData), (__bridge CFDataRef)message_data, 0);
}
LPC code:
void make_arp_response (uint8_t *buffer)
{
uint16_t pos = sizeof (ethernet.source)+sizeof (ethernet.dest);
uint8_t type[2];
type[0] = ARP_TYPE>>8;
type[1] = (uint8_t)ARP_TYPE;
memcpy (buffer+pos, &type, sizeof (ethernet.type)); pos = sizeof(ethernet); //set ethernet type
arp.hwType = ((0x01)<<8);
memcpy (buffer+pos, &arp.hwType, sizeof (arp.hwType)); pos += sizeof(arp.hwType);
arp.protocol[0] = 0x08;
arp.protocol[1] = 0x00;
memcpy (buffer+pos, &arp.protocol, sizeof (arp.protocol)); pos += sizeof(arp.protocol);
memcpy (buffer+pos, &arp.macLen, sizeof (arp.macLen)); pos += sizeof(arp.macLen);
memcpy (buffer+pos, &arp.ipLen, sizeof (arp.ipLen)); pos += sizeof(arp.ipLen);
arp.opCode = (0x02) << 8;
memcpy (buffer+pos, &arp.opCode, sizeof (arp.opCode)); pos += sizeof(arp.opCode);
memcpy (buffer+pos, &macaddr, sizeof (arp.sourceMac)); pos += sizeof(arp.sourceMac);
memcpy (buffer+pos, &arp.destIP, sizeof (arp.sourceIp)); pos += sizeof(arp.sourceIp);
memcpy (buffer+pos, &arp.sourceMac, sizeof (arp.destMac)); pos += sizeof(arp.destMac);
memcpy (buffer+pos, &arp.sourceIp, sizeof (arp.destIP));
enc28j60_PacketSend(sizeof (ethernet)+sizeof (arp),buf);
}
UPDATE:
It seems that this is not just an iOS problem, but problem with Wifi clients. I have tried to send UDP from windows laptop over wifi and it also sends the ARP request but response and UDP packet got lost somehow. It seems that my ruter have some problems with my LPC :)
I have also tried to connect Arduino to the same enc28j60 board instead of LPC, and UDP communication works.
Library for arduino is found somewhere on the NET. ARP response in arduino code looks the same to me.
UPDATE 2:
Arp request:
ff ff ff ff ff ff 85 29 fb 0d c2 71 08 06 00 01
08 00 06 04 00 01 85 29 fb 0d c2 71 c0 a8 05 28
00 00 00 00 00 00 c0 a8 05 08 00 00 00 00 00 00
00 00 00 00 00 00 00 00 25 a9 c3
Arp response:
85 29 fb 0d c2 71 7b c3 53 a6 9c 55 08 06 00 01
08 00 06 04 00 02 7b c3 53 a6 9c 55 c0 a8 05 08
85 29 fb 0d c2 71 c0 a8 05 28
This response is dumped from LPC just after sending it on wire. I didnt saw it in sniffer.

Related

SkCanvas throws when drawing from a task

A call to draw picture from an awaited task, will crash my app.
A regular non awaited call will not crash but will not draw my svg.
public static Task DrawSVGOnCanvas(SKCanvas canvas, string assemblyName, string svgFileName, SKRect sizeRect, SKPaint paint)
{
return Task.Run(async () =>
{
try
{
Stream stream = await GetImageStream(svgFileName, assemblyName, null);
if (stream == null)
{
return;
}
stream.Position = 0;
SKSvg.SKSvg svg = new SKSvg.SKSvg();
svg.Load(stream);
SKMatrix scaleMatrix = GetScaleMatrix(svg.Picture, sizeRect);
canvas.DrawPicture(svg.Picture, ref scaleMatrix, paint);
}
catch (Exception ex)
{
_logService.HandleException(ex);
}
});
}
I was trying to call this async method so I could get the stream for the svg file without locking the ui thread.
Has anyone encountered this, or tried to implement something similiar using skiasharp for svg?
Update 1:
The stacktrace for the crash:
=================================================================
Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
No native Android stacktrace (see debuggerd output).
=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x8d04084e):0x8d04083e 10 98
00 78 00 28 13 d1 15 b0 bd e8 00 0f f0 bd ...x.(..........
0x8d04084e d9 f8 00 00 59 46 2a 46 43 46 d0 f8 c4 60 48 46 ....YF*FCF...`HF
0x8d04085e b0 47 0e 98 00 28 1e bf 10 98 00 78 00 28 eb d0 .G...(.....x.(..
0x8d04086e 8a f0 cf fb 03 68 10 ae 46 ce 5b 69 13 9d cd e9 .....h..F.[i....
=================================================================
Managed Stacktrace:
=================================================================
at <unknown> <0xffffffff>
at SkiaSharp.SkiaApi:sk_canvas_draw_picture <0x00043>
at SkiaSharp.SKCanvas:DrawPicture <0x001fb>
at <>c__DisplayClass27_1:<DrawSVGOnCanvas>b__1 <0x000f3>
at RunnableImplementor:Run <0x000c3>
at Java.Lang.IRunnableInvoker:n_Run <0x000bf>
at Android.Runtime.DynamicMethodNameCounter:28 <0x000eb>
at Android.Runtime.DynamicMethodNameCounter:28 <0x000db>
=================================================================
06-08 16:54:05.532 F/libc ( 8842): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 8842 (UI)
If I am trying to await the call instead of letting it run unawaited I get the following:
=================================================================
Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
No native Android stacktrace (see debuggerd output).
=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x8d65084e):
0x8d65083e
10
98
00
78
00 28 13 d1
15 b0 bd e8 00 0f f0 bd ...x.(........
..
0x8d65084e d9 f8 00 00 59 46 2a 46 43 46 d0 f8 c4 60 48
46 ..
.
.YF*FCF...`HF
0x8d65085e b0 47 0e 98 00 28 1e bf 10 98 00 78 00 28 eb
d0 .G..
.(.....
x.(..
0x8d65086e 8a f0 cf fb 03 68 10 ae 46 ce 5b
69 13 9d cd e9 .....h..F.[i..
..
=================================================================
Managed Stacktrace:
=================================================================
at <unknown> <0xffffffff>
at SkiaSharp.SkiaApi:sk_canvas_draw_picture <0x00043>
at SkiaSharp.SKCanvas:DrawPicture <0x001fb>
at <<DrawSVGOnCanvas>b__0>d:MoveNext <0x00823>
at MoveNextRunner:InvokeMoveNext <0x000d7>
at System.Threading.ExecutionContext:RunInternal <0x0040b>
at System.Threading.ExecutionContext:Run <0x00073>
at MoveNextRunner:Run <0x0018f>
at System.Threading.Tasks.AwaitTaskContinuation:RunOrScheduleAction <0x00183>
at System.Threading.Tasks.Task:FinishContinuations <0x0032b>
at System.Threading.Tasks.Task:FinishStageThree <0x00153>
at System.Threading.Tasks.Task`1:TrySetResult <0x0020f>
at System.Threading.Tasks.UnwrapPromise`1:TrySetFromTask <0x00553>
at System.Threading.Tasks.UnwrapPromise`1:InvokeCore <0x000db>
at System.Threading.Tasks.UnwrapPromise`1:Invoke <0x000e3>
at System.Threading.Tasks.Task:FinishContinuations <0x004c7>
at System.Threading.Tasks.Task:FinishStageThree <0x00153>
at System.Threading.Tasks.Task`1:TrySetResult <0x0020f>
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:SetResult <0x00223>
at <<GetImageStream>b__0>d:MoveNext <0x01637>
at MoveNextRunner:InvokeMoveNext <0x000d7>
at System.Threading.ExecutionContext:RunInternal <0x0040b>
at System.Threading.ExecutionContext:Run <0x00073>
at MoveNextRunner:Run <0x0018f>
at System.Threading.Tasks.AwaitTaskContinuation:RunOrScheduleAction <0x00183>
at System.Threading.Tasks.Task:FinishContinuations <0x0032b>
at System.Threading.Tasks.Task:FinishStageThree <0x00153>
at System.Threading.Tasks.Task`1:TrySetResult <0x0020f>
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1:SetResult <0x00223>
at <GetObject>d__17`1:MoveNext <0x0077b>
at MoveNextRunner:InvokeMoveNext <0x000d7>
at System.Threading.ExecutionContext:RunInternal <0x0040b>
at System.Threading.ExecutionContext:Run <0x00073>
at MoveNextRunner:Run <0x0018f>
at System.Threading.Tasks.AwaitTaskContinuation:RunOrScheduleAction <0x00183>
at System.Threading.Tasks.Task:FinishContinuations <0x0032b>
at System.Threading.Tasks.Task:FinishStageThree <0x00153>
at System.Threading.Tasks.Task:FinishStageTwo <0x003bb>
at System.Threading.Tasks.Task:Finish <0x001c3>
at System.Threading.Tasks.Task:ExecuteWithThreadLocal <0x002cb>
at System.Threading.Tasks.Task:ExecuteEntry <0x001d7>
at System.Threading.Tasks.Task:System.Threading.IThreadPoolWorkItem.ExecuteWorkItem <0x0005f>
at System.Threading.ThreadPoolWorkQueue:Dispatch <0x00507>
at System.Threading._ThreadPoolWaitCallback:PerformWaitCallback <0x0007f>
at <Module>:runtime_invoke_bool <0x000bb>
=================================================================
06-08 16:50:38.262 F/libc ( 8383): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 8439 (Thread Pool Wor)
This is most likely a result of drawing to the screen from a view, but in the background?
You cannot draw to the screen from a background task or even any task. The on-screen canvas most often only lives as long as the PaintSurface event is executing. This is because the OS is no longer doing the drawing and has moved on.
The paint events are always blocking. If you need to draw in the background, you must create a new surface and draw on that. Then you can draw that surface to the screen when it is done. To do this, trigger a refresh and then draw it.
You ssould never keep references to the surface or canvas that was provided by the view. This may be destroyed and recreated at any time.

react, fetch, multer file corrupted on upload

I am uploading a file using whatwg-fetch
When I am sending the file to the server everything seems to works without problem, I have the following headers
Content-Length: 6941
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryUZ3MAI9SPh2fjdl3
And the code
export function addImage(image, name) {
return (dispatch, getState) => {
const { user } = getState();
let data = new FormData();
data.append('image', image);
data.append('name', name);
return fetch(generateUrl(`/image?token=${user.token}`), {
method: 'POST',
body: data
})
.then(response => {
return response.json()
.then(json => {
if (!response.ok) return console.error(json);
dispatch(getImages())
});
})
}
}
Then I am receiving the code on the server
router.post('/', securityController.middleware('post_image'), multer().single('image'), (req, res, next) => {
fs.writeFileSync('test.jpeg', req.file.buffer)
imageDataProvider.addImage(req.body.name, req.file)
.then(image => res.json(image))
.catch(next)
})
I have two tests there, one is uploading to s3 and the other one is writing it into test.jpeg
But the uploaded image is corrupted, this is the image I am receiving
{ fieldname: 'image',
originalname: 'download.jpeg',
encoding: '7bit',
mimetype: 'image/jpeg',
buffer:
<Buffer c3 bf c3 98 c3 bf c3 a0 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 c3 bf c3 9b 00 c2 84 00 09 06 07 12 12 10 15 0f 10 10 15 10 0f 0f 0f 0f 10 0f ... >,
size: 9783 }
I do not understand why the size is different. The image is corrupted on both s3 and local storage
The server is a serverless (I am havinf the same issue running with serverless offline or directly on lambda)
JPEG files are starting with hex
FF D8 FF E0 00 10 4A 46 49 46 00
it seems, that your "buffer"-string was converted from ISO-8859-1 to UTF-8, because:
FF (ISO-1) = C3 BF (UTF-8)
D8 (ISO-1) = C3 98 (UTF-8)
FF (ISO-1) = C3 BF (UTF-8)
E0 (ISO-1) = C3 A0 (UTF-8)
that's the reason why the size is now different and the jpeg file is corrupted.
disable the CharacterSet converting to UTF-8 (use original binary data)

Is there Zlib for R ? raw inflate function - how to decompress hexadecimal values

I need to decompress hex values and convert those to string.
Actual problem is that i'm not able to figure out how to decompress hex values
Hex do not contain any headers,
If i copy hex codes to CyberChef i'm able to decompress those and have original string
In CyberChef only Raw Inflate operation is needed
So i'm hoping help how to do raw inflate in R
I have tried memDecompress using all options without success (i.e gzip etc)
UPDATE:
Here is a sample from hex:
e3 0e 71 0d 0e f1 54 c8 cb 2f 52 30 02 00
which i'm able to convert using CyberChef to string
".TESTI nor 2"
RLdata<- sqlQuery(connection, ..... AS Varbinary(max) AS NOTEShort ......
> RLdata$NOTEshort[4268]
[[1]]
[1] e3 0e 71 0d 0e f1 54 c8 cb 2f 52 30 02 00
> unlist(RLdata$NOTEshort[4268])
[1] e3 0e 71 0d 0e f1 54 c8 cb 2f 52 30 02 00
> memDecompress(unlist(RLdata$NOTEshort[4268]),type = "gzip", asChar = TRUE)
Error in memDecompress(unlist(RLdata$NOTEshort[4268]), type = "gzip", :
internal error -3 in memDecompress(2)
> memDecompress(unlist(RLdata$NOTEshort[4268]),type = "unknown", asChar = TRUE)
[1] "ã\016q\r\016ñTÈË/R0\002"
Warning message:
In memDecompress(unlist(RLdata$NOTEshort[4268]), type = "unknown", :
unknown compression, assuming none
If you convert it into Base64 and then decode it back to Hex I think it decompresses to original, but may have been changed by a bug fix. It used to do this a couple of years back but I haven't used CyberChef in a while, sorry
Had to do this using python3. Zlib.decompress() did the trick.
Link to python solution
Read Dynamics NAV Table Metadata with SQL

Fatal Error when calling showSaveDialog() and showOpenMultipleDialog()

The JVM is crashing when I run these two lines:
javafx.stage.FileChooser fileChooser = new FileChooser();
File targetFile = fileChooser.showSaveDialog( mainStage );
I am on Ubuntu 16.10, OpenJDK 8 64bit:
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-0ubuntu1.16.10.2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
Kernel version:
Linux Joshua-PC 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I tried the solution outlined here with no success: https://stackoverflow.com/a/34612376/61248
Here is the top of the error log:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8573f34e40, pid=19801, tid=0x00007f850d733700
#
# JRE version: OpenJDK Runtime Environment (8.0_131-b11) (build 1.8.0_131-8u131-b11-0ubuntu1.16.10.2-b11)
# Java VM: OpenJDK 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpthread.so.0+0x9e40] pthread_mutex_lock+0x0
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00007f856c325800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=19824, stack(0x00007f850d633000,0x00007f850d734000)]
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000006e6f84
Registers:
RAX=0x00007f8573f34e40, RBX=0x00007f856c2e1730, RCX=0x000000000000014c, RDX=0x00007f850d72b8b0
RSP=0x00007f850d72b828, RBP=0x00007f850d72b890, RSI=0x00007f850d72b8a0, RDI=0x00000000006e6f74
R8 =0x00007f850d72b890, R9 =0x00007f856c2919fd, R10=0x00007f854dd43387, R11=0x0000000000000065
R12=0x00007f850d72b88c, R13=0x0000000000000000, R14=0x00007f85007b27c8, R15=0x00007f850d72ce20
RIP=0x00007f8573f34e40, EFLAGS=0x0000000000010202, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f850d72b828)
0x00007f850d72b828: 00007f854dcd8bda 00007f850d72b8a0
0x00007f850d72b838: 00007f850d72b8b0 00007f851358d510
0x00007f850d72b848: 00007f856c29c720 00007f8518f02cc1
0x00007f850d72b858: 7b2d1296d82fd300 00007f856c29c720
0x00007f850d72b868: 00007f8518f02cc1 00007f8518f04494
0x00007f850d72b878: 00007f854dcb4f56 0000000000000003
0x00007f850d72b888: 00007f850d72b930 00007f8500883400
0x00007f850d72b898: 0000000000004d70 0000014e0000014c
0x00007f850d72b8a8: 00007f8500000000 0000015700000156
0x00007f850d72b8b8: 00007f8500000000 0000000000000000
0x00007f850d72b8c8: 7b2d1296d82fd300 00007f8500882a50
0x00007f850d72b8d8: 00007f8500882a84 00007f856c29c720
0x00007f850d72b8e8: 00007f8518ebd79f 0000000000000000
0x00007f850d72b8f8: 00007f854c3e2078 00007f8500883400
0x00007f850d72b908: 7b2d1296d82fd300 00007f850d72b9ec
0x00007f850d72b918: 00007f8500883fa8 00007f850d72b980
0x00007f850d72b928: 00007f8500883fa8 0000000000000000
0x00007f850d72b938: 00007f85007b27c8 00007f850d72ce20
0x00007f850d72b948: 00007f8518ebfcc0 00007f8500883e80
0x00007f850d72b958: 00007f8518e91487 00007f85007b27c8
0x00007f850d72b968: 00007f850087d250 00007f850d72b9a0
0x00007f850d72b978: 00007f8518e4fd1f 00007f850d72ba00
0x00007f850d72b988: 00007f850d72b9f0 00007f850d72b9e0
0x00007f850d72b998: 00007f84c40127b0 00007f84c4012870
0x00007f850d72b9a8: 00007f854c3e3557 0000000000000000
0x00007f850d72b9b8: 0000000000000000 0000000100000001
0x00007f850d72b9c8: 0000000c0000000c 0000000000000000
0x00007f850d72b9d8: 7b2d1296d82fd300 00007f85007b2600
0x00007f850d72b9e8: 00007f850087d250 0000000000000006
0x00007f850d72b9f8: 00007f8518e52e93 0000000000000000
0x00007f850d72ba08: 000001cc0000000c 0000000000000001
0x00007f850d72ba18: 00000006d82fd300 000000004000000c
Instructions: (pc=0x00007f8573f34e40)
0x00007f8573f34e20: 89 0c 25 e0 02 00 00 64 48 c7 04 25 f0 02 00 00
0x00007f8573f34e30: 00 00 00 00 b8 82 00 00 00 e9 e0 f9 ff ff 66 90
0x00007f8573f34e40: 8b 57 10 89 d1 81 e1 7f 01 00 00 90 89 d0 83 e0
0x00007f8573f34e50: 7c 0f 85 99 00 00 00 48 83 ec 08 85 c9 49 89 f8
Register to memory mapping:
RAX=0x00007f8573f34e40: pthread_mutex_lock+0 in /lib/x86_64-linux-gnu/libpthread.so.0 at 0x00007f8573f2b000
RBX=0x00007f856c2e1730 is an unknown value
RCX=0x000000000000014c is an unknown value
RDX=0x00007f850d72b8b0 is pointing into the stack for thread: 0x00007f856c325800
RSP=0x00007f850d72b828 is pointing into the stack for thread: 0x00007f856c325800
RBP=0x00007f850d72b890 is pointing into the stack for thread: 0x00007f856c325800
RSI=0x00007f850d72b8a0 is pointing into the stack for thread: 0x00007f856c325800
RDI=0x00000000006e6f74 is an unknown value
R8 =0x00007f850d72b890 is pointing into the stack for thread: 0x00007f856c325800
R9 =0x00007f856c2919fd is an unknown value
R10=0x00007f854dd43387: <offset 0xb0387> in /usr/lib/x86_64-linux-gnu/libX11.so.6 at 0x00007f854dc93000
R11=0x0000000000000065 is an unknown value
R12=0x00007f850d72b88c is pointing into the stack for thread: 0x00007f856c325800
R13=0x0000000000000000 is an unknown value
R14=0x00007f85007b27c8 is an unknown value
R15=0x00007f850d72ce20 is pointing into the stack for thread: 0x00007f856c325800
Stack: [0x00007f850d633000,0x00007f850d734000], sp=0x00007f850d72b828, free space=994k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libpthread.so.0+0x9e40] pthread_mutex_lock+0x0
C 0x0000000000004d70
Full error log here: http://hypnosplayer.org/misc/save-as-error.log
This was being caused by the use of an external library JNativeHook for global hotkeys, particularly this line:
GlobalScreen.registerNativeHook();
and this line:
GlobalScreen.addNativeKeyListener( globalHotkeyListener );
I don't understand why this caused the problem, but removing both of these calls solves the issue. I suppose I'll have to look for a different global hotkey library.
I spoke with the library developer. He reviewed the crash and said it doesn't happen in the library direct, and he indicated that the problem may be with "xcb" and linux. He recommended using an earlier version of the library (v2.0.2 rather than v2.1.0) and that resolved the issue.
Is this reproducible?
The instruction stream looks like this:
0: 89 0c 25 e0 02 00 00 mov %ecx,0x2e0
7: 64 48 c7 04 25 f0 02 movq $0x0,%fs:0x2f0
e: 00 00 00 00 00 00
14: b8 82 00 00 00 mov $0x82,%eax
19: e9 e0 f9 ff ff jmpq 0xfffffffffffff9fe
1e: 66 90 xchg %ax,%ax
This is from the end of the __pthread_mutex_lock_full function in libpthread. The first instruction faults because it attempts to write to the absolute address 0x2e0, which is not mapped. This instruction is the tail of a proper instruction, which writes to the TCB via the %fs register override:
993a: 64 48 89 04 25 e0 02 mov %rax,%fs:0x2e0
9941: 00 00
It's not a simple stray function pointer call, either, because the JVM reports that the faulting instruction is at pthread_mutex_lock+0, i.e., the proper start of the function. So it looks like that the JVM/dynamic linker's view of libpthread are slightly off (shifted by 32 bytes, actually).
EDIT As this is perfectly reproducible, it is not a file rewrite of libpthread.so.0, as I originally suspected. It is likely some sort of memory corruption which flips a bit in a function pointer. If -Xcheck:jni does not provide any hints, this needs an extending debugging session with GDB to identify the root cause (running the JVM under valgrind probably has too many false positives).

Getting an error while trying to send SS command using USAT application

I'm trying to have a USIM perform call forwarding (a.k.a call redirection) using the proactive command SEND SS (TS 31.111 sections: 6.4.11, 8.14, etc.). Unfortunately I keep getting an error from the network which I can't understand.
I'm trying the following sequence:
ME->USIM: 8012000018 (FETCH from the ME toward UICC)
USIM->ME: 12 (procedure byte)
USIM->ME: D01681030411008202818305000909FFAA120A25556777B49000
D0 (proactive command) 16 (length)
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
82 (device identities) 02 (length) 81 (UICC) 83 (network)
05 (alpha identifier) 00 (length)
909FFAA120A25556777B4 (SS String = **21*0525576774#)
9000 (OK)
ME->USIM: 801400000D (Terminal response of size 0x0D)
USIM->ME: 14 (procedure byte)
ME->USIM: 81030411000202828103023424
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
03 (Result) 02 (length) 34 (SS Return Error) 24 (???)
I can't figure out what '24' means.
Just to make sure I'm using a correct SS string, I activated CALL CONTROL on the USIM and dialed **21*0525576774# in the keypad. The result was as follows:
ME->UICC: 80C200001C (Envelope of length 0x1C)
UICC->ME: C2 (procedure byte)
ME->UICC: D41A020282810909FFAA120A25556777B4130924F51027D078CF0013
D4 (envelope) 1A (length)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
09 (send ss) 09 (length) FFAA120A25556777B4 (SS string)
13 (location information) 09 (length) 24F51027D078CF0013 (not relevant)
USIM->ME: 9000 (OK)
As you can see, the SS string is identical. When the ME sends it it seems to work (call forwarding is activated) yet when I try to send it from the UICC to the network I get the error '3424'.
I've searched through the specs (TS 31.111, TS 22.030 and even TS 24.080) but didn't find even the tiniest lead as to what I'm doing wrong.
Any help will be appreciated :)
Cheers,
Nir.
I think the problem occurs due to timer management(Action in contradiction with the current timer state) becouse
0x34-> Means SS Return Error
0x24-> Means Action in contradiction with the current timer state.

Resources