On Wed, 14 Jul 2004, electa wrote: > I have Zonealarm Security Suite > > I give all requested rights to X program when they asked them, that is: > Bash.exe access Internet and Trusted > xinit.exe access Internet and Trusted > xterm.exe access Internet and Trusted > Xwin.exe access Internet and Trusted and listen as server in Internet and > Trusted > > (And i still think that they do not need all of this, > in fact access to localhost (127.0.0.1) should be enough for X programs...) > > Can you show me these incrimined lines of log?
from my log: ********************************************** Program name: C:\cygwin\bin\sh.exe (3820) App version: 1005.10, api: 0.116 DLL version: 1005.10, api: 0.116 DLL build: 2004-06-15 14:34 OS version: Windows NT-5.0 Heap size: 402653184 Date/Time: 2004-07-13 18:40:53 ********************************************** 101 808 [main] sh 3820 fhandler_socket::fixup_after_exec: here 65 873 [main] sh 3820 fhandler_socket::fixup_after_fork: WSASocket begin, dwServiceFlags1=131174 3760 4633 [main] sh 3820 wsock_init: res 0 194 4827 [main] sh 3820 wsock_init: wVersion 514 62 4889 [main] sh 3820 wsock_init: wHighVersion 514 59 4948 [main] sh 3820 wsock_init: szDescription WinSock 2.0 57 5005 [main] sh 3820 wsock_init: szSystemStatus Running 57 5062 [main] sh 3820 wsock_init: iMaxSockets 0 53 5115 [main] sh 3820 wsock_init: iMaxUdpDg 0 52 5167 [main] sh 3820 wsock_init: lpVendorInfo 0 5437 10604 [main] sh 3820 fhandler_socket::fixup_after_fork: WSASocket went fine new_sock 0x3EC, old_sock 0x3E8 150 10754 [main] sh 3820 fhandler_socket::fixup_after_exec: here 87 10841 [main] sh 3820 fhandler_socket::fixup_after_fork: WSASocket begin, dwServiceFlags1=131174 105 10946 [main] sh 3820 fhandler_socket::fixup_after_fork: WSASocket went fine new_sock 0x3E0, old_sock 0x3E4 129 11075 [main] sh 3820 events_init: windows_system_directory 'C:\WINNT\system32\', windows_system_directory_length 18 149 11224 [main] sh 3820 _cygwin_istext_for_stdio: fd 0: opened as binary 64 11288 [main] sh 3820 _cygwin_istext_for_stdio: fd 1: opened as binary 56 11344 [main] sh 3820 _cygwin_istext_for_stdio: fd 2: opened as binary from your's: ********************************************** Program name: C:\Programmi\cygwin\bin\sh.exe (2116) App version: 1005.10, api: 0.116 DLL version: 1005.10, api: 0.116 DLL build: 2004-05-25 22:07 OS version: Windows NT-5.1 Heap size: 402653184 Date/Time: 2004-07-14 14:44:55 ********************************************** 100 364 [main] sh 2116 open_shared: name (null), shared 0xA020000 (wanted 0xA020000), h 0x6FC 55 419 [main] sh 2116 fhandler_base::set_flags: flags 0x18002, supplied_bin 0x0 32 451 [main] sh 2116 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 27 478 [main] sh 2116 fhandler_base::set_flags: filemode set to binary 770 1248 [main] sh 2116 fhandler_console::open: incremented open_fhs, now 2 75 1323 [main] sh 2116 fhandler_console::open: opened conin$ 0xB, conout$ 0x2B 70 1393 [main] sh 2116 fhandler_base::set_flags: flags 0x18002, supplied_bin 0x0 31 1424 [main] sh 2116 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000 26 1450 [main] sh 2116 fhandler_base::set_flags: filemode set to binary 104 1554 [main] sh 2116 fhandler_console::open: incremented open_fhs, now 2 36 1590 [main] sh 2116 fhandler_console::open: opened conin$ 0x13, conout$ 0x2F 66 1656 [main] sh 2116 fhandler_socket::fixup_after_exec: here 798 2454 [main] sh 2116 fhandler_socket::fixup_after_fork: WSASocket begin, dwServiceFlags1=102 13667 16121 [main] sh 2116 wsock_init: res 0 176 16297 [main] sh 2116 wsock_init: wVersion 514 34 16331 [main] sh 2116 wsock_init: wHighVersion 514 30 16361 [main] sh 2116 wsock_init: szDescription WinSock 2.0 26 16387 [main] sh 2116 wsock_init: szSystemStatus Running 26 16413 [main] sh 2116 wsock_init: iMaxSockets 0 26 16439 [main] sh 2116 wsock_init: iMaxUdpDg 0 25 16464 [main] sh 2116 wsock_init: lpVendorInfo 0 after this line the log ends. It seems it can not setup that socket correctly which lead me to the assumption you have ZoneAlarm. ZoneAlarm is known to change the behaviour of Windows TCP/IP stack and this seems to cause troubles with cygwin since cygwin must provide unix like semantics and has problems if something does not work it was expected. So it is not a problem with insufficient rights to access the network (in fact xkbcomp does not need any network access) but a problem with different/unexpected behaviour of windows subsystems. I doubt this can be solved without digging into the startup code of the cygwin library where it stopped bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723