By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,594 Members | 3,680 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,594 IT Pros & Developers. It's quick & easy.

Sockets class question - sending TCP data

P: n/a
I need to duplicate the functionality of a java applet, and how it connects
to a remote server. But, I don't have the protocol information or the java
source code which was written years ago. So, I used a packet sniffer and
saw the protocol (TCP), the port, IP address, etc. All is good. I tried 2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed identical to
those coming from the java program. The problem is that the java program
gets responses back from the remote server, but my code doesn't. It is not
a listening problem, because I am determing the responses by looking at the
packet sniffer. I've tried 2 completely different bits of code, written
differently, and the problem is the same. Again, the transmit side looks
identical to the java program, and so I can't begin to understand why the
responses from the remote server shouldn't be identical. I mean if I send X
to the server, and the java code sends X, the remote server shouldn't be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits are
good but responses are non-existing or empty? Is there some special switch
or something that makes the packets different on the outbound side in a way
a packet sniffer wouldn't notice.

Jun 26 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
D. Partrick,

You say that you did this in a Java applet. Are you doing this in a
..NET control embedded in IE, or are you doing this in a local stand-alone
app? The reason I ask is that if you have embedded the control in IE, then
it is probably a permissions issue which is preventing your message from
returning, and going out in the first place as well.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:iz******************@tornado.socal.rr.com...
I need to duplicate the functionality of a java applet, and how it connects
to a remote server. But, I don't have the protocol information or the
java
source code which was written years ago. So, I used a packet sniffer and
saw the protocol (TCP), the port, IP address, etc. All is good. I tried
2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed identical
to
those coming from the java program. The problem is that the java program
gets responses back from the remote server, but my code doesn't. It is
not
a listening problem, because I am determing the responses by looking at
the
packet sniffer. I've tried 2 completely different bits of code, written
differently, and the problem is the same. Again, the transmit side looks
identical to the java program, and so I can't begin to understand why the
responses from the remote server shouldn't be identical. I mean if I send
X
to the server, and the java code sends X, the remote server shouldn't be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits are
good but responses are non-existing or empty? Is there some special
switch
or something that makes the packets different on the outbound side in a
way
a packet sniffer wouldn't notice.

Jun 26 '06 #2

P: n/a
D. Patrick wrote:
I need to duplicate the functionality of a java applet, and how it connects
to a remote server. But, I don't have the protocol information or the java
source code which was written years ago. So, I used a packet sniffer and
saw the protocol (TCP), the port, IP address, etc. All is good. I tried 2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed identical to
those coming from the java program. The problem is that the java program
gets responses back from the remote server, but my code doesn't. It is not
a listening problem, because I am determing the responses by looking at the
packet sniffer. I've tried 2 completely different bits of code, written
differently, and the problem is the same. Again, the transmit side looks
identical to the java program, and so I can't begin to understand why the
responses from the remote server shouldn't be identical. I mean if I send X
to the server, and the java code sends X, the remote server shouldn't be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits are
good but responses are non-existing or empty? Is there some special switch
or something that makes the packets different on the outbound side in a way
a packet sniffer wouldn't notice.


You can always decompile the Java class files with some luck and try to
find the routines used.

http://members.fortunecity.com/neshkov/dj.html

Jesse
Jun 26 '06 #3

P: n/a
I am trying to duplicate the functionality of a java applet, and not
actually combining .NET and Java. There is no control or IE imbedding
involved, and again, the traffic analyzer shows that I'm sending the same
stuff, but maybe my problem is that I'm still doing it wrong in a way that I
can't decipher from simply looking at TCP and port number and the bytes. I
know there are some strange parameters that alter the sockets methodology,
for example.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:OZ**************@TK2MSFTNGP04.phx.gbl...
D. Partrick,

