Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
marchywka
Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: Port opening and closing.

[ Edited ]

From the description you gave, it sounds like your "known to work" example could just have set a shorter timeout.

I'm not sure if nmap is really the best stimulator but let's try wget along with apache ( since I happen to be set up

for this right now). Armed with showtraffic ( pretty dirt level for this, but again it is what I have ) and the spec,

[ ed, I originally indicated tcpdump which I do have but didn't use here ]  

 

http://www.ietf.org/rfc/rfc793.txt

 

I can hit my server,

 

$ wget -O ~/xxx -S -v "http://192.168.2.103"

 

And check the remote log ( note this packet capture doesn't work with all wireless cards but read the notes on anything you may want to use ).

 

$ cat showtraf.log |grep  -A 10 ".103" | grep -A 10 ".104" | grep -A 10 ":80"

 

 [ at this point I could be doing a lot wrong but with primitive tools this is how you go... ]

 

$ cat server_hit | grep "Proto\|000020" | sed -e 's/Proto: TCP //' | awk '{print $1" "$2" "$3" "$4" "$5" "$6}'

 

I'm inserting stuff from RFC, that you need to determiine is accurate,  

presumably I've got the push bit set but again check,

 

 

   20  URG:  Urgent Pointer field significant
  10 ACK:  Acknowledgment field significant
  8  PSH:  Push Function
 4   RST:  Reset the connection
2    SYN:  Synchronize sequence numbers
1    FIN:  No more data from sender

 

 

len: 64 192.168.2.104:1358 -> 192.168.2.103:80
00000020 b0 02 00 00 21

SYN-SENT    --><CTL=SYN>               --> SYN-RECEIVED
len: 64 192.168.2.103:80 -> 192.168.2.104:1358
00000020 b0 12 fa f0 a3

ESTABLISHED <--<CTL=SYN,ACK>  <-- SYN-RECEIVED
len: 52 192.168.2.104:1358 -> 192.168.2.103:80
00000020 80 10 80 00 0e

ESTABLISHED --> <CTL=ACK>       --> ESTABLISHED
len: 152 192.168.2.104:1358 -> 192.168.2.103:80
00000020 80 18 80 00 e2

ESTABLISHED --><CTL=ACK><DATA> --> ESTABLISHED
len: 52 192.168.2.103:80 -> 192.168.2.104:1358
00000020 80 10 fa 8c 8c
len: 401 192.168.2.103:80 -> 192.168.2.104:1358
00000020 80 18 fa 8c e4
len: 52 192.168.2.104:1358 -> 192.168.2.103:80
00000020 80 11 7f a8 06

 FIN-WAIT-1  --><CTL=FIN,ACK>  --> CLOSE-WAIT
len: 52 192.168.2.103:80 -> 192.168.2.104:1358
00000020 80 10 fa 8c 8b

FIN-WAIT-2  <-- <CTL=ACK>      <-- CLOSE-WAIT

len: 52 192.168.2.103:80 -> 192.168.2.104:1358
00000020 80 11 fa 8c 8b

TIME-WAIT   <-- <CTL=FIN,ACK>  <-- LAST-ACK
len: 52 192.168.2.104:1358 -> 192.168.2.103:80
00000020 80 10 7f a8 06

 TIME-WAIT   --> <CTL=ACK>      --> CLOSED

 

 

Note that the above grep is supposed to isolate the tcp bits from more complete packages, you could

try to verfiy yourself from a more complete dump,

 

 

[2008.09.27 - 08:31:48.202]
Proto: TCP len: 152 192.168.2.104:1358 -> 192.168.2.103:80

00000000 45 00 00 98 13 7e 40 00 80 06 60 c2 c0 a8 02 68 E  ~‼~@ ?♠`AA"☻h
00000010 c0 a8 02 67 05 4e 00 50 69 24 1f 33 d0 f3 b2 1e A"☻g♣N Pi$▼3Dó²▲
00000020 80 18 80 00 e2 14 00 00 01 01 08 0a 00 00 50 c0 ?↑? ⶠ ☺☺    PA
00000030 00 00 00 00 47 45 54 20 2f 20 48 54 54 50 2f 31     GET / HTTP/1
00000040 2e 30 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 .0  User-Agent:
00000050 57 67 65 74 2f 31 2e 39 2e 31 0d 0a 48 6f 73 74 Wget/1.9.1  Host
00000060 3a 20 31 39 32 2e 31 36 38 2e 32 2e 31 30 33 0d : 192.168.2.103
00000070 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 43 6f  Accept: */*  Co
00000080 6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65 70 2d 41 nnection: Keep-A

 

 

Message Edited by marchywka on 09-27-2008 09:33 AM
Developer
rgelb1
Posts: 108
Registered: ‎08-05-2008
My Device: Not Specified

Re: Port opening and closing.

I did a bit of investigation about ports not closing with Microsoft Network Monitor and the bottom line is that closing SocketConnection or the DataOutputStream don't actually send necessary TCP commands to close the connection.  I compared TCP packets sent from a BlackBerry client to those sent by a desktop client app (written in C#).

 

Here is the C# Client portion:

 

Client -> Server: SYN (e.g. sync sequence numbers)

Server -> Client: SYN and ACK (numbers synced and acknowledged receipt of message)

Client -> Server:  ACK (acknowledged receipt of message)

Client -> Server:  PUSH and ACK (Sending the actual data and ACK)

Client -> Server:  FIN and ACK (End of Data and ACK)

Server -> Client:  ACK

Server -> Client:  FIN and ACK

Client -> Server:  ACK

 

At this point the connection is terminated.

 

Here are the packets coming from the BlackBerry client

Client -> Server: SYN (e.g. sync sequence numbers)

Server -> Client: SYN and ACK (numbers synced and acknowledged receipt of message)

Client -> Server:  ACK (acknowledged receipt of message)

Client -> Server:  PUSH and ACK (Sending the actual data and ACK)

Server -> Client:  ACK 

 

then 110 seconds later:

Client -> Server:  FIN and ACK (End of Data and ACK)

Server -> Client:  ACK

Server -> Client:  FIN and ACK

Client -> Server:  ACK

 

 

So, as you can see the FIN (end of data) command is not sent 110 seconds after I sent out the last message, closed the output stream and the connection.

 

Note that the IP address of the BlackBerry resolves to the Enterprise BlackBerry Server installed here at my employer, not to the actual blackberry.   I don't know whether this is important or not.  So it seems like the Enterprise BlackBerry Server holds on to the signal to close the connection for 110 seconds, then sends the FIN.

 

Where can I go from here?

 

 

 

BlackBerry Development Advisor
MSohm
Posts: 14,864
Registered: ‎07-09-2008
My Device: BlackBerry Passport

Re: Port opening and closing.

Since this doesn't look like a BlackBerry application issue, I recommending posting your last message (and a brief recap) in the BlackBerry Enterprise Solution forum.
Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Developer
marchywka
Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: Port opening and closing.

Someone from RIM could confirm if ";deviceside=true" would at least let you isolate the problem by making

a direct connection. Did you try to read the nonexistent input data from another thread?

 

 I'll look in more detail at your results later but you could consider checking your firewall(s) too.

I assume you C# code is on a different machine from the server? I guess there could be some quirks

due to the specifics of the network path beyond MDS. I guess your firewall could be getting confused

but I've never looked at attack scenarios in enough detail to determine if this is realistic. I'm not sure if

tracert or anything similar would help.

 

BlackBerry Development Advisor
MSohm
Posts: 14,864
Registered: ‎07-09-2008
My Device: BlackBerry Passport

Re: Port opening and closing.

Good point.  Trying deviceside=true would elminate the BlackBerry Enterprise Server from the equation.  That would also be a good test.
Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Developer
rgelb1
Posts: 108
Registered: ‎08-05-2008
My Device: Not Specified

Re: Port opening and closing.

Gentlemen,to your questions and clarifications...

 

1.  I can't use deviceside=true because I need to hit an IP address within the enterprise network.  E.g. not on the public internet.   

2.  No, i did not try to read from another thread.  Everything is occuring on a single thread.

3.  There are no firewalls on the boxes I control.   I suppose there could be something on the BlackBerry enterprise server, but even if there was a firewall there, it's unlikely that the BBES firewall would keep the FIN message for exactly 110 seconds and then release it.