I've allowed all in both Sygate and Process Guard for anything involved with this.
May I throw in some suggestions from the outer? I note that you are running Microsoft Windows XP Home Edition, Service Pack 2.
#1 I have observed that sometimes the Windows Firewall ( bizarrely, regardless of whether it is set on or off ) needs to have an explicit exception rule applied to enable stuff. Try this:
Start -> Control Panel -> Windows Firewall -> Exceptions -> Add Port
Say enter 'BOINC' in the Name field, and '1043' in the Port Number field. Press OK, and OK again to close. Reboot to be sure....
#2 Another sneaky spot to look is as follows:
Start -> Control Panel -> Network Connections -> Click on whatever is your internet connection -> Properties -> Click/Highlight Internet Protocol ( TCP/IP ) -> Properties -> Advanced ( on Internet Protocol (TCP/IP) Properties now ) -> Options ( on Advanced TCP/IP Settings now ) -> Options -> Click/Highlight TCP/IP Filtering -> and make sure the box to the left of 'Enable TCP/IP Filtering ( All adapters ) DOES NOT HAVE A TICK in it. Close all those screens by clicking on the OK's and Close's. Reboot to be sure.......
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Bruce mentions "3 minute latency". Does that mean search for an entry 3minutes later than time shown in my logs? 3min. earliar? 3min. +/-?
To clarify this, I've modified the message at the start of the logfiles. It now reads:
These files are posted approximately three minutes after the events are logged.
The other thing I've noticed is that the minute logs don't always seem to have the full minute. I've seen examples of small bits of time missing at the start and the end of each minute. Maybe this is an artifact of the log slicing process. If we are unlucky, maybe your bit of the server log just happens to be missing. I'll post a query in Bruce's thread. Hopefully he'll see it.
Gary, I didn't see this in the other thread (but I'll check again). Could you please give me an example? The three-minute latency exists EXACTLY because I want to capture all events for a given minute, and sometimes events are logged with up to a three minute delay.
So all we have to do is work out what is wrong with the maths for your case. We simply must be looking in the wrong log slice.
Also possible that there was no scheduler contact at that time. (I'm not sure, I'm not sure which client side log snippet is relevant for this thread.)
Quote:
Please right click your clock and -> Adjust Date/Time and go to the Time Zone tab. You see your world map so please tell us what it says there for time zone. Thank you.
Another way to figure out the UTC offset is for a user to look in the sched log directory and see what the most recent log file was. This is about three minutes old. Just comparing this with their computer's clock or the wallclock immediately shows their offset from UTC.
And after reading this thread more thorough, I suspect you will not find
the mentioned incident in the scheduler logs, because no scheduler is
involved during upload !?
Michael, this is correct. File upload does NOT use the scheduler and hence does not appear in the scheduler logs. File upload is an asyncronous process. It is designed this way because this design reduces strain/load on the database.
Tried all three of those capture filter values-in each case error message: No packets captured! As no packets captured, closing temporary capture file.
seems you are not giving up. OK, bear with me one more time. First we should
check, if anything is captured at all.
1) Try with no filter at all. This make no sense, but it is just to check,
if it is working at all.
2) We need to filter the output. Use "tcp port 80" as filter and browse
the web a little. This will not work, if you are behind a proxy, which might
use another port e.g. 8080.
3) Best thing to do, would be capture all HTTP traffic, but I was unsuccessful to create such a filter. Anyone an idea?
4) So the last thing, use "src host ". Try your upload, save
it to a file and look for error 500.
Just to prove it SHOULD work. An excerpt from my last upload:
No. Time Source Destination Protocol Info
3 0.147414 192.168.0.103 129.89.61.70 HTTP POST /EinsteinAtHome_cgi/file_upload_handler HTTP/1.1
This was generated with "dst host 129.89.61.70", this is einstein.phys.uwm.edu, my ul/dl server. This information is in sched_request_einstein.phys.uwm.edu.xml in your BOINC directory.
Michael
PS: Seems I'am really bad at helping people. Also I will have no access to a Windows PC during the holydays.
"Two things are infinite: the Universe, and human stupidity. And I'm not sure about the universe." -A. Einstein
You probably wish I would just go away. Here is what I got running BOINC with no capture filter- first a whole lot of that "who has tell " which I will spare you. Then-
Frame 2091 (343 bytes on wire, 343 bytes captured)
Ethernet II, Src: FirstInt_41:30:f1 (00:40:ca:41:30:f1), Dst: 24.161.128.1 (00:05:9a:d0:f4:a8)
Internet Protocol, Src: 66.91.2.128 (66.91.2.128), Dst: 129.89.61.70 (129.89.61.70)
Transmission Control Protocol, Src Port: 3166 (3166), Dst Port: http (80), Seq: 242, Ack: 26, Len: 289
Reassembled TCP Segments (530 bytes): #2073(241), #2091(289)
Hypertext Transfer Protocol
Line-based text data: application/x-www-form-urlencoded
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
2092 70.363997 129.89.61.70 66.91.2.128 TCP [TCP segment of a reassembled PDU]
Frame 2091 (343 bytes on wire, 343 bytes captured)
Ethernet II, Src: FirstInt_41:30:f1 (00:40:ca:41:30:f1), Dst: 24.161.128.1 (00:05:9a:d0:f4:a8)
Internet Protocol, Src: 66.91.2.128 (66.91.2.128), Dst: 129.89.61.70 (129.89.61.70)
Transmission Control Protocol, Src Port: 3166 (3166), Dst Port: http (80), Seq: 242, Ack: 26, Len: 289
Reassembled TCP Segments (530 bytes): #2073(241), #2091(289)
Hypertext Transfer Protocol
Line-based text data: application/x-www-form-urlencoded
Hypertext Transfer Protocol
OK, this is probably a scheduler request. From source 66.91.2.128 (cpe-66-91-2-128.hawaii.res.rr.com; IP assigned to you from your provider!?) to
destination 129.89.61.70 (einstein.phys.uwm.edu). Could you post the
entiry HTTP answer here? Should be available in the export.
Quote:
No. Time Source Destination Protocol Info
2092 70.363997 129.89.61.70 66.91.2.128 TCP [TCP segment of a reassembled PDU]
No. Time Source Destination Protocol Info
2093 70.385742 129.89.61.70 66.91.2.128 HTTP HTTP/1.1 200 OK (text/plain)
In case of error I was awaiting something like "500 ERROR". Hm. maybe BOINC
is translating it by itself to error 500, although it was not an HTTP error
500 at all? This HTTP request was OK, indicated by "200 OK".
Quote:
Frame 2093 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 270, Ack: 531, Len: 1460
Reassembled TCP Segments (1704 bytes): #2092(244), #2093(1460)
Hypertext Transfer Protocol
Line-based text data: text/plain
No. Time Source Destination Protocol Info
2094 70.386037 66.91.2.128 129.89.61.70 TCP 3166 > http [ACK] Seq=531 Ack=1730 Win=256960 Len=0
No. Time Source Destination Protocol Info
2096 70.532527 129.89.61.70 66.91.2.128 HTTP Continuation or non-HTTP traffic
Frame 2096 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 1730, Ack: 531, Len: 1460
Hypertext Transfer Protocol
More HTTP traffic between you and einstein. Now please post the content of the
requests here. Again, they should be in the export file. This is displayed in the GUI too. Select the appropriate entry and have a look at the bottom frame. In the middle frame there are triangle shaped "buttons". Click on them
and they open up more info.
RE: I've allowed all in
)
May I throw in some suggestions from the outer? I note that you are running Microsoft Windows XP Home Edition, Service Pack 2.
#1 I have observed that sometimes the Windows Firewall ( bizarrely, regardless of whether it is set on or off ) needs to have an explicit exception rule applied to enable stuff. Try this:
Start -> Control Panel -> Windows Firewall -> Exceptions -> Add Port
Say enter 'BOINC' in the Name field, and '1043' in the Port Number field. Press OK, and OK again to close. Reboot to be sure....
#2 Another sneaky spot to look is as follows:
Start -> Control Panel -> Network Connections -> Click on whatever is your internet connection -> Properties -> Click/Highlight Internet Protocol ( TCP/IP ) -> Properties -> Advanced ( on Internet Protocol (TCP/IP) Properties now ) -> Options ( on Advanced TCP/IP Settings now ) -> Options -> Click/Highlight TCP/IP Filtering -> and make sure the box to the left of 'Enable TCP/IP Filtering ( All adapters ) DOES NOT HAVE A TICK in it. Close all those screens by clicking on the OK's and Close's. Reboot to be sure.......
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Bruce mentions "3
)
To clarify this, I've modified the message at the start of the logfiles. It now reads:
These files are posted approximately three minutes after the events are logged.
Director, Einstein@Home
RE: The other thing I've
)
Gary, I didn't see this in the other thread (but I'll check again). Could you please give me an example? The three-minute latency exists EXACTLY because I want to capture all events for a given minute, and sometimes events are logged with up to a three minute delay.
Director, Einstein@Home
RE: So all we have to do is
)
Also possible that there was no scheduler contact at that time. (I'm not sure, I'm not sure which client side log snippet is relevant for this thread.)
Another way to figure out the UTC offset is for a user to look in the sched log directory and see what the most recent log file was. This is about three minutes old. Just comparing this with their computer's clock or the wallclock immediately shows their offset from UTC.
Director, Einstein@Home
RE: And after reading this
)
Michael, this is correct. File upload does NOT use the scheduler and hence does not appear in the scheduler logs. File upload is an asyncronous process. It is designed this way because this design reduces strain/load on the database.
Director, Einstein@Home
RE: RE: He's probably got
)
I thought that this was a potentially useful trick, so I linked the 'last scheduler contact' time to the appropriate scheduler log minute file.
Director, Einstein@Home
Ok-- Checked win.
)
Ok--
Checked win. firewall. no change.
Tried all three of those capture filter values-in each case error message: No packets captured! As no packets captured, closing temporary capture file.
Watching the wheels go 'round,
Brad
"You have confused the true with the real."
Hi Brad, seems you are not
)
Hi Brad,
seems you are not giving up. OK, bear with me one more time. First we should
check, if anything is captured at all.
1) Try with no filter at all. This make no sense, but it is just to check,
if it is working at all.
2) We need to filter the output. Use "tcp port 80" as filter and browse
the web a little. This will not work, if you are behind a proxy, which might
use another port e.g. 8080.
3) Best thing to do, would be capture all HTTP traffic, but I was unsuccessful to create such a filter. Anyone an idea?
4) So the last thing, use "src host ". Try your upload, save
it to a file and look for error 500.
Just to prove it SHOULD work. An excerpt from my last upload:
No. Time Source Destination Protocol Info
3 0.147414 192.168.0.103 129.89.61.70 HTTP POST /EinsteinAtHome_cgi/file_upload_handler HTTP/1.1
Frame 3 (308 bytes on wire, 308 bytes captured)
Ethernet II, Src: 00:13:d4:dc:c0:f5, Dst: 00:40:05:d4:74:3e
Destination: 00:40:05:d4:74:3e (AniCommu_d4:74:3e)
Source: 00:13:d4:dc:c0:f5 (00:13:d4:dc:c0:f5)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.0.103 (192.168.0.103), Dst Addr: 129.89.61.70 (129.89.61.70)
Transmission Control Protocol, Src Port: 48706 (48706), Dst Port: http (80), Seq: 1, Ack: 0, Len: 242
Source port: 48706 (48706)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 243 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 5840 (scaled)
Checksum: 0xd093 (correct)
Options: (12 bytes)
Hypertext Transfer Protocol
POST /EinsteinAtHome_cgi/file_upload_handler HTTP/1.1\\r\\n
User-Agent: BOINC client (i686-pc-linux-gnu 5.02)\\r\\n
Host: einstein.phys.uwm.edu\\r\\n
Accept: */*\\r\\n
Content-Type: application/x-www-form-urlencoded\\r\\n
Content-Length: 286\\r\\n
Expect: 100-continue\\r\\n
\\r\\n
This was generated with "dst host 129.89.61.70", this is einstein.phys.uwm.edu, my ul/dl server. This information is in sched_request_einstein.phys.uwm.edu.xml in your BOINC directory.
Michael
PS: Seems I'am really bad at helping people. Also I will have no access to a Windows PC during the holydays.
Team Linux Users Everywhere
"Two things are infinite: the
)
"Two things are infinite: the Universe, and human stupidity. And I'm not sure about the universe." -A. Einstein
You probably wish I would just go away. Here is what I got running BOINC with no capture filter- first a whole lot of that "who has tell " which I will spare you. Then-
Frame 2091 (343 bytes on wire, 343 bytes captured)
Ethernet II, Src: FirstInt_41:30:f1 (00:40:ca:41:30:f1), Dst: 24.161.128.1 (00:05:9a:d0:f4:a8)
Internet Protocol, Src: 66.91.2.128 (66.91.2.128), Dst: 129.89.61.70 (129.89.61.70)
Transmission Control Protocol, Src Port: 3166 (3166), Dst Port: http (80), Seq: 242, Ack: 26, Len: 289
Reassembled TCP Segments (530 bytes): #2073(241), #2091(289)
Hypertext Transfer Protocol
Line-based text data: application/x-www-form-urlencoded
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
2092 70.363997 129.89.61.70 66.91.2.128 TCP [TCP segment of a reassembled PDU]
Frame 2092 (298 bytes on wire, 298 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 26, Ack: 531, Len: 244
No. Time Source Destination Protocol Info
2093 70.385742 129.89.61.70 66.91.2.128 HTTP HTTP/1.1 200 OK (text/plain)
Frame 2093 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 270, Ack: 531, Len: 1460
Reassembled TCP Segments (1704 bytes): #2092(244), #2093(1460)
Hypertext Transfer Protocol
Line-based text data: text/plain
No. Time Source Destination Protocol Info
2094 70.386037 66.91.2.128 129.89.61.70 TCP 3166 > http [ACK] Seq=531 Ack=1730 Win=256960 Len=0
Frame 2094 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FirstInt_41:30:f1 (00:40:ca:41:30:f1), Dst: 24.161.128.1 (00:05:9a:d0:f4:a8)
Internet Protocol, Src: 66.91.2.128 (66.91.2.128), Dst: 129.89.61.70 (129.89.61.70)
Transmission Control Protocol, Src Port: 3166 (3166), Dst Port: http (80), Seq: 531, Ack: 1730, Len: 0
No. Time Source Destination Protocol Info
2095 70.460172 24.161.128.1 Broadcast ARP Who has 24.161.129.230? Tell 24.161.128.1
Frame 2095 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)
No. Time Source Destination Protocol Info
2096 70.532527 129.89.61.70 66.91.2.128 HTTP Continuation or non-HTTP traffic
Frame 2096 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 1730, Ack: 531, Len: 1460
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
2097 70.533718 129.89.61.70 66.91.2.128 HTTP Continuation or non-HTTP traffic
Frame 2097 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 3190, Ack: 531, Len: 1460
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
2098 70.533870 66.91.2.128 129.89.61.70 TCP 3166 > http [ACK] Seq=531 Ack=4650 Win=256960 Len=0
Frame 2098 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FirstInt_41:30:f1 (00:40:ca:41:30:f1), Dst: 24.161.128.1 (00:05:9a:d0:f4:a8)
Internet Protocol, Src: 66.91.2.128 (66.91.2.128), Dst: 129.89.61.70 (129.89.61.70)
Transmission Control Protocol, Src Port: 3166 (3166), Dst Port: http (80), Seq: 531, Ack: 4650, Len: 0
No. Time Source Destination Protocol Info
2099 70.536320 129.89.61.70 66.91.2.128 HTTP Continuation or non-HTTP traffic
Frame 2099 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: FirstInt_41:30:f1 (00:40:ca:41:30:f1)
Internet Protocol, Src: 129.89.61.70 (129.89.61.70), Dst: 66.91.2.128 (66.91.2.128)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3166 (3166), Seq: 4650, Ack: 531, Len: 1460
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
2100 70.540509 24.161.128.1 Broadcast ARP Who has 66.91.1.3? Tell 66.91.0.1
Frame 2100 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)
No. Time Source Destination Protocol Info
2101 70.554891 24.161.128.1 Broadcast ARP Who has 24.161.133.63? Tell 24.161.128.1
Frame 2101 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 24.161.128.1 (00:05:9a:d0:f4:a8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)
No. Time Source Destination Protocol Info
2102 70.647997 66.91.2.128 129.89.61.70 TCP 3166 > http [ACK] Seq=531 Ack=6110 Win=
Then back to "who has". No mention of error 500
I exported as plain text. Haven't tried again, but I'm sure in original Ethereal log Einstein was mentioned, and these entries were color coded.
Have already devoted too much time to this, but will continue fiddling when able.
Brad
"You have confused the true with the real."
RE: Frame 2091 (343 bytes
)
OK, this is probably a scheduler request. From source 66.91.2.128 (cpe-66-91-2-128.hawaii.res.rr.com; IP assigned to you from your provider!?) to
destination 129.89.61.70 (einstein.phys.uwm.edu). Could you post the
entiry HTTP answer here? Should be available in the export.
In case of error I was awaiting something like "500 ERROR". Hm. maybe BOINC
is translating it by itself to error 500, although it was not an HTTP error
500 at all? This HTTP request was OK, indicated by "200 OK".
More HTTP traffic between you and einstein. Now please post the content of the
requests here. Again, they should be in the export file. This is displayed in the GUI too. Select the appropriate entry and have a look at the bottom frame. In the middle frame there are triangle shaped "buttons". Click on them
and they open up more info.
Michael
PS: Waiting for Ageless' black ops death squad.
Team Linux Users Everywhere
