If I have the IOR available, is it possible to form the corbaloc from it?
Are there any tools that can do it automatically.
(I am using JacORB 3.5)
IOR is the way that you can access the host. In CORBA we use IOR instead of a readable host:port. I think that CORBA JDK has a IORInterpreter or IORReader, but Jacorb don't have it.
Why doesn't JacORB use host names in it's IOR?
The reason we're using IP numbers instead of human readable host names is that the jdk doesn't provide a way (unless implementing the DNS protocol ourselves / using an external library) to get the fully qualified hostname (that is e.g. z1.inf.fu-berlin.de instead of just z1). But using only the unqualified hostname renders the IOR useless outside of the domain.
from: JacORB's FAQ
If you still want a host:port to connect, you can use:
//Server
java.util.Properties props = new java.util.Properties();
props.setProperty("OAIAddr","myMachine");
props.setProperty("OAPort","3555");
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, props)
//Client
org.omg.CORBA.Object obj = orb.string_to_object("corbaloc:iiop:myMachine:3555/MyServant");
MyServant goodDay = MyServantHelper.narrow( obj );
If you obtain the IOR string, you could convert it to corbaloc format. One example as below:
Input: IOR String:
IOR:000000000000001949444C3A4D6F6E65792F4163636F756E74616E743A312E300000000000000001000000000000007C000102000000000D3139322E3136382E35362E31000022B8000000285374616E64617264496D706C4E616D652F4D6E7124242F5F4D6F6E65795F4163636F756E74616E74000000020000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001
Then you could use one tool (e.g. UCS Tools , or you could use the dior.bat tools provided by jacorb) to parse this string, the result is shown as below:
Parse IOR Output:
------IOR components-----
TypeId : IDL:Money/Accountant:1.0
TAG_INTERNET_IOP Profiles:
Profile Id: 0
IIOP Version: 1.2
Host: 192.168.56.1
Port: 8888
Object key (URL): StandardImplName/Mnq$$/_Money_Accountant
Object key (hex): 0x53 74 61 6E 64 61 72 64 49 6D 70 6C 4E 61 6D 65 2F 4D 6E 71 24 24 2F 5F 4D 6F 6E 65 79 5F 41 63 63 6F 75 6E 74 61 6E 74
-- Found 2 Tagged Components--
#0: TAG_ORB_TYPE
Type: 1245790976 (JacORB)
#1: TAG_CODE_SETS
ForChar native code set Id: ISO8859_1
Char Conversion Code Sets: UTF8
ForWChar native code set Id: UTF16
WChar Conversion Code Sets: UTF8
Then, you could obtain the necessary info for corbaloc (e.g., IIOP version, host, port, Object key).
Then, you could produce the final corbaloc format:
corbaloc:iiop:1.2#192.168.56.1:8888/StandardImplName/Mnq$$/_Money_Accountant
You could use the JacORB internal API org.jacorb.orb.util.Corbaloc::generateCorbaloc (org.omg.CORBA.ORB, org.omg.CORBA.Object)
e.g.
corbaLoc = "corbaloc:" + CorbaLoc.generateCorbaloc(orb,xxx._this_object());
Related
I am capturing MQTT traffic for troubleshooting using below command
tcpdump -i team0 -w mqtt-trace.pcap src 10.x.x.x
But it results in very big file within minutes, Can i filter tcpdump on base of topic name
Following is tcp payload, I want it only capture payload which has PKGCTRL/1/status/frequency or if tcpdump can directly support filter on application layer protocol like wireshark mqtt.topic == PKGCTRL/1/status/frequency
0000 00 13 95 36 2e ef 00 10 7e 07 87 3d 08 00 45 00 ...6....~..=..E.
0010 00 77 2e 0d 40 00 40 06 f6 78 0a 0b 80 f3 0a 0b .w..#.#..x......
0020 80 f2 c3 6a 75 83 e4 f8 f7 7a 0a 89 67 76 50 18 ...ju....z..gvP.
0030 ea 60 59 f8 00 00 30 4d 00 1a 50 4b 47 43 54 52 .`Y...0M..PKGCTR
0040 4c 2f 31 2f 73 74 61 74 75 73 2f 66 72 65 71 75 L/1/status/frequ
0050 65 6e 63 79 0a 11 09 c2 7a 85 14 d0 71 37 16 12 ency....z...q7..
0060 06 08 01 10 01 18 00 12 1c 0a 0d 09 0b 46 25 75 .............F%u
0070 02 f2 48 40 10 21 18 00 11 00 60 76 14 d0 71 37 ..H#.!....`v..q7
0080 16 20 00 28 00 . .(.
I don't think the previously accepted answer necessarily does what you think it does and possibly not even what you want it to do. The original question stated, "But it results in very big file within minutes, Can i filter tcpdump on base of topic name"
If you're trying to limit the size of the capture file, then the previously accepted answer isn't doing that because it uses the exact same capture filter as was originally provided, namely src 10.x.x.x. This means that you're capturing the same amount of data as you were before. Just because a capture file name wasn't specified doesn't mean that packets aren't being written to a file; they are. In the case of tshark, packets are written to a temporary file, which will continue to grow until the capture session is terminated and then ideally it will be deleted, but not always. The location of the temporary file varies depending on the platform that tshark is run on, but you should be able to easily locate the directory by running tshark -G folders | grep "^Temp".
Now, if you want to reduce the size of the capture file, or the number of packets that you see, then you should be able to modify the tcpdump or tshark command-line arguments to accomplish that.
First off, if you don't need the entire payload, you can apply a snaplen to cut the packets short after some appropriate value. This is done using the -s option, and it's the same option for either capture tool.
OK, but whether you decide to apply a snaplen or not, if you want to filter based on the specific topic name, most likely you can achieve this; however there are a couple of caveats that I listed below. The main idea is to use the slice operator, [] (see the pcap-filter man page) to compare various bytes of the TCP payload to specific values. (NOTE: Neither tcpdump itself nor pcap-filter refers to this operator as the slice operator, but wireshark-filter does, so I do as well.) So the filter should:
Match packets only to/from a particular host, in this case 10.x.x.x
Match only MQTT packets (typically by port number, which I'll assume to be the standard tcp/1883 port)
Match only PUBLISH messages with QoS 0
Match only PUBLISH messages where the topic length is 26 bytes
Match only PUBLISH messages where the topic is "PKGCTRL/1/status/frequency"
Here's a command that should work (at least in most cases -> see caveats below):
tcpdump -i team0 -w mqtt-trace.pcap \
"(src host 10.x.x.x) and \
(tcp port 1883) and \
((tcp[20]&0xf6)=0x30) and \
(tcp[22:2]=26) and \
(tcp[24:4]=0x504b4743 and tcp[28:4]=0x54524c2f and \
tcp[32:4]=0x312f7374 and tcp[36:4]=0x61747573 and \
tcp[40:4]=0x2f667265 and tcp[44:4]=0x7175656e and tcp[48:2]=0x6379)"
It should be obvious from the description of the desired filter above what each separate component of the filter is doing for you.
Here, you'll end up with a capture file of the desired packets that you can reference later on if you need to. You can even apply this same filter to the tshark solution too if you prefer as well as writing to the named capture file, because as I explained earlier, tshark is writing packets to a file whether you explicitly specify one or not.
Caveats:
The filter assumes TCP headers are 20 bytes for simplicity in illustrating the solution, but that may not be the case. If you want a more robust solution to accommodate any TCP header size, then you'll need to determine the TCP header size from the data offset field of the TCP header, which is done in the filter using ((tcp[12]&0xf0)>>4)*4, and then replace every occurrence of 20 in the slice operator's offset field with that value. So for example, tcp[22:2]=26 becomes tcp[(((tcp[12]&0xf0)>>4)*4)+2:2]=26, etc.
Because the MQTT remaining message length field is variable-length encoded per MQTT3.1.1 section 2.2.3 Remaining Length, the filter, as provided above, will only work for values of the remaining length field from 0 to 127, i.e., the remaining length field must only be a single byte. Given that the topic in this case is 26 bytes and the topic length itself is 2 bytes, this means the filter will only work for MQTT message payloads of 99 bytes or less (127 - (2 + 26)).
As #hardillb suggested, use tshark instead. Due to tshark's architecture, you can't write a file at the same time as a display filter (it would be too slow).
To get the information you need, it would look something like this
$ tshark -i team0 -f "src 10.x.x.x" \
-Y "mqtt.topic == PKGCTRL/1/status/frequency" -T fields -e mqtt.topic
-i team0: Filter on interface team0
-f "src 10.x.x.x": Use a capture filter, which is the same as tcpdump's filtering. This will speed up processing as it's faster than a display filter (next bullet).
-Y "mqtt.topic == PKGCTRL/1/status/frequency": Filter for packets that match this display filter
-T fields -e mqtt.topic: Output only the mqtt.topic field, as that is the target information.
-T fields will output columnar data vertically delimited by newlines. It won't be horizontally delimited because there is only column, but the default is \t.
Portable executables compiled using Delphi have a PACKAGEINFO resource that lists the units the program requires & contains.
Documentation of the structure can be found in this version of SysUtils.pas, which shows each TUnitName entry is:
One byte containing flags.
One byte which is a hash code.
The name of the unit, as a null terminated string.
An example can be seen in the PACKAGEINFO structure below:
00000000 00 00 10 cc 00 00 00 00 81 00 00 00 01 59 46 6f |...Ì.........YFo|
00000010 72 6d 31 33 00 10 6d 62 73 55 74 69 6c 73 00 10 |rm13..mbsUtils..|
00000020 55 54 79 70 65 73 00 00 81 53 79 73 49 6e 69 74 |UTypes...SysInit|
The first unit defined (after the header) is named YForm13 with a hash code of 0x59. The second is bsUtils with a hash code of 0x6D.
A comparison between different Delphi compiled executables shows that units like SysInit and System seem to have the same hash code across two files, but this is not a large study.
What is this hash code used for? Can it be correlated to other parts of the compiled executable?
The hash code is used to check whether or not the units are good and can be loaded. Inspecting the code, it is used at runtime and not at compile time.
The part is not documented, however you may inspect the VCL Source code (which cannot be posted here): unit System.SysUtils, look for InternalUnitCheck.
The module name will is used as a part of the hash, and the unit name is used as the last part.
I'm trying to add a filter to a field in Wireshak.
My dissector name is: "basic".
it has 3 fields - field1, field2, field3.
each field can have a value of string.
I want that on Wireshark i'll be able to filter by a particular field, for example: basic.field1. (just the same as you look for tcp.len)
How can i do this?
You must declare the fields, assign them to your protocol and add them to the tree when appropriate. There are currently 2 different types of strings supported by Lua, those of type ftypes.STRING, which is used for strings of a known, fixed length, and type ftypes.STRINGZ, which is a NULL (zero)-terminated string, so how you declare the fields will depend upon which of the 2 types they are.
Unfortunately, despite the documentation listing ftypes.UINT_STRING as a supported type, it isn't as can be seen in the source code for wslua_proto_field.c. This type of string is applicable when a length field precedes the string to indicate the length of the string in bytes. In any case, it isn't currently available for Lua-based dissectors.
So, as an example, let's suppose your protocol uses UDP/33333 as its transport and port number, and its 3 fields consist of each of the 3 types of strings described above, namely:
field1: a fixed-length string of 12 bytes.
field2: a NULL-terminated string of arbitrary length.
field3: a counted string preceded by a 2 byte length field in big-endian (network) byte order.
Given these assumptions, the following will dissect the packets:
-- Protocol
local p_basic = Proto("basic", "Basic Protocol")
-- Fields
local f_basic_field1 = ProtoField.string("basic.field1", "Field1")
local f_basic_field2 = ProtoField.stringz("basic.field2", "Field2")
local f_basic_field3 = ProtoField.string("basic.field3", "Field3")
p_basic.fields = { f_basic_field1, f_basic_field2, f_basic_field3 }
-- Dissection
function p_basic.dissector(buf, pinfo, tree)
local basic_tree = tree:add(p_basic, buf(0,-1))
pinfo.cols.protocol:set("BASIC")
basic_tree:add(f_basic_field1, buf(0, 12))
local strz = buf(12):stringz()
local field2_len = string.len(strz) + 1
basic_tree:add(f_basic_field2, buf(12, field2_len))
local field3_len = buf:range(12 + field2_len, 2):uint()
basic_tree:add(f_basic_field3, buf(12 + field2_len + 2, field3_len))
end
-- Registration
local udp_table = DissectorTable.get("udp.port")
udp_table:add(33333, p_basic)
If you want to test this, first save the above lua code to a file such as basic.lua in your personal plugins directory (Found via Help -> About Wireshark -> Folders -> Personal Plugins). You can then use the following hex bytes to test it:
0000 00 0e b6 00 00 02 00 0e b6 00 00 01 08 00 45 00
0010 00 37 00 00 40 00 40 11 b5 ea c0 00 02 65 c0 00
0020 02 66 82 35 82 35 00 23 22 32 48 65 6c 6c 6f 20
0030 77 6f 72 6c 64 21 48 69 20 74 68 65 72 65 00 00
0040 04 42 79 65 21
Save these bytes into a text file, e.g., basic.txt. Start Wireshark and import the file via File -> Import from Hex Dump... -> Filename:basic.txt -> OK. You should see the 3 fields dissected as part of the "Basic Protocol".
For further help with Lua dissectors, you might want to refer to one or more of the following:
Wireshark Lua (wiki page)
Wireshark Lua Examples (wiki page)
Wireshark Lua Dissectors (wiki page)
Wireshark Contributed scripts, macros, colouring rules and plugins (wiki page)
Chapter 10. Lua Support in Wireshark (Wireshark Developer's Guide)
https://www.wireshark.org/docs/wsdg_html_chunked/wsluarm_modules.html (Wireshark Developer's Guide)
Wireshark Lua API Reference Manual Addendum (wiki page)
Lua Directory
Sharkfest '15 presentation and accompanying YouTube video, by Graham Bloice
I have implemented a websocket server in my existing server. Handshake is good and then I can even send first message and client browser receives it. But any subsequent messages disconnect websocket. On chrome I get following error.
failed: A server must not mask any frames that it sends to the client.
My frame is created like this
Len = erlang:size(Msg),
if
Len < 126 ->
Message = [<<1:1, 0:3,2:4,0:1,Len:7>>,Msg];
Len < 65536 ->
Message = [<<1:1, 0:3,2:4,0:1,126:7,Len:16>>,Msg];
true ->
Message = [<<1:1, 0:3,2:4,0:1,127:7,Len:64>>,Msg]
end,
Now one sample data to be transmitted looks like this
<<130,46,60,115,110,112,95,105,110,102,111,32,97,118,95,112,111,116,61,34,49,49,34,32,104,97,110,100,115,95,112,101,114,95,104,111,117,114,61,34,48,46,50,48,34,32,47,62>>
As you can see in the code above, my mask bit is always set to 0, but I don't why the same message works for the first time and then I send the same message again, it complains about mask bit set.
Anybody got any idea why?
Thanks
The frame sample data you pasted is sane.
48 bytes
ErlangSampleBytes[48] = 82 2E 3C 73 6E 70 5F 69 6E 66 6F 20 61 76 5F 70
6F 74 3D 22 31 31 22 20 68 61 6E 64 73 5F 70 65
72 5F 68 6F 75 72 3D 22 30 2E 32 30 22 20 2F 3E
It Parses/Translates to:
82 = fin:true
rsv1:false
rsv2:false
rsv3:false
opcode:2
2E = masked:false
payloadLength:46 (decimal)
Payload = UTF8 valid:
<snp_info av_pot="11" hands_per_hour="0.20" />
You don't even have a mismatch on the payload length declaration and what is left in the sample buffer.
At this point, it would be wise to look at the chrome inspection tooling to find out what the frames it thinks it got. And a next step after that would be to try to capture the network traffic with a tool like WireShark in an effort to see what is going on.
Suspect that the # of bytes you are sending on the wire, vs what you are declaring in the payloadLength are differing. (common one i've seen is sending more bytes than you declare)
Such as allocating a buffer of 1024 bytes, filling in the first 48 properly, then sending the entire 1024 bytes. That will mess parsing of the next frame.
I have a small graphic that is part of my document. It's PDF, is 193 lines, and has some binary data mixed with its postscript. I'm currently using the graphicx package and including the pdf as a separate file. Is there a way I can inline it directly in my latex source?
Here's a solution I devised:
convert the pdf to postscript using pdftops (part of the xpdf package),
convert the postscript to ASCII-only, and
embed the postscript using the graphicx package and the \special macro.
A drawback is that embedding postscript using \special requires me to emit dvi instead of pdf. It would be nice to improve this solution to allow pdf to be emitted directly.
The latex source will look something like this.
\noindent\vbox to 112pt{\vfil\hbox to 248pt{\special{" gsave
currentfile /ASCIIHexDecode filter cvx exec
25 21 50 53 2d 41 64 6f 62 65 2d 33 2e 30 20 45
50 53 46 2d 33 2e 30 0a 25 20 50 72 6f 64 75 63
65 64 20 62 79 20 78 70 64 66 2f 70 64 66 74 6f
70 73 20 33 2e 30 32 0a 25 25 43 72 65 61 74 6f
...
65 72 0a 65 6e 64 0a 25 25 44 6f 63 75 6d 65 6e
74 53 75 70 70 6c 69 65 64 52 65 73 6f 75 72 63
65 73 3a 0a 25 25 45 4f 46 0a
>
grestore
}
\hfil}}
I made a gist at github that provides a complete example.
Take a look at Asymptote and Latex Integration Guide
I don't think there is a way to inline binary data in LaTeX. You could recreate graphics as vector type images with various packages (such as Asymptote recommended by lpthnc). If you're really clever you could write some TeX to store the data in array format and recreate it, but I don't think there's a package to do it simply.
you should also take a look at the pdfpages package. all kinds of options for including PDFs in your PDF document.
pdfpages: http://www.ctan.org/tex-archive/macros/latex/contrib/pdfpages/pdfpages.pdf
OK, I think this does what you want, but unless you really need to do something like this, other solutions are better.
To be able to use this solution, you need to:
enable shell escape in your Latex command (-shell-escape command line option). Shell escape is disabled by default because of security reasons.
have access to uuencode and uudecode programs where you're compiling the file.
Let's say your graphic is graphic.png, and your main document is doc.tex. First, encode graphic.png and append it to the end (the encoded data is all text):
$ cat graphic.png | uuencode graphic.jpg >>doc.tex
Then, make sure you have this before you include the graphic in doc.tex:
\immediate\write18{cat \jobname.tex | uudecode}
For example, here's a document I created:
\documentclass{article}
\immediate\write18{cat \jobname.tex | uudecode}
\usepackage{graphicx}
\begin{document}
\includegraphics[width=\textwidth]{graphic}
\end{document}
%%% Do not touch the data below, this is added by uuencode.
begin 644 graphic.png
..... (stripped a lot of lines) ...
`
end
Then, this will work:
$ pdflatex -shell-escape doc
As I said, there are much nicer and better solutions, and unless you really have to have one source file, don't do this.