Client exits immediately after selecting server

[KarZan]

I have one machine which acts as a test environment on which I have compiled vompserver. Then I have another machine which acts as my normal vdr device. I have copied the compiled vompserver to the normal vdr device and both macines are running. When I start windows client I get a list of servers as I should but when I select my test machine the client just dies. It works fine on the normal vdr machine. They are both in the same private network with identical vdr versions and linux versions. Even iptables are the same. And on both machines I get the same line in the log:

ERROR: plugin '<no name given>' called cPlugin::ConfigDirectory(), which is not thread safe!

How do I find out why its working on one but not in the other? The funny thing is that it worked on the test machine while I was testing it in the beginning.

Anybody? I really am out of ideas. 

[MartenR]

I have no idea what it can be, but I'll ask some standard questions to get closer to the problem.

1) Version of the vompserver plugin on your two vdr machines? Are they identical and equal to 0.2.5?

2) Plattform of your two servers, Distribution, Intel Prozessor?, 32 Bit or 64 Bit?, Endian ?, gcc version?, libc ?

[KarZan]

1) Yes, they are both 0.2.5.

2) Fedora Core 6, with 2.6.18 kernel, 32 bit version (both). Test environment is with Intel PIII 550MHz and the other is with AMD 3000+. Gcc 4.1.1, libc-2.5.

The funny thing is, that it did work with the test environment when I tested it before copying the libvdr-vompserver to my normal vdr machine. And I can not recall I changed anything.

I have ordered a Hauppauge MediaMVP but havent got it yet so I can not say how it will behave but I should know that in a couple of weeks.

[carsten]

Moin,

the above mentioned line in syslog doesn't seem to be connected to the issue, as it appears in my logs every now and then also, while everything is running.

BR,
Carsten.

[MartenR]

Hmm, I don't have any ideas except for one silly thing. Disconnect one of the servers from the LAN and try again.
Maybe there is an error in the server selection code.

Marten

[KarZan]

Actually I tried that already and it had no affect. There is ofcourse no selection of server and the client just exits after searching server.

And the line in the log is identical between the working and nonworking environments.

[MartenR]

Maybe you can use ethereal or wireshark to sniff the network communication to detect the difference between the two servers.

Marten

[KarZan]

I tried wireshark (on windows client)  but my knowledge on tcp/ip is propably not good enough cause I do not know what to look for 

I sniffed both environments with a series of tasks where I started vompclient and selected the server from the list. Nonworking environment ofcource exited at this point. On working environment I then just excited the client manually.

Then I used wiresharks "expert info" and the difference between the two results was a Keep-Alive <-> Keep-Alive ACK pair on the working environment. I filtered all traffic between client and server.

Any hint how the comparison can be done?

This is the non working log
No.   Time   Source   Destination   Protocol   Info
1   0.000000   192.168.1.11   192.168.1.100   UDP   Source port: 3024  Destination port: 3024
2   5.747812   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [SYN] Seq=0 Len=0 MSS=1460
3   5.748080   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
4   5.748112   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [ACK] Seq=1 Ack=1 Win=65535 Len=0
5   5.762219   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=14
6   5.762408   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [ACK] Seq=1 Ack=15 Win=5840 Len=0
7   5.763656   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [PSH, ACK] Seq=1 Ack=15 Win=5840 Len=12
8   5.768227   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [PSH, ACK] Seq=15 Ack=13 Win=65523 Len=25
9   5.790321   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [PSH, ACK] Seq=13 Ack=40 Win=5840 Len=10
10   5.800717   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [PSH, ACK] Seq=40 Ack=23 Win=65513 Len=38
11   5.801181   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [PSH, ACK] Seq=23 Ack=78 Win=5840 Len=8
12   5.801841   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [PSH, ACK] Seq=78 Ack=31 Win=65505 Len=33
13   5.802126   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [PSH, ACK] Seq=31 Ack=111 Win=5840 Len=15
14   5.802659   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [PSH, ACK] Seq=111 Ack=46 Win=65490 Len=33
15   5.802936   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [PSH, ACK] Seq=46 Ack=144 Win=5840 Len=8
16   5.804889   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [PSH, ACK] Seq=144 Ack=54 Win=65482 Len=37
17   5.805752   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [PSH, ACK] Seq=54 Ack=181 Win=5840 Len=8
18   5.806359   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [FIN, ACK] Seq=181 Ack=62 Win=65474 Len=0
19   5.830900   192.168.1.11   192.168.1.100   TCP   3024 > 1467 [FIN, ACK] Seq=62 Ack=182 Win=5840 Len=0
20   5.830946   192.168.1.100   192.168.1.11   TCP   1467 > 3024 [ACK] Seq=182 Ack=63 Win=65474 Len=0

