[Samba] Samba and the InterWeb - Samba

This is a discussion on [Samba] Samba and the InterWeb - Samba ; Hi, We have an office-based Windows-locked publishing system whose only delivery mechanism is to write to a local filesystem, and a requirement for its output to be available to a collocated production environment comprising Solaris and Linux boxes. The 'obvious' ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: [Samba] Samba and the InterWeb

  1. [Samba] Samba and the InterWeb

    Hi,

    We have an office-based Windows-locked publishing system whose only
    delivery mechanism is to write to a local filesystem, and a requirement
    for its output to be available to a collocated production environment
    comprising Solaris and Linux boxes. The 'obvious' solution was to run a
    Samba server on one of the collocated Linux boxes and mount the share it
    provides on the relevant Windows machines in the office. And this is
    what I have done. This works, but encounters the problem I am about to
    describe.

    SCENARIO ONE:

    Connecting to the server/share in Explorer (Windows XP) by typing the
    path (\\dns.host.name\share) into the address bar is accomplished
    without problem, as is receiving a directory listing. But uploading a
    file to the remote share (by drag and dropping) causes Explorer to
    freeze for anything between 10 and 30 seconds after which the file
    transfers at good speed.

    SCENARIO TWO:

    Map the remote share, using same connection details. Now copy is often
    fine, but sometimes will just fail with a "Cannot copy
    : The specified network name is no longer available." and
    leave a zero-length file at the remote end.

    Not infrequently, smbd processes are being left in an 'uninterruptible
    sleep' state.

    If I mount the remote share via smbmount onto a Linux server in the
    office, I don't encounter any of these problems.

    Packet-sniffing on scenario one shows that the pause is happening before
    any set-up for the file transfer: it looks like the client
    disconnects, then there's a pause, then it reconnects.

    I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4. Clients
    are Windows XP Pro. Our office has a fairly large and complex LAN which
    is managed by a separate department. Access to the Internet is, not
    surprisingly, via a NATting gateway. Appropriate ports have been opened
    in the firewalls, though all communication is in Direct-hosted mode (ie,
    I only see traffic on port 445/tcp).

    smb.conf looks like this:

    [global]

    workgroup = WG123
    netbios name = n2323 # hostname of server
    server string = FOO-BAR-Samba

    #wins proxy = yes
    #wins server = xxx.xx.xx.x

    security = user
    passdb backend = tdbsam

    load printers = no

    # idle time (mins) before client is disconnected
    dead time = 15
    keepalive = 10
    socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
    inherit permissions = yes

    [test-xml]
    path = /stuff/test-xml
    writeable = Yes
    public = no

    Could anyone suggest what might be going on here?

    Thanks,

    Alex.
    --
    Alex Hooper | www.bmjpg.com
    Systems and Database Administration | ahooper@bmjgroup.com
    BMJ Knowledge, BMJ Publishing Group | +44 20 7383 6049
    BMA House, LONDON, WC1H 9JR |


    __________________________________________________ _____________________
    The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses. Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ Group. A private limited company, registered in England and Wales under registration number 03102371. Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK.
    __________________________________________________ _____________________
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  2. Re: [Samba] Samba and the InterWeb

    Alex Hooper wrote:
    > Hi,
    >
    > We have an office-based Windows-locked publishing system whose only
    > delivery mechanism is to write to a local filesystem, and a
    > requirement for its output to be available to a collocated production
    > environment comprising Solaris and Linux boxes. The 'obvious' solution
    > was to run a Samba server on one of the collocated Linux boxes and
    > mount the share it provides on the relevant Windows machines in the
    > office. And this is what I have done. This works, but encounters the
    > problem I am about to describe.
    >
    > SCENARIO ONE:
    >
    > Connecting to the server/share in Explorer (Windows XP) by typing the
    > path (\\dns.host.name\share) into the address bar is accomplished
    > without problem, as is receiving a directory listing. But uploading a
    > file to the remote share (by drag and dropping) causes Explorer to
    > freeze for anything between 10 and 30 seconds after which the file
    > transfers at good speed.
    >
    > SCENARIO TWO:
    >
    > Map the remote share, using same connection details. Now copy is often
    > fine, but sometimes will just fail with a "Cannot copy
    > : The specified network name is no longer available." and
    > leave a zero-length file at the remote end.
    >
    > Not infrequently, smbd processes are being left in an 'uninterruptible
    > sleep' state.
    >
    > If I mount the remote share via smbmount onto a Linux server in the
    > office, I don't encounter any of these problems.
    >
    > Packet-sniffing on scenario one shows that the pause is happening
    > before any set-up for the file transfer: it looks like the client
    > disconnects, then there's a pause, then it reconnects.
    >
    > I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4.
    > Clients are Windows XP Pro. Our office has a fairly large and complex
    > LAN which is managed by a separate department. Access to the Internet
    > is, not surprisingly, via a NATting gateway. Appropriate ports have
    > been opened in the firewalls, though all communication is in
    > Direct-hosted mode (ie, I only see traffic on port 445/tcp).
    >
    > smb.conf looks like this:
    >
    > [global]
    >
    > workgroup = WG123
    > netbios name = n2323 # hostname of server
    > server string = FOO-BAR-Samba
    >
    > #wins proxy = yes
    > #wins server = xxx.xx.xx.x
    >
    > security = user
    > passdb backend = tdbsam
    >
    > load printers = no
    >
    > # idle time (mins) before client is disconnected
    > dead time = 15
    > keepalive = 10
    > socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
    > inherit permissions = yes
    >
    > [test-xml]
    > path = /stuff/test-xml
    > writeable = Yes
    > public = no
    >
    > Could anyone suggest what might be going on here?
    >
    > Thanks,
    >
    > Alex.

    On scenario1, is it (Windows client) trying to connect to port 445 on
    the server, being dropped instead of rejected, timing out, and then
    establishing a connection on port 139? I think by default Windows tries
    to connect to both at the same time or something weird like that.


    On scenario2, I've seen behavior something akin to this on a corrupted
    e1000 kernel module. I've also seen bad cables (twice where gigabit and
    mii are concerned, IIRC) that behave all kinds of weird, at any given
    moment.

    Anyways, FWIW, how does your 'netstat -s' output look? Are you getting
    a considerable number of connection resets being sent or received?

    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  3. Re: [Samba] Samba and the InterWeb

    Scott Lovenberg uttered:
    > Alex Hooper wrote:
    >> Hi,
    >>
    >> We have an office-based Windows-locked publishing system whose only
    >> delivery mechanism is to write to a local filesystem, and a
    >> requirement for its output to be available to a collocated production
    >> environment comprising Solaris and Linux boxes. The 'obvious' solution
    >> was to run a Samba server on one of the collocated Linux boxes and
    >> mount the share it provides on the relevant Windows machines in the
    >> office. And this is what I have done. This works, but encounters the
    >> problem I am about to describe.
    >>
    >> SCENARIO ONE:
    >>
    >> Connecting to the server/share in Explorer (Windows XP) by typing the
    >> path (\\dns.host.name\share) into the address bar is accomplished
    >> without problem, as is receiving a directory listing. But uploading a
    >> file to the remote share (by drag and dropping) causes Explorer to
    >> freeze for anything between 10 and 30 seconds after which the file
    >> transfers at good speed.
    >>
    >> SCENARIO TWO:
    >>
    >> Map the remote share, using same connection details. Now copy is often
    >> fine, but sometimes will just fail with a "Cannot copy
    >> : The specified network name is no longer available." and
    >> leave a zero-length file at the remote end.
    >>
    >> Not infrequently, smbd processes are being left in an 'uninterruptible
    >> sleep' state.
    >>
    >> If I mount the remote share via smbmount onto a Linux server in the
    >> office, I don't encounter any of these problems.
    >>
    >> Packet-sniffing on scenario one shows that the pause is happening
    >> before any set-up for the file transfer: it looks like the client
    >> disconnects, then there's a pause, then it reconnects.
    >>
    >> I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4.
    >> Clients are Windows XP Pro. Our office has a fairly large and complex
    >> LAN which is managed by a separate department. Access to the Internet
    >> is, not surprisingly, via a NATting gateway. Appropriate ports have
    >> been opened in the firewalls, though all communication is in
    >> Direct-hosted mode (ie, I only see traffic on port 445/tcp).
    >>
    >> smb.conf looks like this:
    >>
    >> [global]
    >>
    >> workgroup = WG123
    >> netbios name = n2323 # hostname of server
    >> server string = FOO-BAR-Samba
    >>
    >> #wins proxy = yes
    >> #wins server = xxx.xx.xx.x
    >>
    >> security = user
    >> passdb backend = tdbsam
    >>
    >> load printers = no
    >>
    >> # idle time (mins) before client is disconnected
    >> dead time = 15
    >> keepalive = 10
    >> socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
    >> inherit permissions = yes
    >>
    >> [test-xml]
    >> path = /stuff/test-xml
    >> writeable = Yes
    >> public = no
    >>
    >> Could anyone suggest what might be going on here?
    >>
    >> Thanks,
    >>
    >> Alex.

    > On scenario1, is it (Windows client) trying to connect to port 445 on
    > the server, being dropped instead of rejected, timing out, and then
    > establishing a connection on port 139? I think by default Windows tries
    > to connect to both at the same time or something weird like that.
    >


    No. There is no attempt to use port 139: only 445 is approached.

    >
    > On scenario2, I've seen behavior something akin to this on a corrupted
    > e1000 kernel module. I've also seen bad cables (twice where gigabit and
    > mii are concerned, IIRC) that behave all kinds of weird, at any given
    > moment.
    >


    The server's using the bnx2 module and the NIC is at 100MB FD. I'm not
    noting any other network weirdness, which would seem to suggest cabling
    is probably OK, wouldn't it?

    > Anyways, FWIW, how does your 'netstat -s' output look? Are you getting
    > a considerable number of connection resets being sent or received?
    >


    No. All the "reset sent"s in the diff below belong to an unrelated
    application. In the time between the two netstats compared below,
    various stalling transfers were made and one "network name is no longer
    available" was received:

    # diff -Bub /root/netstat-20080213-0939 /root/netstat-20080213-1016
    --- /root/netstat-20080213-0939 2008-02-13 09:39:24.000000000 +0000
    +++ /root/netstat-20080213-1016 2008-02-13 10:16:34.000000000 +0000
    @@ -1,43 +1,44 @@
    Ip:
    - 4336 total packets received
    + 21933 total packets received
    0 forwarded
    0 incoming packets discarded
    - 4335 incoming packets delivered
    - 4134 requests sent out
    + 20292 incoming packets delivered
    + 19069 requests sent out
    Icmp:
    - 26 ICMP messages received
    + 92 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
    - echo requests: 26
    - 26 ICMP messages sent
    + echo requests: 92
    + 92 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
    - echo replies: 26
    + echo replies: 92
    Tcp:
    - 6 active connections openings
    - 161 passive connection openings
    + 11 active connections openings
    + 169 passive connection openings
    0 failed connection attempts
    - 0 connection resets received
    - 93 connections established
    - 4176 segments received
    - 3992 segments send out
    + 1 connection resets received
    + 97 connections established
    + 18529 segments received
    + 17417 segments send out
    0 segments retransmited
    0 bad segments received.
    - 259 resets sent
    + 333 resets sent
    Udp:
    - 132 packets received
    + 1663 packets received
    0 packets to unknown port received.
    0 packet receive errors
    - 116 packets sent
    + 1560 packets sent
    TcpExt:
    ArpFilter: 0
    - 74 TCP sockets finished time wait in fast timer
    - 18 delayed acks sent
    - 3191 packets directly queued to recvmsg prequeue.
    - 396 packets directly received from prequeue
    - 2006 packets header predicted
    - TCPPureAcks: 969
    - TCPHPAcks: 1773
    + 78 TCP sockets finished time wait in fast timer
    + 880 delayed acks sent
    + 14318 packets directly queued to recvmsg prequeue.
    + 1431219 packets directly received from prequeue
    + 10014 packets header predicted
    + 1063 packets header predicted and directly queued to user
    + TCPPureAcks: 1612
    + TCPHPAcks: 10445
    TCPRenoRecovery: 0
    TCPSackRecovery: 0
    TCPSACKReneging: 0
    --
    Alex Hooper | www.bmjpg.com
    Systems and Database Administration | ahooper@bmjgroup.com
    BMJ Knowledge, BMJ Publishing Group | +44 20 7383 6049
    BMA House, LONDON, WC1H 9JR |


    __________________________________________________ _____________________
    The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses. Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ Group. A private limited company, registered in England and Wales under registration number 03102371. Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK.
    __________________________________________________ _____________________
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  4. [Samba] Re: Samba and the InterWeb

    Alex Hooper wrote:
    > Scott Lovenberg uttered:
    >> Alex Hooper wrote:
    >>> Hi,
    >>>
    >>> We have an office-based Windows-locked publishing system whose only
    >>> delivery mechanism is to write to a local filesystem, and a
    >>> requirement for its output to be available to a collocated production
    >>> environment comprising Solaris and Linux boxes. The 'obvious'
    >>> solution was to run a Samba server on one of the collocated Linux
    >>> boxes and mount the share it provides on the relevant Windows
    >>> machines in the office. And this is what I have done. This works, but
    >>> encounters the problem I am about to describe.
    >>>
    >>> SCENARIO ONE:
    >>>
    >>> Connecting to the server/share in Explorer (Windows XP) by typing the
    >>> path (\\dns.host.name\share) into the address bar is accomplished
    >>> without problem, as is receiving a directory listing. But uploading a
    >>> file to the remote share (by drag and dropping) causes Explorer to
    >>> freeze for anything between 10 and 30 seconds after which the file
    >>> transfers at good speed.
    >>>
    >>> SCENARIO TWO:
    >>>
    >>> Map the remote share, using same connection details. Now copy is
    >>> often fine, but sometimes will just fail with a "Cannot copy
    >>> : The specified network name is no longer available." and
    >>> leave a zero-length file at the remote end.
    >>>
    >>> Not infrequently, smbd processes are being left in an
    >>> 'uninterruptible sleep' state.
    >>>
    >>> If I mount the remote share via smbmount onto a Linux server in the
    >>> office, I don't encounter any of these problems.
    >>>
    >>> Packet-sniffing on scenario one shows that the pause is happening
    >>> before any set-up for the file transfer: it looks like the client
    >>> disconnects, then there's a pause, then it reconnects.
    >>>
    >>> I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4.
    >>> Clients are Windows XP Pro. Our office has a fairly large and complex
    >>> LAN which is managed by a separate department. Access to the Internet
    >>> is, not surprisingly, via a NATting gateway. Appropriate ports have
    >>> been opened in the firewalls, though all communication is in
    >>> Direct-hosted mode (ie, I only see traffic on port 445/tcp).
    >>>
    >>> smb.conf looks like this:
    >>>
    >>> [global]
    >>>
    >>> workgroup = WG123
    >>> netbios name = n2323 # hostname of server
    >>> server string = FOO-BAR-Samba
    >>>
    >>> #wins proxy = yes
    >>> #wins server = xxx.xx.xx.x
    >>>
    >>> security = user
    >>> passdb backend = tdbsam
    >>>
    >>> load printers = no
    >>>
    >>> # idle time (mins) before client is disconnected
    >>> dead time = 15
    >>> keepalive = 10
    >>> socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
    >>> inherit permissions = yes
    >>>
    >>> [test-xml]
    >>> path = /stuff/test-xml
    >>> writeable = Yes
    >>> public = no
    >>>
    >>> Could anyone suggest what might be going on here?
    >>>
    >>> Thanks,
    >>>
    >>> Alex.

    >> On scenario1, is it (Windows client) trying to connect to port 445 on
    >> the server, being dropped instead of rejected, timing out, and then
    >> establishing a connection on port 139? I think by default Windows
    >> tries to connect to both at the same time or something weird like that.
    >>

    >
    > No. There is no attempt to use port 139: only 445 is approached.
    >
    >>
    >> On scenario2, I've seen behavior something akin to this on a corrupted
    >> e1000 kernel module. I've also seen bad cables (twice where gigabit
    >> and mii are concerned, IIRC) that behave all kinds of weird, at any
    >> given moment.
    >>

    >
    > The server's using the bnx2 module and the NIC is at 100MB FD. I'm not
    > noting any other network weirdness, which would seem to suggest cabling
    > is probably OK, wouldn't it?
    >

    I once heard a quote (which I'd like to attribute to Jeremy Allison
    for some reason) to the effect of "The Windows SMB network stack is like
    a canary in a coal mine, when you have network troubles it's the first
    thing to die." I could get everything else to work just fine with this
    driver, but SMB/CIFS just kept flaking out. So, I always try to trace a
    problem starting from the wall back.

    >> Anyways, FWIW, how does your 'netstat -s' output look? Are you
    >> getting a considerable number of connection resets being sent or
    >> received?
    >>

    >
    > No. All the "reset sent"s in the diff below belong to an unrelated
    > application. In the time between the two netstats compared below,
    > various stalling transfers were made and one "network name is no longer
    > available" was received:
    >
    > # diff -Bub /root/netstat-20080213-0939 /root/netstat-20080213-1016
    > --- /root/netstat-20080213-0939 2008-02-13 09:39:24.000000000 +0000
    > +++ /root/netstat-20080213-1016 2008-02-13 10:16:34.000000000 +0000
    > @@ -1,43 +1,44 @@
    > Ip:
    > - 4336 total packets received
    > + 21933 total packets received
    > 0 forwarded
    > 0 incoming packets discarded
    > - 4335 incoming packets delivered
    > - 4134 requests sent out
    > + 20292 incoming packets delivered
    > + 19069 requests sent out
    > Icmp:
    > - 26 ICMP messages received
    > + 92 ICMP messages received
    > 0 input ICMP message failed.
    > ICMP input histogram:
    > - echo requests: 26
    > - 26 ICMP messages sent
    > + echo requests: 92
    > + 92 ICMP messages sent
    > 0 ICMP messages failed
    > ICMP output histogram:
    > - echo replies: 26
    > + echo replies: 92
    > Tcp:
    > - 6 active connections openings
    > - 161 passive connection openings
    > + 11 active connections openings
    > + 169 passive connection openings
    > 0 failed connection attempts
    > - 0 connection resets received
    > - 93 connections established
    > - 4176 segments received
    > - 3992 segments send out
    > + 1 connection resets received


    Hrm... the client reset. Do you have a wire sniff to see what is going
    on right before the client sends a reset?

    > + 97 connections established
    > + 18529 segments received
    > + 17417 segments send out
    > 0 segments retransmited
    > 0 bad segments received.
    > - 259 resets sent
    > + 333 resets sent
    > Udp:
    > - 132 packets received
    > + 1663 packets received
    > 0 packets to unknown port received.
    > 0 packet receive errors
    > - 116 packets sent
    > + 1560 packets sent
    > TcpExt:
    > ArpFilter: 0
    > - 74 TCP sockets finished time wait in fast timer
    > - 18 delayed acks sent
    > - 3191 packets directly queued to recvmsg prequeue.
    > - 396 packets directly received from prequeue
    > - 2006 packets header predicted
    > - TCPPureAcks: 969
    > - TCPHPAcks: 1773
    > + 78 TCP sockets finished time wait in fast timer
    > + 880 delayed acks sent
    > + 14318 packets directly queued to recvmsg prequeue.
    > + 1431219 packets directly received from prequeue
    > + 10014 packets header predicted
    > + 1063 packets header predicted and directly queued to user
    > + TCPPureAcks: 1612
    > + TCPHPAcks: 10445
    > TCPRenoRecovery: 0
    > TCPSackRecovery: 0
    > TCPSACKReneging: 0


    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  5. Re: [Samba] Re: Samba and the InterWeb

    On Wed, Feb 13, 2008 at 11:34:13AM -0500, Scott Lovenberg wrote:

    > I once heard a quote (which I'd like to attribute to Jeremy Allison for
    > some reason) to the effect of "The Windows SMB network stack is like a
    > canary in a coal mine, when you have network troubles it's the first thing
    > to die."


    Wow - great quote ! Not mine though :-). Wish I'd thought of it :-).

    Cheers,

    Jeremy.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  6. Re: [Samba] Re: Samba and the InterWeb

    Scott Lovenberg uttered:
    > Alex Hooper wrote:
    >> Scott Lovenberg uttered:
    >>> Alex Hooper wrote:
    >>>> Hi,
    >>>>
    >>>> We have an office-based Windows-locked publishing system whose only
    >>>> delivery mechanism is to write to a local filesystem, and a
    >>>> requirement for its output to be available to a collocated
    >>>> production environment comprising Solaris and Linux boxes. The
    >>>> 'obvious' solution was to run a Samba server on one of the
    >>>> collocated Linux boxes and mount the share it provides on the
    >>>> relevant Windows machines in the office. And this is what I have
    >>>> done. This works, but encounters the problem I am about to describe.
    >>>>
    >>>> SCENARIO ONE:
    >>>>
    >>>> Connecting to the server/share in Explorer (Windows XP) by typing
    >>>> the path (\\dns.host.name\share) into the address bar is
    >>>> accomplished without problem, as is receiving a directory listing.
    >>>> But uploading a file to the remote share (by drag and dropping)
    >>>> causes Explorer to freeze for anything between 10 and 30 seconds
    >>>> after which the file transfers at good speed.
    >>>>
    >>>> SCENARIO TWO:
    >>>>
    >>>> Map the remote share, using same connection details. Now copy is
    >>>> often fine, but sometimes will just fail with a "Cannot copy
    >>>> : The specified network name is no longer available." and
    >>>> leave a zero-length file at the remote end.
    >>>>
    >>>> Not infrequently, smbd processes are being left in an
    >>>> 'uninterruptible sleep' state.
    >>>>
    >>>> If I mount the remote share via smbmount onto a Linux server in the
    >>>> office, I don't encounter any of these problems.
    >>>>
    >>>> Packet-sniffing on scenario one shows that the pause is happening
    >>>> before any set-up for the file transfer: it looks like the client
    >>>> disconnects, then there's a pause, then it reconnects.
    >>>>
    >>>> I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4.
    >>>> Clients are Windows XP Pro. Our office has a fairly large and
    >>>> complex LAN which is managed by a separate department. Access to the
    >>>> Internet is, not surprisingly, via a NATting gateway. Appropriate
    >>>> ports have been opened in the firewalls, though all communication is
    >>>> in Direct-hosted mode (ie, I only see traffic on port 445/tcp).
    >>>>
    >>>> smb.conf looks like this:
    >>>>
    >>>> [global]
    >>>>
    >>>> workgroup = WG123
    >>>> netbios name = n2323 # hostname of server
    >>>> server string = FOO-BAR-Samba
    >>>>
    >>>> #wins proxy = yes
    >>>> #wins server = xxx.xx.xx.x
    >>>>
    >>>> security = user
    >>>> passdb backend = tdbsam
    >>>>
    >>>> load printers = no
    >>>>
    >>>> # idle time (mins) before client is disconnected
    >>>> dead time = 15
    >>>> keepalive = 10
    >>>> socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
    >>>> inherit permissions = yes
    >>>>
    >>>> [test-xml]
    >>>> path = /stuff/test-xml
    >>>> writeable = Yes
    >>>> public = no
    >>>>
    >>>> Could anyone suggest what might be going on here?
    >>>>
    >>>> Thanks,
    >>>>
    >>>> Alex.
    >>> On scenario1, is it (Windows client) trying to connect to port 445 on
    >>> the server, being dropped instead of rejected, timing out, and then
    >>> establishing a connection on port 139? I think by default Windows
    >>> tries to connect to both at the same time or something weird like that.
    >>>

    >>
    >> No. There is no attempt to use port 139: only 445 is approached.
    >>
    >>>
    >>> On scenario2, I've seen behavior something akin to this on a
    >>> corrupted e1000 kernel module. I've also seen bad cables (twice
    >>> where gigabit and mii are concerned, IIRC) that behave all kinds of
    >>> weird, at any given moment.
    >>>

    >>
    >> The server's using the bnx2 module and the NIC is at 100MB FD. I'm not
    >> noting any other network weirdness, which would seem to suggest
    >> cabling is probably OK, wouldn't it?
    >>

    > I once heard a quote (which I'd like to attribute to Jeremy Allison for
    > some reason) to the effect of "The Windows SMB network stack is like a
    > canary in a coal mine, when you have network troubles it's the first
    > thing to die." I could get everything else to work just fine with this
    > driver, but SMB/CIFS just kept flaking out. So, I always try to trace a
    > problem starting from the wall back.
    >
    >>> Anyways, FWIW, how does your 'netstat -s' output look? Are you
    >>> getting a considerable number of connection resets being sent or
    >>> received?
    >>>

    >>
    >> No. All the "reset sent"s in the diff below belong to an unrelated
    >> application. In the time between the two netstats compared below,
    >> various stalling transfers were made and one "network name is no
    >> longer available" was received:
    >>
    >> # diff -Bub /root/netstat-20080213-0939 /root/netstat-20080213-1016
    >> --- /root/netstat-20080213-0939 2008-02-13 09:39:24.000000000 +0000
    >> +++ /root/netstat-20080213-1016 2008-02-13 10:16:34.000000000 +0000
    >> @@ -1,43 +1,44 @@
    >> Ip:
    >> - 4336 total packets received
    >> + 21933 total packets received
    >> 0 forwarded
    >> 0 incoming packets discarded
    >> - 4335 incoming packets delivered
    >> - 4134 requests sent out
    >> + 20292 incoming packets delivered
    >> + 19069 requests sent out
    >> Icmp:
    >> - 26 ICMP messages received
    >> + 92 ICMP messages received
    >> 0 input ICMP message failed.
    >> ICMP input histogram:
    >> - echo requests: 26
    >> - 26 ICMP messages sent
    >> + echo requests: 92
    >> + 92 ICMP messages sent
    >> 0 ICMP messages failed
    >> ICMP output histogram:
    >> - echo replies: 26
    >> + echo replies: 92
    >> Tcp:
    >> - 6 active connections openings
    >> - 161 passive connection openings
    >> + 11 active connections openings
    >> + 169 passive connection openings
    >> 0 failed connection attempts
    >> - 0 connection resets received
    >> - 93 connections established
    >> - 4176 segments received
    >> - 3992 segments send out
    >> + 1 connection resets received

    >
    > Hrm... the client reset. Do you have a wire sniff to see what is going
    > on right before the client sends a reset?
    >

    Hi,

    I've put one at
    http://www.oops.org.uk/misc/transfer...3-reset02.pcap

    I'm unable to extract useful clue from it, though brain fog is building
    up here. I'm starting to consider publishing to an internal machine and
    syncing with SCP or rsync. Feels hacky, though.

    Cheers,
    --
    Alex Hooper | www.bmjpg.com
    Systems and Database Administration | ahooper@bmjgroup.com
    BMJ Knowledge, BMJ Publishing Group | +44 20 7383 6049
    BMA House, LONDON, WC1H 9JR |


    __________________________________________________ _____________________
    The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses. Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ Group. A private limited company, registered in England and Wales under registration number 03102371. Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK.
    __________________________________________________ _____________________
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  7. [Samba] Re: Samba and the InterWeb

    Alex Hooper wrote:
    > Scott Lovenberg uttered:
    >> Alex Hooper wrote:
    >>> Scott Lovenberg uttered:
    >>>> Alex Hooper wrote:
    >>>>> Hi,
    >>>>>
    >>>>> We have an office-based Windows-locked publishing system whose only
    >>>>> delivery mechanism is to write to a local filesystem, and a
    >>>>> requirement for its output to be available to a collocated
    >>>>> production environment comprising Solaris and Linux boxes. The
    >>>>> 'obvious' solution was to run a Samba server on one of the
    >>>>> collocated Linux boxes and mount the share it provides on the
    >>>>> relevant Windows machines in the office. And this is what I have
    >>>>> done. This works, but encounters the problem I am about to describe.
    >>>>>
    >>>>> SCENARIO ONE:
    >>>>>
    >>>>> Connecting to the server/share in Explorer (Windows XP) by typing
    >>>>> the path (\\dns.host.name\share) into the address bar is
    >>>>> accomplished without problem, as is receiving a directory listing.
    >>>>> But uploading a file to the remote share (by drag and dropping)
    >>>>> causes Explorer to freeze for anything between 10 and 30 seconds
    >>>>> after which the file transfers at good speed.
    >>>>>
    >>>>> SCENARIO TWO:
    >>>>>
    >>>>> Map the remote share, using same connection details. Now copy is
    >>>>> often fine, but sometimes will just fail with a "Cannot copy
    >>>>> : The specified network name is no longer available." and
    >>>>> leave a zero-length file at the remote end.
    >>>>>
    >>>>> Not infrequently, smbd processes are being left in an
    >>>>> 'uninterruptible sleep' state.
    >>>>>
    >>>>> If I mount the remote share via smbmount onto a Linux server in the
    >>>>> office, I don't encounter any of these problems.
    >>>>>
    >>>>> Packet-sniffing on scenario one shows that the pause is happening
    >>>>> before any set-up for the file transfer: it looks like the client
    >>>>> disconnects, then there's a pause, then it reconnects.
    >>>>>
    >>>>> I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4.
    >>>>> Clients are Windows XP Pro. Our office has a fairly large and
    >>>>> complex LAN which is managed by a separate department. Access to
    >>>>> the Internet is, not surprisingly, via a NATting gateway.
    >>>>> Appropriate ports have been opened in the firewalls, though all
    >>>>> communication is in Direct-hosted mode (ie, I only see traffic on
    >>>>> port 445/tcp).
    >>>>>
    >>>>> smb.conf looks like this:
    >>>>>
    >>>>> [global]
    >>>>>
    >>>>> workgroup = WG123
    >>>>> netbios name = n2323 # hostname of server
    >>>>> server string = FOO-BAR-Samba
    >>>>>
    >>>>> #wins proxy = yes
    >>>>> #wins server = xxx.xx.xx.x
    >>>>>
    >>>>> security = user
    >>>>> passdb backend = tdbsam
    >>>>>
    >>>>> load printers = no
    >>>>>
    >>>>> # idle time (mins) before client is disconnected
    >>>>> dead time = 15
    >>>>> keepalive = 10
    >>>>> socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
    >>>>> inherit permissions = yes
    >>>>>
    >>>>> [test-xml]
    >>>>> path = /stuff/test-xml
    >>>>> writeable = Yes
    >>>>> public = no
    >>>>>
    >>>>> Could anyone suggest what might be going on here?
    >>>>>
    >>>>> Thanks,
    >>>>>
    >>>>> Alex.
    >>>> On scenario1, is it (Windows client) trying to connect to port 445
    >>>> on the server, being dropped instead of rejected, timing out, and
    >>>> then establishing a connection on port 139? I think by default
    >>>> Windows tries to connect to both at the same time or something weird
    >>>> like that.
    >>>>
    >>>
    >>> No. There is no attempt to use port 139: only 445 is approached.
    >>>
    >>>>
    >>>> On scenario2, I've seen behavior something akin to this on a
    >>>> corrupted e1000 kernel module. I've also seen bad cables (twice
    >>>> where gigabit and mii are concerned, IIRC) that behave all kinds of
    >>>> weird, at any given moment.
    >>>>
    >>>
    >>> The server's using the bnx2 module and the NIC is at 100MB FD. I'm
    >>> not noting any other network weirdness, which would seem to suggest
    >>> cabling is probably OK, wouldn't it?
    >>>

    >> I once heard a quote (which I'd like to attribute to Jeremy Allison
    >> for some reason) to the effect of "The Windows SMB network stack is
    >> like a canary in a coal mine, when you have network troubles it's the
    >> first thing to die." I could get everything else to work just fine
    >> with this driver, but SMB/CIFS just kept flaking out. So, I always
    >> try to trace a problem starting from the wall back.
    >>
    >>>> Anyways, FWIW, how does your 'netstat -s' output look? Are you
    >>>> getting a considerable number of connection resets being sent or
    >>>> received?
    >>>>
    >>>
    >>> No. All the "reset sent"s in the diff below belong to an unrelated
    >>> application. In the time between the two netstats compared below,
    >>> various stalling transfers were made and one "network name is no
    >>> longer available" was received:
    >>>
    >>> # diff -Bub /root/netstat-20080213-0939 /root/netstat-20080213-1016
    >>> --- /root/netstat-20080213-0939 2008-02-13 09:39:24.000000000 +0000
    >>> +++ /root/netstat-20080213-1016 2008-02-13 10:16:34.000000000 +0000
    >>> @@ -1,43 +1,44 @@
    >>> Ip:
    >>> - 4336 total packets received
    >>> + 21933 total packets received
    >>> 0 forwarded
    >>> 0 incoming packets discarded
    >>> - 4335 incoming packets delivered
    >>> - 4134 requests sent out
    >>> + 20292 incoming packets delivered
    >>> + 19069 requests sent out
    >>> Icmp:
    >>> - 26 ICMP messages received
    >>> + 92 ICMP messages received
    >>> 0 input ICMP message failed.
    >>> ICMP input histogram:
    >>> - echo requests: 26
    >>> - 26 ICMP messages sent
    >>> + echo requests: 92
    >>> + 92 ICMP messages sent
    >>> 0 ICMP messages failed
    >>> ICMP output histogram:
    >>> - echo replies: 26
    >>> + echo replies: 92
    >>> Tcp:
    >>> - 6 active connections openings
    >>> - 161 passive connection openings
    >>> + 11 active connections openings
    >>> + 169 passive connection openings
    >>> 0 failed connection attempts
    >>> - 0 connection resets received
    >>> - 93 connections established
    >>> - 4176 segments received
    >>> - 3992 segments send out
    >>> + 1 connection resets received

    >>
    >> Hrm... the client reset. Do you have a wire sniff to see what is
    >> going on right before the client sends a reset?
    >>

    > Hi,
    >
    > I've put one at
    > http://www.oops.org.uk/misc/transfer...3-reset02.pcap
    >
    > I'm unable to extract useful clue from it, though brain fog is building
    > up here. I'm starting to consider publishing to an internal machine and
    > syncing with SCP or rsync. Feels hacky, though.
    >
    > Cheers,


    OK, it looks like you're choking on an enumeration for your subversion
    directory right before the first session close. Have you turned off
    "hide dot files", which is on by default?

    As far as rsync goes, it can be hacky, depending on how you do it.
    Personally, I have a script that mounts another computers administrative
    C$ share (as a domain admin - use a password file or it'll show up in
    top!). It works just fine, although not the most elegant way to do
    things... but that's why we're geeks, getting things done trumps
    elegance every day of the week. You'll have problems with open files
    though, unless you do an LVM snapshot or something. The nice thing
    about it though is that you can save permissions with rsync, and you do
    have hardlinking, client/server abilities, and stunnel support. Amanda
    or Bacula may be more elegant, but the setup overhead to have the same
    functionality that an easily modifiable shell script gives you, makes it
    a zero sum game in the short term. Just my $0.02.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

+ Reply to Thread