You say that you did this in a Java applet. Are you doing this in a
.NET control embedded in IE, or are you doing this in a local stand-alone
app? The reason I ask is that if you have embedded the control in IE,
then it is probably a permissions issue which is preventing your message
from returning, and going out in the first place as well.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:iz******************@tornado.socal.rr.com...
I need to duplicate the functionality of a java applet, and how it
connects
to a remote server. But, I don't have the protocol information or the
java
source code which was written years ago. So, I used a packet sniffer
and
saw the protocol (TCP), the port, IP address, etc. All is good. I
tried 2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed identical
to
those coming from the java program. The problem is that the java
program
gets responses back from the remote server, but my code doesn't. It is
not
a listening problem, because I am determing the responses by looking at
the
packet sniffer. I've tried 2 completely different bits of code, written
differently, and the problem is the same. Again, the transmit side looks
identical to the java program, and so I can't begin to understand why the
responses from the remote server shouldn't be identical. I mean if I
send X
to the server, and the java code sends X, the remote server shouldn't be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits are
good but responses are non-existing or empty? Is there some special
switch
or something that makes the packets different on the outbound side in a
way
a packet sniffer wouldn't notice.


Jun 26 '06 #4

P: n/a

"Jesse Houwing" <je***********@nospam-sogeti.nl> wrote in message
news:uY**************@TK2MSFTNGP03.phx.gbl...
D. Patrick wrote:
I need to duplicate the functionality of a java applet, and how it
connects
to a remote server. But, I don't have the protocol information or the
java
source code which was written years ago. So, I used a packet sniffer
and
saw the protocol (TCP), the port, IP address, etc. All is good. I
tried 2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed identical
to
those coming from the java program. The problem is that the java
program
gets responses back from the remote server, but my code doesn't. It is
not
a listening problem, because I am determing the responses by looking at
the
packet sniffer. I've tried 2 completely different bits of code, written
differently, and the problem is the same. Again, the transmit side looks
identical to the java program, and so I can't begin to understand why the
responses from the remote server shouldn't be identical. I mean if I
send X
to the server, and the java code sends X, the remote server shouldn't be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits are
good but responses are non-existing or empty? Is there some special
switch
or something that makes the packets different on the outbound side in a
way
a packet sniffer wouldn't notice.


You can always decompile the Java class files with some luck and try to
find the routines used.

http://members.fortunecity.com/neshkov/dj.html

Jesse


that's an interesting idea, thanks. I don't know java, even though I can
probably guess at some things. do you know of a converter from java to
csharp, by chance?
Jun 26 '06 #5

P: n/a
Have you looked at the actual TCP packets, that is, all of them, including
the ones that do the connecting? I think it would be useful to determine
what sort of connection parameters were used, what sort of Socket settings,
etc. Compare the entire TCP packet binarily. Does your packet sniffer parse
the packets also?

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:30*******************@tornado.socal.rr.com...
I am trying to duplicate the functionality of a java applet, and not
actually combining .NET and Java. There is no control or IE imbedding
involved, and again, the traffic analyzer shows that I'm sending the same
stuff, but maybe my problem is that I'm still doing it wrong in a way that
I can't decipher from simply looking at TCP and port number and the bytes.
I know there are some strange parameters that alter the sockets
methodology, for example.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:OZ**************@TK2MSFTNGP04.phx.gbl...
D. Partrick,

You say that you did this in a Java applet. Are you doing this in a
.NET control embedded in IE, or are you doing this in a local stand-alone
app? The reason I ask is that if you have embedded the control in IE,
then it is probably a permissions issue which is preventing your message
from returning, and going out in the first place as well.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:iz******************@tornado.socal.rr.com...
I need to duplicate the functionality of a java applet, and how it
connects
to a remote server. But, I don't have the protocol information or the
java
source code which was written years ago. So, I used a packet sniffer
and
saw the protocol (TCP), the port, IP address, etc. All is good. I
tried 2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed
identical to
those coming from the java program. The problem is that the java
program
gets responses back from the remote server, but my code doesn't. It is
not
a listening problem, because I am determing the responses by looking at
the
packet sniffer. I've tried 2 completely different bits of code,
written
differently, and the problem is the same. Again, the transmit side
looks
identical to the java program, and so I can't begin to understand why
the
responses from the remote server shouldn't be identical. I mean if I
send X
to the server, and the java code sends X, the remote server shouldn't be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits are
good but responses are non-existing or empty? Is there some special
switch
or something that makes the packets different on the outbound side in a
way
a packet sniffer wouldn't notice.



Jun 26 '06 #6