And this is the working log
No.   Time   Source   Destination   Protocol   Info
1   0.000000   192.168.1.10   192.168.1.100   UDP   Source port: 3024  Destination port: 3024
2   4.463455   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [SYN] Seq=0 Len=0 MSS=1460
3   4.463631   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
4   4.463656   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [ACK] Seq=1 Ack=1 Win=65535 Len=0
5   4.465204   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=14
6   4.465340   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [ACK] Seq=1 Ack=15 Win=5840 Len=0
7   4.465820   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=1 Ack=15 Win=5840 Len=12
8   4.470658   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=15 Ack=13 Win=65523 Len=25
9   4.470922   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=13 Ack=40 Win=5840 Len=10
10   4.482957   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=40 Ack=23 Win=65513 Len=38
11   4.483146   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=23 Ack=78 Win=5840 Len=8
12   4.483810   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=78 Ack=31 Win=65505 Len=33
13   4.483929   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=31 Ack=111 Win=5840 Len=8
14   4.484355   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=111 Ack=39 Win=65497 Len=22
15   4.484476   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=39 Ack=133 Win=5840 Len=8
16   4.485477   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=133 Ack=47 Win=65489 Len=28
17   4.485617   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=47 Ack=161 Win=5840 Len=8
18   4.486209   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=161 Ack=55 Win=65481 Len=18
19   4.486326   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=55 Ack=179 Win=5840 Len=8
20   4.486763   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=179 Ack=63 Win=65473 Len=20
21   4.486879   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=63 Ack=199 Win=5840 Len=14
22   4.494633   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=199 Ack=77 Win=65459 Len=36
23   4.494812   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=77 Ack=235 Win=5840 Len=8
24   4.495521   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=235 Ack=85 Win=65451 Len=36
25   4.495906   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=85 Ack=271 Win=5840 Len=8
26   4.684934   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [ACK] Seq=271 Ack=93 Win=65443 Len=0
27   7.683789   192.168.1.10   192.168.1.100   TCP   [TCP Keep-Alive] 3024 > 1671 [ACK] Seq=92 Ack=271 Win=5840 Len=0
28   7.683824   192.168.1.100   192.168.1.10   TCP   [TCP Keep-Alive ACK] 1671 > 3024 [ACK] Seq=271 Ack=93 Win=65443 Len=0
29   8.212301   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [PSH, ACK] Seq=271 Ack=93 Win=65443 Len=37
30   8.212808   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [PSH, ACK] Seq=93 Ack=308 Win=5840 Len=8
31   8.213426   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [FIN, ACK] Seq=308 Ack=101 Win=65435 Len=0
32   8.213532   192.168.1.10   192.168.1.100   TCP   3024 > 1671 [FIN, ACK] Seq=101 Ack=309 Win=5840 Len=0
33   8.213551   192.168.1.100   192.168.1.10   TCP   1671 > 3024 [ACK] Seq=309 Ack=102 Win=65435 Len=0

The only thing this tells me is thät the communication is just stopped in the non working environment after 20th frame. Or that on the 17th frame is happening something that causes the communication to end.

This is the 17th datablock of the non working
0000  00 20 ed bd 14 df 00 01  02 a2 af d6 08 00 45 00   . ...... ......E.
0010  00 30 47 01 40 00 40 06  70 07 c0 a8 01 0b c0 a8   .0G.@.@. p.......
0020  01 64 0b d0 05 bb 14 10  38 71 82 d6 8e 22 50 18   .d...... 8q..."P.
0030  16 d0 a6 2a 00 00 00 00  00 04 00 00 00 01         ...*.... ...... 

And this is the 17th datablock of the working
0000  00 20 ed bd 14 df 00 17  31 65 29 3c 08 00 45 00   . ...... 1e)<..E.
0010  00 30 74 fe 40 00 40 06  42 0b c0 a8 01 0a c0 a8   .0t.@.@. B.......
0020  01 64 0b d0 06 87 65 72  b9 61 0a 3e 20 ea 50 18   .d....er .a.> .P.
0030  16 d0 b8 de 00 00 00 00  00 04 00 00 00 00         ........ ...... 

There are some differences but do those differences tell anything?

[MartenR]

Ok, we see one thing, that the UDP stuff works. So the error must be caused by some TCP command.

One thing I miss for the interpretation is, that I don't know in which direction your 17th frame travells from server to client or from client to server.
Maybe I tell you something about vomps protocoll. The clients sends a message through tcp (payload) of the form

AA AA AA AA BB BB BB BB payload 

Here is AA AA AA AA the length of BB BB BB BB + payload and BB BB BB BB is the message typ. (Of the BB would only one BB non zero, we have yet only 20 something commands).

Then the server responds with
AA AA AA AA payload
where AA AA AA AA is the length of the payload.

So what we need to know is what the client has asked last before the crash and the servers answer. (And this for both servers.) Then I can compare inside the code, what caused the crash.

Marten

[KarZan]

Ok, this actually helped me. I took a look whats in the conf file on the server and there was Last Power State = Off. Changed it to On and now it works I do not know how this was changed

In the 14th frame client sent "General Last Power State" to server to which the server responded in the 15th frame with string Off.

Seems that when I exit the client it sets the last power state to off thus causing the client to exit after server selection. But the real reason is probaply Power After Boot setting. In the non working environment it is Last State but totally missing from the working environments conf file.

[MartenR]

I will make the options menu and the options version dependent, so that options which are nonsense for the windows version will not appear. Like this option.

Marten