Bug 126104 - Swat not responding to non-local hits
Swat not responding to non-local hits
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
2
All Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-15 22:37 EDT by Bishop Clark
Modified: 2014-08-31 19:26 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-24 03:34:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bishop Clark 2004-06-15 22:37:36 EDT
Description of problem:
When hitting swat from a remote (non-localhost) IP, swat seems to bail
completely and return no data to the caller.

Version-Release number of selected component (if applicable):
samba-3.0.3-5

How reproducible:
Always

Steps to Reproduce:
1.configure /etc/xinetd.d/swat to accept non-local connections:
 - chkconfig swat on
 - patch /etc/xinetd.d/sat << EOF
--- /etc/xinetd.d/swat  2004-06-15 18:53:51.651159864 -0700
+++ -   2004-06-15 19:26:27.657216000 -0700
@@ -7,7 +7,7 @@
        port            = 901
        socket_type     = stream
        wait            = no
-       only_from       = 192.168.21.0 24.68.22.9
+       only_from       = localhost
        user            = root
        server          = /usr/sbin/swat
        log_on_failure  += USERID

 - service xinetd restart
 - iptables -I INPUT -i eth0 -j ACCEPT
   (eth0 is internal interface, eth1 external, 
    to avoid RPC default-iface security problems)

2.  strace -ff -F -p `pidof xinetd`
3.  on other machine, lynx http://swatbox:901
  
Actual results:
Lynx: "Alert!: Unexpected network read error; connection aborted."
Mozilla: status bar: null document returned or connection errors
IE:  apparently similar output

strace:
select(6, [3 5], NULL, NULL, NULL)      = 1 (in [3])
ioctl(3, FIONREAD, [1])                 = 0
read(3, "\21", 1)                       = 1
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 2900
close(-1)                               = -1 EBADF (Bad file descriptor)
waitpid(-1, 0xfef1dd48, WNOHANG)        = -1 ECHILD (No child processes)
select(6, [3 5], NULL, NULL, NULL)      = 1 (in [5])
accept(5, {sa_family=AF_INET, sin_port=htons(3676),
sin_addr=inet_addr("192.168.21.100")}, [16]) = 7
time(NULL)                              = 1087351006
clone(Process 2901 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf70552e8) = 2901
[pid  2865] time([1087351006])          = 1087351006
[pid  2865] close(7)                    = 0
select(6, [3 5], NULL, NULL, NULL
...

Expected results:

 - login required
 - login
 - swat iface

Additional info:

 - logging in via lynx from localhost appeas to work, when
configuration (xinetd, iptables) is set to allow it.

 - grep SELINUX /etc/sysconfig/selinux  (ugh)
   SELINUX=disabled

End Customer (not me) generally disillusioned/disappointed with FC2,
may revert to FC1 or Conectiva/PLD (avoiding MDK/PLD/SuSE/$$$) for
SOHO gateway within short period of time.  Thus, short window of
relevance.  Will advise and close ticket/INVALID if customer moves and
no CCs/MeToos on Bz by then.
Comment 1 Steven Foggitt 2004-06-16 03:22:59 EDT
I am having the same issue. Would like to support FC 2 but I am
finding it hard to stay. Just too many issues to deal with.
Comment 2 Alan Cox 2004-06-19 08:44:01 EDT
Works for me. Make sure you also turned disabled=yes into disabled=no in 
/etc/xinetd.d/swat
Comment 3 Bishop Clark 2004-06-19 21:33:29 EDT
Thanks for the bad news, Alan.  Yeah, I've un-disabled the xinetd
profile (or shouldn't the Select() return?) .

Now we get to find out why yours works and mine does not.  Classic
install, too.  I don't have a whack of hardware spare in the home
office, but I may roll a machine together and get an install going
myself, just to replicate this problem and get some repro instructions
together.
Comment 4 Bishop Clark 2004-06-24 03:34:19 EDT
the user in question has reverted to FC1.  I'll reopen when I get
another spare box to cook up an FC2 install here (or bug 115980 is
closed).

Closing pending repro.  Too bad I can't close:withdrawn.

Note You need to log in before you can comment on or make changes to this bug.