P: n/a
Yeah, I've compared all, including the connection packets, in both binary
form and "english" byte form.

I am not sure what you mean by whether the packet sniffer parses the
packets.
"Kevin Spencer" <uc*@ftc.gov> wrote in message
news:OP**************@TK2MSFTNGP03.phx.gbl...
Have you looked at the actual TCP packets, that is, all of them, including
the ones that do the connecting? I think it would be useful to determine
what sort of connection parameters were used, what sort of Socket
settings, etc. Compare the entire TCP packet binarily. Does your packet
sniffer parse the packets also?

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:30*******************@tornado.socal.rr.com...
I am trying to duplicate the functionality of a java applet, and not
actually combining .NET and Java. There is no control or IE imbedding
involved, and again, the traffic analyzer shows that I'm sending the same
stuff, but maybe my problem is that I'm still doing it wrong in a way that
I can't decipher from simply looking at TCP and port number and the bytes.
I know there are some strange parameters that alter the sockets
methodology, for example.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:OZ**************@TK2MSFTNGP04.phx.gbl...
D. Partrick,

You say that you did this in a Java applet. Are you doing this in a
.NET control embedded in IE, or are you doing this in a local
stand-alone app? The reason I ask is that if you have embedded the
control in IE, then it is probably a permissions issue which is
preventing your message from returning, and going out in the first place
as well.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:iz******************@tornado.socal.rr.com...
I need to duplicate the functionality of a java applet, and how it
connects
to a remote server. But, I don't have the protocol information or the
java
source code which was written years ago. So, I used a packet sniffer
and
saw the protocol (TCP), the port, IP address, etc. All is good. I
tried 2
different versions of .NET code to duplicate the requests to the remote
server. Again, I used the packet sniffer and my packets seemed
identical to
those coming from the java program. The problem is that the java
program
gets responses back from the remote server, but my code doesn't. It is
not
a listening problem, because I am determing the responses by looking at
the
packet sniffer. I've tried 2 completely different bits of code,
written
differently, and the problem is the same. Again, the transmit side
looks
identical to the java program, and so I can't begin to understand why
the
responses from the remote server shouldn't be identical. I mean if I
send X
to the server, and the java code sends X, the remote server shouldn't
be
able to tell whether it is my code or the java code, right?

Any thoughts? Anyone seen anything like this before where transmits
are
good but responses are non-existing or empty? Is there some special
switch
or something that makes the packets different on the outbound side in a
way
a packet sniffer wouldn't notice.




Jun 27 '06 #7

P: n/a
Ethereal, for example, parses packets. Here's an example from a capture (one
packet):

No. Time Source Destination Protocol Info
Src Port Dst Port
1 07:02:47 DellComp_f9:54:48 NETBIOS- BROWSER Host
Announcement DEV02, Workstation, Server, SQL Server, NT Workstation, NT
Server, Backup Browser

Frame 1 (180 bytes on wire, 180 bytes captured)
Arrival Time: Jun 27, 2006 07:02:47.267019000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 180 bytes
Capture Length: 180 bytes
Protocols in frame: eth:llc:netbios:smb:browser
IEEE 802.3 Ethernet
Destination: NETBIOS- (03:00:00:00:00:01)
Source: DellComp_f9:54:48 (00:b0:d0:f9:54:48)
Length: 166
Logical-Link Control
DSAP: NetBIOS (0xf0)
IG Bit: Individual
SSAP: NetBIOS (0xf0)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
NetBIOS
Length: 44 bytes
Delimiter: EFFF (NetBIOS)
Command: Datagram (0x08)
Receiver's Name: DYNAMICSYSTEMS<1d> (Local Master Browser)
DYNAMICSYSTEMS
0x1d (Local Master Browser)
Sender's Name: DEV02<20> (Server service)
DEV02
0x20 (Server service)
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
SMB Command: Trans (0x25)
Error Class: Success (0x00)
Reserved: 00
Error Code: No Error
Flags: 0x00
0... .... = Request/Response: Message is a request to the server
.0.. .... = Notify: Notify client only on open
..0. .... = Oplocks: OpLock not requested/granted
...0 .... = Canonicalized Pathnames: Pathnames are not
canonicalized
.... 0... = Case Sensitivity: Path names are case sensitive
.... ..0. = Receive Buffer Posted: Receive buffer has not been
posted
.... ...0 = Lock and Read: Lock&Read, Write&Unlock are not
supported
Flags2: 0x0000
0... .... .... .... = Unicode Strings: Strings are ASCII
.0.. .... .... .... = Error Code Type: Error codes are DOS error
codes
..0. .... .... .... = Execute-only Reads: Don't permit reads if
execute-only
...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
.... 0... .... .... = Extended Security Negotiation: Extended
security negotiation is not supported
.... .... .0.. .... = Long Names Used: Path names in request are
not long file names
.... .... .... .0.. = Security Signatures: Security signatures
are not supported
.... .... .... ..0. = Extended Attributes: Extended attributes
are not supported
.... .... .... ...0 = Long Names Allowed: Long file names are
not allowed in the response
Process ID High: 0
Signature: 0000000000000000
Reserved: 0000
Tree ID: 0
Process ID: 0
User ID: 0
Multiplex ID: 0
Trans Request (0x25)
Word Count (WCT): 17
Total Parameter Count: 0
Total Data Count: 33
Max Parameter Count: 0
Max Data Count: 0
Max Setup Count: 0
Reserved: 00
Flags: 0x0000
.... .... .... ..0. = One Way Transaction: Two way transaction
.... .... .... ...0 = Disconnect TID: Do NOT disconnect TID
Timeout: 1 second
Reserved: 0000
Parameter Count: 0
Parameter Offset: 0
Data Count: 33
Data Offset: 86
Setup Count: 3
Reserved: 00
Byte Count (BCC): 50
Transaction Name: \MAILSLOT\BROWSE
SMB MailSlot Protocol
Opcode: Write Mail Slot (1)
Priority: 0
Class: Unreliable & Broadcast (2)
Size: 50
Mailslot Name: \MAILSLOT\BROWSE
Microsoft Windows Browser Protocol
Command: Host Announcement (0x01)
Update Count: 0
Update Periodicity: 12 minutes
Host Name: DEV02
OS Major Version: 5
OS Minor Version: 0
Server Type: 0x00029007
.... .... .... .... .... .... .... ...1 = Workstation: This is a
Workstation
.... .... .... .... .... .... .... ..1. = Server: This is a Server
.... .... .... .... .... .... .... .1.. = SQL: This is an SQL server
.... .... .... .... .... .... .... 0... = Domain Controller: This is
NOT a Domain Controller
.... .... .... .... .... .... ...0 .... = Backup Controller: This is
NOT a Backup Controller
.... .... .... .... .... .... ..0. .... = Time Source: This is NOT a
Time Source
.... .... .... .... .... .... .0.. .... = Apple: This is NOT an
Apple host
.... .... .... .... .... .... 0... .... = Novell: This is NOT a
Novell server
.... .... .... .... .... ...0 .... .... = Member: This is NOT a
Domain Member server
.... .... .... .... .... ..0. .... .... = Print: This is NOT a Print
Queue server
.... .... .... .... .... .0.. .... .... = Dialin: This is NOT a
Dialin server
.... .... .... .... .... 0... .... .... = Xenix: This is NOT a Xenix
server
.... .... .... .... ...1 .... .... .... = NT Workstation: This is an
NT Workstation
.... .... .... .... ..0. .... .... .... = WfW: This is NOT a WfW
host
.... .... .... .... 1... .... .... .... = NT Server: This is an NT
Server
.... .... .... ...0 .... .... .... .... = Potential Browser: This is
NOT a Potential Browser
.... .... .... ..1. .... .... .... .... = Backup Browser: This is a
Backup Browser
.... .... .... .0.. .... .... .... .... = Master Browser: This is
NOT a Master Browser
.... .... .... 0... .... .... .... .... = Domain Master Browser:
This is NOT a Domain Master Browser
.... .... ...0 .... .... .... .... .... = OSF: This is NOT an OSF
host
.... .... ..0. .... .... .... .... .... = VMS: This is NOT a VMS
host
.... .... .0.. .... .... .... .... .... = Windows 95+: This is NOT a
Windows 95 or above host
.0.. .... .... .... .... .... .... .... = Local: This is NOT a local
list only request
0... .... .... .... .... .... .... .... = Domain Enum: This is NOT a
Domain Enum request
Browser Protocol Major Version: 15
Browser Protocol Minor Version: 1
Signature: 0xaa55
Host Comment:

0000 03 00 00 00 00 01 00 b0 d0 f9 54 48 00 a6 f0 f0 ..........TH....
0010 03 2c 00 ff ef 08 00 00 00 00 00 00 00 44 59 4e .,...........DYN
0020 41 4d 49 43 53 59 53 54 45 4d 53 20 1d 44 45 56 AMICSYSTEMS .DEV
0030 30 32 20 20 20 20 20 20 20 20 20 20 20 ff 53 4d 02 .SM
0040 42 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B%..............
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 11 00 00 ................
0060 21 00 00 00 00 00 00 00 00 00 e8 03 00 00 00 00 !...............
0070 00 00 00 00 21 00 56 00 03 00 01 00 00 00 02 00 ....!.V.........
0080 32 00 5c 4d 41 49 4c 53 4c 4f 54 5c 42 52 4f 57 2.\MAILSLOT\BROW
0090 53 45 00 01 00 80 fc 0a 00 44 45 56 30 32 00 00 SE.......DEV02..
00a0 00 00 00 00 00 00 00 00 00 05 00 07 90 02 00 0f ................
00b0 01 55 aa 00 .U..

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:fH*****************@tornado.socal.rr.com...
Yeah, I've compared all, including the connection packets, in both binary
form and "english" byte form.

I am not sure what you mean by whether the packet sniffer parses the
packets.
"Kevin Spencer" <uc*@ftc.gov> wrote in message
news:OP**************@TK2MSFTNGP03.phx.gbl...
Have you looked at the actual TCP packets, that is, all of them,
including the ones that do the connecting? I think it would be useful to
determine what sort of connection parameters were used, what sort of
Socket settings, etc. Compare the entire TCP packet binarily. Does your
packet sniffer parse the packets also?

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.
"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:30*******************@tornado.socal.rr.com...
I am trying to duplicate the functionality of a java applet, and not
actually combining .NET and Java. There is no control or IE imbedding
involved, and again, the traffic analyzer shows that I'm sending the same
stuff, but maybe my problem is that I'm still doing it wrong in a way
that I can't decipher from simply looking at TCP and port number and the
bytes. I know there are some strange parameters that alter the sockets
methodology, for example.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:OZ**************@TK2MSFTNGP04.phx.gbl...
D. Partrick,

You say that you did this in a Java applet. Are you doing this in a
.NET control embedded in IE, or are you doing this in a local
stand-alone app? The reason I ask is that if you have embedded the
control in IE, then it is probably a permissions issue which is
preventing your message from returning, and going out in the first
place as well.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"D. Patrick" <re*****************@thenotreal.com> wrote in message
news:iz******************@tornado.socal.rr.com...
>I need to duplicate the functionality of a java applet, and how it
>connects
> to a remote server. But, I don't have the protocol information or the
> java
> source code which was written years ago. So, I used a packet sniffer
> and
> saw the protocol (TCP), the port, IP address, etc. All is good. I
> tried 2
> different versions of .NET code to duplicate the requests to the
> remote
> server. Again, I used the packet sniffer and my packets seemed
> identical to
> those coming from the java program. The problem is that the java
> program
> gets responses back from the remote server, but my code doesn't. It
> is not
> a listening problem, because I am determing the responses by looking
> at the
> packet sniffer. I've tried 2 completely different bits of code,
> written
> differently, and the problem is the same. Again, the transmit side
> looks
> identical to the java program, and so I can't begin to understand why
> the
> responses from the remote server shouldn't be identical. I mean if I
> send X
> to the server, and the java code sends X, the remote server shouldn't
> be
> able to tell whether it is my code or the java code, right?
>
> Any thoughts? Anyone seen anything like this before where transmits
> are
> good but responses are non-existing or empty? Is there some special
> switch
> or something that makes the packets different on the outbound side in
> a way
> a packet sniffer wouldn't notice.
>
>
>



Jun 27 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.