Low Cost Hub With Read-Only Ports? - TCP-IP

This is a discussion on Low Cost Hub With Read-Only Ports? - TCP-IP ; Does anyone make a low cost four to eight port 10/100 hub that has a way to designate one of the ports as "readonly"? I want to have a notebook act as a sniffer behind an infected computer without exposing ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 37

Thread: Low Cost Hub With Read-Only Ports?

  1. Low Cost Hub With Read-Only Ports?

    Does anyone make a low cost four to eight port 10/100 hub that has a way to
    designate one of the ports as "readonly"? I want to have a notebook act as
    a sniffer behind an infected computer without exposing the notebook to any
    attack. I've seen what true network TAPs cost, and it seems silly to
    spend $600 to $2K for fairly trivial functionality like this. Portability
    is a key requirement so having a smaller desktop hub that is also
    programmable would be desirable. Any candidates?

    --
    Will



  2. Re: Low Cost Hub With Read-Only Ports?

    In article ,
    Will wrote:
    >Does anyone make a low cost four to eight port 10/100 hub that has a way to
    >designate one of the ports as "readonly"? I want to have a notebook act as
    >a sniffer behind an infected computer without exposing the notebook to any
    >attack. I've seen what true network TAPs cost, and it seems silly to
    >spend $600 to $2K for fairly trivial functionality like this. Portability
    >is a key requirement so having a smaller desktop hub that is also
    >programmable would be desirable. Any candidates?
    >
    >--
    >Will



    If you run your sniffer laptop from a CD-bootable OS (knoppix and many
    others) if it *does* gete infected, a reboot will fix it.




    --
    a d y k e s @ p a n i x . c o m
    Don't blame me. I voted for Gore. A Proud signature since 2001

  3. Re: Low Cost Hub With Read-Only Ports?

    Will wrote:

    > Does anyone make a low cost four to eight port 10/100 hub that has a way to
    > designate one of the ports as "readonly"?



    Ehm... what about simply cutting one of the wires, trivially creating a
    Rx-only ethernet cable?

  4. Re: Low Cost Hub With Read-Only Ports?

    "Sebastian G." wrote in message
    news:5bkhv3F2tquhaU1@mid.dfncis.de...
    > Will wrote:
    >
    >> Does anyone make a low cost four to eight port 10/100 hub that has a way
    >> to designate one of the ports as "readonly"?

    >
    > Ehm... what about simply cutting one of the wires, trivially creating a
    > Rx-only ethernet cable?


    Clever idea...which wire do I cut, and perhaps some vendor sells such a
    cable to avoid the hassle?

    --
    Will



  5. Re: Low Cost Hub With Read-Only Ports?

    Hello,

    Sebastian G. a écrit :
    > Will wrote:
    >
    >> Does anyone make a low cost four to eight port 10/100 hub that has a
    >> way to designate one of the ports as "readonly"?

    >
    > Ehm... what about simply cutting one of the wires, trivially creating a
    > Rx-only ethernet cable?


    I guess you mean one of the pairs.
    Wouldn't it break the link beat detection and speed auto-negotiation ?

  6. Re: Low Cost Hub With Read-Only Ports?

    "Sebastian G." writes:

    >Will wrote:


    >> Does anyone make a low cost four to eight port 10/100 hub that has a way to
    >> designate one of the ports as "readonly"?



    >Ehm... what about simply cutting one of the wires, trivially creating a
    >Rx-only ethernet cable?


    I don't think that works nicely except if the Hub doesn't do link detection
    and neither does your laptop.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  7. Re: Low Cost Hub With Read-Only Ports?

    Will wrote:


    >> Ehm... what about simply cutting one of the wires, trivially creating a
    >> Rx-only ethernet cable?

    >
    > Clever idea...which wire do I cut, and perhaps some vendor sells such a
    > cable to avoid the hassle?


    http://en.wikipedia.org/wiki/Etherne...ted-pair_cable

    Dunno if a vendor sells it, in any large companies the admins do all the
    cabling themselves.

  8. Re: Low Cost Hub With Read-Only Ports?

    Pascal Hambourg wrote:


    >> Ehm... what about simply cutting one of the wires, trivially creating a
    >> Rx-only ethernet cable?

    >
    > I guess you mean one of the pairs.
    > Wouldn't it break the link beat detection and speed auto-negotiation ?



    Sure it does.

  9. Re: Low Cost Hub With Read-Only Ports?

    Casper H.S. Dik wrote:


    >> Ehm... what about simply cutting one of the wires, trivially creating a
    >> Rx-only ethernet cable?

    >
    > I don't think that works nicely except if the Hub doesn't do link detection
    > and neither does your laptop.


    If your setup doesn't require it, the failure of link detection won't break
    anything. The only real problem is the OS, thus you have to deactivate DHCP
    media sensing (e.g. the OS reports a non-existent network connection through
    the DHCP negoiation state in the TCP/IP stack and then invalidates the
    routes) and setup the routing table manually.

  10. Re: Low Cost Hub With Read-Only Ports?

    In article <5blstoF2tq84fU1@mid.dfncis.de>,
    Sebastian G. wrote:

    >>> Ehm... what about simply cutting one of the wires, trivially creating a
    >>> Rx-only ethernet cable?

    >>
    >> Clever idea...which wire do I cut, and perhaps some vendor sells such a
    >> cable to avoid the hassle?

    >
    >http://en.wikipedia.org/wiki/Etherne...ted-pair_cable


    Perhaps the point of that URL is to suggest doing what seems obvious
    to me. That is to buy a jumper cable at a local retail store, strip
    the out jacket, and cut one wire of the right pair. Or buy several
    cables, and cut different wires in each.

    But as others have said, the result is unlikely to work. One reason
    is that modern Ethernet hardware tends to want to chatter in both
    directions before passing packets.

    Another problem is that many boxes now sold as "Ethernet hubs" are
    really learning bridges instead of Ethernet repeaters and so do not
    forward all packets to all ports. They must be bridges instead of
    repeaters if they are "10/100" hubs or able to connect 10 MHz hosts to
    100 MHz hosts. If they are cheap, they lack the knobs and switches to
    configure a port to receive all packets, and so no port will see all
    packets.


    >Dunno if a vendor sells it, in any large companies the admins do all the
    >cabling themselves.


    On the contrary, that it seems that everyone has the tools and parts
    needed to build a few cables does not imply that they are used except
    in special cases. In many large U.S. companies, contractors do most
    "cable pulling," and jumpers and other impermanent cables are built by
    outsider vendors. It's too expensive to build your own short cables,
    unless you are getting Third World wages.


    Vernon Schryver vjs@rhyolite.com

  11. Re: Low Cost Hub With Read-Only Ports?

    Vernon Schryver wrote:


    > But as others have said, the result is unlikely to work.



    Well, they do work quite well. Not to mention that this is the preferred
    setup for master-slave keep-alive communication for redundant firewalls on
    OpenBSD.

    > One reason is that modern Ethernet hardware tends to want to chatter in both
    > directions before passing packets.



    and doesn't break if it can't do so.

    > Another problem is that many boxes now sold as "Ethernet hubs" are
    > really learning bridges instead of Ethernet repeaters and so do not
    > forward all packets to all ports. They must be bridges instead of
    > repeaters if they are "10/100" hubs or able to connect 10 MHz hosts to
    > 100 MHz hosts. If they are cheap, they lack the knobs and switches to
    > configure a port to receive all packets, and so no port will see all
    > packets.



    Then you have to add some MAC flooding. This is exactly why I prefer some
    good old classical that you can put in between the line.

    > In many large U.S. companies, contractors do most
    > "cable pulling," and jumpers and other impermanent cables are built by
    > outsider vendors. It's too expensive to build your own short cables,
    > unless you are getting Third World wages.



    What do you think these vendors are doing? Right: Ethernet cable is so damn
    cheap, it's like a natural resource for them. You just pull of some 100
    meters, cut them as required, add the plugs and there you go.

  12. Re: Low Cost Hub With Read-Only Ports?

    In article <5blur5F2tj148U1@mid.dfncis.de>,
    Sebastian G. wrote:

    >> But as others have said, the result is unlikely to work.

    >
    >Well, they do work quite well.


    Let's wait to see if the other person can make them work. That people
    who know about such things can make them work does not imply that they
    are likely to work for people with less experience.


    > Not to mention that this is the preferred
    >setup for master-slave keep-alive communication for redundant firewalls on
    >OpenBSD.


    I'm sure that's all very nice, although I don't understand why one would
    use Ethernet cables with one pair cut with redundant firewalls.

    It is somewhat surprising to see mention of a UNIX-like operating system
    from someone who elsewhere seems to think that DHCP is part of the the
    "OS" and the "TCP stack" and talks about Microsoft's registry switches
    that control whether the system should pay attention to Ethernet carrier
    sense. In the UNIX world, DHCP is just another application, albeit one
    that hammers on network interfaces. BSD style network interfaces or
    drivers decide whether to pay attention to carrier, including transmitting
    when there is none--that is, if the MAC chip doesn't decide the issue
    itself.


    >> One reason is that modern Ethernet hardware tends to want to chatter in both
    >> directions before passing packets.

    >
    >and doesn't break if it can't do so.


    "Doesn't necessarily break" and "works in some cases" are not the
    same as "doesn't break." The problem is not only in the host but
    also in the hub. What does your cheap hub do when it sees no carrier
    on either pair? What if it is smart enough to automagically switch
    the TX and RX pairs in all sockets instead of having a single extra
    "uplink" socket, as is now common?

    Another trouble is that HDX Ethernet is CSMA/CD. The hub cannot
    do much carrier sensing (CD) if its RX pair (or the host's TX pair)
    is cut.


    >> Another problem is that many boxes now sold as "Ethernet hubs" are
    >> really learning bridges instead of Ethernet repeaters and so do not
    >> forward all packets to all ports.


    >Then you have to add some MAC flooding. This is exactly why I prefer some
    >good old classical that you can put in between the line.


    How does one "add some MAC flooding" on a cheap hub with no management
    facilities? Cheap hubs do whatever they are wired to do at the factory.
    The only controls you have on them are in how you choose to connect
    them to cables (including power).
    As I wrote, whatever the other person finds today as a "cheap hub" is
    likely to be 10/100 bridge, and so likely to be a pain for passive
    packet snooping.


    >> In many large U.S. companies, contractors do most
    >> "cable pulling," and jumpers and other impermanent cables are built by
    >> outsider vendors. It's too expensive to build your own short cables,
    >> unless you are getting Third World wages.

    >
    >What do you think these vendors are doing? Right: Ethernet cable is so damn
    >cheap, it's like a natural resource for them. You just pull of some 100
    >meters, cut them as required, add the plugs and there you go.


    Yes, and that cutting and plug crimping is part of the job of "cable
    pulling" done by outside contractors. I'm sure that there are large
    companies that do it all themselves, but I _know_ that many large
    companies outsource cable pulling and buy tons of pre-built cables
    in lengths ranging from short jumpers to 100 meters.


    Vernon Schryver vjs@rhyolite.com

  13. Re: Low Cost Hub With Read-Only Ports?

    Vernon Schryver wrote:


    >> Not to mention that this is the preferred
    >> setup for master-slave keep-alive communication for redundant firewalls on
    >> OpenBSD.

    >
    > I'm sure that's all very nice, although I don't understand why one would
    > use Ethernet cables with one pair cut with redundant firewalls.



    It's about a master firewall server continually advertising its presence to
    a slave server without the latter being able to accidentially invoke any
    malicious behaviour on the master server. State table changes are usually
    transferred on a second line, which also can be Rx-only and made Rx+Tx on
    demand (when a master server has to recover the state table from the slave
    server).

    > It is somewhat surprising to see mention of a UNIX-like operating system
    > from someone who elsewhere seems to think that DHCP is part of the the
    > "OS" and the "TCP stack"



    Why that?

    > and talks about Microsoft's registry switches
    > that control whether the system should pay attention to Ethernet carrier
    > sense.



    Nonsense. DHCP media sensing is a well-known mechanism/protocol that exists
    on Unix as well.

    > BSD style network interfaces or drivers decide whether to pay attention


    > to carrier, including transmitting when there is none--that is, if the
    > MAC chip doesn't decide the issue itself.


    And the network drivers signal such issues to which component? Exactly the
    TCP/IP stack. DHCP media sensing just is a portable way for how the TCP/IP
    forwards these signals to the application (e.g. by intentionally creating a
    DHCP message from a non-existent DHCP server).

    >>> One reason is that modern Ethernet hardware tends to want to chatter in both
    >>> directions before passing packets.

    >> and doesn't break if it can't do so.

    >
    > "Doesn't necessarily break" and "works in some cases" are not the
    > same as "doesn't break."



    No, totally wrong. The sensing is supposed to "fix" problems that don't
    occur on a correct setup. Use the right cabling? No need to negotiate Rx/Tx
    wries. Manually setup the right speed? No speed negotiation needed.

    > The problem is not only in the host but
    > also in the hub. What does your cheap hub do when it sees no carrier
    > on either pair? What if it is smart enough to automagically switch
    > the TX and RX pairs in all sockets instead of having a single extra
    > "uplink" socket, as is now common?



    And as this fails as well, it bogs down to leaving it like it is.
    And yes, my cheap hub doesn't try any such stupid stuff. That's exactly why
    it works so well.

    > Another trouble is that HDX Ethernet is CSMA/CD. The hub cannot
    > do much carrier sensing (CD) if its RX pair (or the host's TX pair)
    > is cut.



    That's not even a problem, that's an intended feature.

    >>> Another problem is that many boxes now sold as "Ethernet hubs" are
    >>> really learning bridges instead of Ethernet repeaters and so do not
    >>> forward all packets to all ports.

    >
    >> Then you have to add some MAC flooding. This is exactly why I prefer some
    >> good old classical that you can put in between the line.

    >
    > How does one "add some MAC flooding" on a cheap hub with no management
    > facilities?



    Simply attach another computer that does the flooding. It could even be the
    compromised machine itself, since the sniffer can verify the existence of a
    stream of bogus ARP requests.

  14. Re: Low Cost Hub With Read-Only Ports?

    In article , vjs@calcite.rhyolite.com (Vernon Schryver) writes:
    | In article <5blstoF2tq84fU1@mid.dfncis.de>,
    | Sebastian G. wrote:
    |
    | >>> Ehm... what about simply cutting one of the wires, trivially creating a
    | >>> Rx-only ethernet cable?
    | >>
    | >> Clever idea...which wire do I cut, and perhaps some vendor sells such a
    | >> cable to avoid the hassle?
    | >
    | >http://en.wikipedia.org/wiki/Etherne...ted-pair_cable
    |
    | Perhaps the point of that URL is to suggest doing what seems obvious
    | to me. That is to buy a jumper cable at a local retail store, strip
    | the out jacket, and cut one wire of the right pair. Or buy several
    | cables, and cut different wires in each.
    |
    | But as others have said, the result is unlikely to work. One reason
    | is that modern Ethernet hardware tends to want to chatter in both
    | directions before passing packets.

    If necessary you can always use another cheap hub to supply link pulses
    to the TX pair. That is, don't just cut a pair; split it out to a separate
    plug. It might be best to disable auto-negotiation, though that probably
    requires something more than a cheap hub...

    Dan Lanciani
    ddl@danlan.*com

  15. Re: Low Cost Hub With Read-Only Ports?

    In article <5bman7F2stdchU1@mid.dfncis.de>,
    Sebastian G. wrote:

    >It's about a master firewall server continually advertising its presence to
    >a slave server without the latter being able to accidentially invoke any
    >malicious behaviour on the master server. State table changes are usually
    >transferred on a second line, which also can be Rx-only and made Rx+Tx on
    >demand (when a master server has to recover the state table from the slave
    >server).


    "Rx-only and made Rx+Tx on demand" is nonsense in this context.
    You cannot un-cut a wire "on demand," and so that stuff cannot be
    using Ethernet cables with one pair cut as proposed in this thread.
    Turning off Ethernet input or output or output in software does not
    meet the other person's design goal of a permanent, unalterable
    block on one direction.

    Personally, I don't think much of the goal. If you can't trust your
    host software to honor your command to be passive while snooping on an
    Ethernet, then I don't think you can trust its monitoring.


    >> and talks about Microsoft's registry switches
    >> that control whether the system should pay attention to Ethernet carrier
    >> sense.

    >
    >Nonsense. DHCP media sensing is a well-known mechanism/protocol that exists
    >on Unix as well.


    Where among the DHCP RFCs or elsewhere is that protocol documented?

    Micrsooft's description at
    http://support.microsoft.com/kb/239924
    seems to say that it has nothing to do with DHCP except to trigger a
    DHCP negotiation. That's consistent with RFC 3927.

    Perhaps I should mention that I wrote the `routed` daemon that is
    in a bunch of versions of UNIX-like systems including FreeBSD and
    Solaris. It uses network interface state changes to trigger various
    RIP, RIPv2, and router discovery protocol events. In at least some
    drivers (e.g. those I've written), those IFF_RUNNING bit changes can
    reflect Ethernet MAC carrier sense problems, persistent FDDI beaconing
    or claiming, etc.
    I guess a control on that mechanism might be called "RIP/RDISC media
    sensing", but it would not be part of what I call a "TCP/IP stack."
    I also doubt it would be a "well-known mechanism/protocol."



    >> BSD style network interfaces or drivers decide whether to pay attention

    >
    > > to carrier, including transmitting when there is none--that is, if the
    > > MAC chip doesn't decide the issue itself.

    >
    >And the network drivers signal such issues to which component? Exactly the
    >TCP/IP stack.


    That's not really right for my notion "TCP/IP stack." It does make sense
    for how many Microsoft system administrators see TCP/IP based on old
    WINSOCK libraries and other TCP/IP before before Windows NT.

    > DHCP media sensing just is a portable way for how the TCP/IP
    >forwards these signals to the application (e.g. by intentionally creating a
    >DHCP message from a non-existent DHCP server).


    It's not "portable" in a protocol sense unless your definition is
    limited to what is said in Redmond as demonstrated by the lack of
    hits for this URL:
    http://www.google.com/search?q=dhcp+...site%3Aisc.org


    >>>> One reason is that modern Ethernet hardware tends to want to chatter in both
    >>>> directions before passing packets.
    >>> and doesn't break if it can't do so.

    >>
    >> "Doesn't necessarily break" and "works in some cases" are not the
    >> same as "doesn't break."

    >
    >No, totally wrong. The sensing is supposed to "fix" problems that don't
    >occur on a correct setup. Use the right cabling? No need to negotiate Rx/Tx
    >wries. Manually setup the right speed? No speed negotiation needed.


    That is an (cough) unusual description of Ethernet auto-sense.


    >> The problem is not only in the host but
    >> also in the hub. What does your cheap hub do when it sees no carrier
    >> on either pair? What if it is smart enough to automagically switch
    >> the TX and RX pairs in all sockets instead of having a single extra
    >> "uplink" socket, as is now common?

    >
    >And as this fails as well, it bogs down to leaving it like it is.
    >And yes, my cheap hub doesn't try any such stupid stuff. That's exactly why
    >it works so well.


    What is the "this" that "fails as well"?
    What bogs down and what is left "like it is"?
    Eactly what is working so well?
    Are you saying that you use cat-5 or cat-6 cables with only one
    working pair to monitor an Ethernet? If so what are the brand and
    model of your cheap hub, and what host hardware and software
    (e.g. laptop) do you use?


    >> Another trouble is that HDX Ethernet is CSMA/CD. The hub cannot
    >> do much carrier sensing (CD) if its RX pair (or the host's TX pair)
    >> is cut.

    >
    >That's not even a problem, that's an intended feature.


    Is that an odd way of saying that a single-pair Ethernet TP cable
    will not work at all on an HDX hub?
    If so, what does that imply for the other person's design goal?
    If a cheap hub that cannot auto-negotiate FDX because one pair is cut
    falls back to HDX, and if HDX transmissions from the hub to the laptop
    do not work without sensing carrier, what does that tell us?

    (To be honest, I don't recall if the IEEE standard says a CSMA/CD
    twisted pair, HDX hub should stop transmitting on the TX pair if
    it does not sense carrier on the RX pair, and I'm too lazy to drag
    out my copy or some other book such as Rich Seifert's to check.)


    >>> Then you have to add some MAC flooding. This is exactly why I prefer some
    >>> good old classical that you can put in between the line.

    >>
    >> How does one "add some MAC flooding" on a cheap hub with no management
    >> facilities?

    >
    >Simply attach another computer that does the flooding. It could even be the
    >compromised machine itself, since the sniffer can verify the existence of a
    >stream of bogus ARP requests.


    Oh, I thought a different notion was intended by "MAC flooding."
    Doesn't this notion require that the hub not defend against that
    attack by shutting down the port? Granted, that might be less
    likely in a cheap hub.


    Vernon Schryver vjs@rhyolite.com

  16. Re: Low Cost Hub With Read-Only Ports?

    Vernon Schryver wrote:

    > In article <5bman7F2stdchU1@mid.dfncis.de>,
    > Sebastian G. wrote:
    >
    >> It's about a master firewall server continually advertising its presence to
    >> a slave server without the latter being able to accidentially invoke any
    >> malicious behaviour on the master server. State table changes are usually
    >> transferred on a second line, which also can be Rx-only and made Rx+Tx on
    >> demand (when a master server has to recover the state table from the slave
    >> server).

    >
    > "Rx-only and made Rx+Tx on demand" is nonsense in this context.
    > You cannot un-cut a wire "on demand," and so that stuff cannot be
    > using Ethernet cables with one pair cut as proposed in this thread.



    What about *replacing* the cable with another one? That's exactly the point.
    You have replaced the defective master server, you exchange the cable with a
    normal one, you have the master server recover its state from the slave
    server, then you put the Rx-only cable back in place.

    > Personally, I don't think much of the goal. If you can't trust your
    > host software to honor your command to be passive while snooping on an
    > Ethernet, then I don't think you can trust its monitoring.



    So that's why they added an optional Rx-only patch to Linux... honestly,
    this is not about trust, this is about reliability. Most systems simply are
    not designed to fully deal with Rx-only network traffic, neither are easily
    configurable in that way.

    > It's not "portable" in a protocol sense unless your definition is
    > limited to what is said in Redmond as demonstrated by the lack of
    > hits for this URL:
    > http://www.google.com/search?q=dhcp+...site%3Aisc.org



    WTF? As I already said, the implementation is a matter of the TCP/IP stack
    of the operating system, and as you already mentioned there are multiple way
    to trigger RIP or DHCP events.

    Why exactly should ISC care?

    (BTW, without a &safe=off&hl=en you might run into Google's censorship...)


    >>> The problem is not only in the host but
    >>> also in the hub. What does your cheap hub do when it sees no carrier
    >>> on either pair? What if it is smart enough to automagically switch
    >>> the TX and RX pairs in all sockets instead of having a single extra
    >>> "uplink" socket, as is now common?

    >> And as this fails as well, it bogs down to leaving it like it is.
    >> And yes, my cheap hub doesn't try any such stupid stuff. That's exactly why
    >> it works so well.

    >
    > What is the "this" that "fails as well"?



    The negoitation with Tx and Rx switched. It it fails as well, the hub
    assumes the normal order it has started the negotiation with.

    > Are you saying that you use cat-5 or cat-6 cables with only one
    > working pair to monitor an Ethernet?



    Yes.

    > If so what are the brand and model of your cheap hub,



    Old no-name thing, model number seems to be HB-101. You know, very very old,
    10TX-only and heating up very fast.

    > and what host hardware and software (e.g. laptop) do you use?



    FreeBSD and Wireshark. Now that's no mystery.

    > If a cheap hub that cannot auto-negotiate FDX because one pair is cut
    > falls back to HDX, and if HDX transmissions from the hub to the laptop
    > do not work without sensing carrier, what does that tell us?



    That you're wrong, it does work with HDX. Why shouldn't it? CSMA/CD doesn't
    even get a share in this process.

    > Oh, I thought a different notion was intended by "MAC flooding."
    > Doesn't this notion require that the hub not defend against that
    > attack by shutting down the port? Granted, that might be less
    > likely in a cheap hub.


    At any rate, what about simply placing a classical hub directly between the
    other hub/switch/router/whatever and the machine?

  17. Re: Low Cost Hub With Read-Only Ports?

    In article <5bml2bF2t5vupU1@mid.dfncis.de>,
    Sebastian G. wrote:

    >> It's not "portable" in a protocol sense unless your definition is
    >> limited to what is said in Redmond as demonstrated by the lack of
    >> hits for this URL:
    >> http://www.google.com/search?q=dhcp+...site%3Aisc.org

    >
    >WTF? As I already said, the implementation is a matter of the TCP/IP stack
    >of the operating system, and as you already mentioned there are multiple way
    >to trigger RIP or DHCP events.
    >
    >Why exactly should ISC care?


    Where is the primary place to look for documentation for the by far
    most popular UNIX implementation of DHCP client and server?
    If the documentation for dhcpd doesn't know about this "DHCP media sense
    protocol," then it is probably neither very well known nor very portable.


    >> Are you saying that you use cat-5 or cat-6 cables with only one
    >> working pair to monitor an Ethernet?

    >
    >Yes.
    >
    >> If so what are the brand and model of your cheap hub,

    >
    >Old no-name thing, model number seems to be HB-101. You know, very very old,
    >10TX-only and heating up very fast.
    >
    >> and what host hardware and software (e.g. laptop) do you use?

    >
    >FreeBSD and Wireshark. Now that's no mystery.


    That simple report of personal experience, without the posturing
    and efforts to show expertise that in fact suggested the opposite,
    might do the other person some good. Ironically, it would also
    have made the reporter appear more expert.

    I doubt that report will do the other person any good for a bunch
    of reasons. One is the modern difficulty of finding 10TX-only hubs.
    (Yes, I have my own piles of junk old 10TX-only hubs, store-bought
    cables, bulk cable, crimping tools, cat-5 RJ-45 plugs and sockets, old
    computers with various Ethernnet interfaces including yellow hose, etc.
    From the other person's questions, I doubt the availability of equivalent
    resources there.)


    >> If a cheap hub that cannot auto-negotiate FDX because one pair is cut
    >> falls back to HDX, and if HDX transmissions from the hub to the laptop
    >> do not work without sensing carrier, what does that tell us?

    >
    >That you're wrong, it does work with HDX. Why shouldn't it? CSMA/CD doesn't
    >even get a share in this process.


    Doesn't that depend on whether the hub demands carrier sense to transmit?
    I agree that Dan Lanciani's suggestion of a Y cable and yet another
    hub or just another port on the original hub to fake carrier should work.


    >At any rate, what about simply placing a classical hub directly between the
    >other hub/switch/router/whatever and the machine?


    If the network to be monitored is running at more than about 9.8 Mbit/sec,
    then the classical hub and host uisng 10BASE-T will miss packets.


    Vernon Schryver vjs@rhyolite.com

  18. Re: Low Cost Hub With Read-Only Ports?

    On Thu, 24 May 2007 22:56:22 +0000, Vernon Schryver wrote:

    > Is that an odd way of saying that a single-pair Ethernet TP cable will
    > not work at all on an HDX hub?
    > If so, what does that imply for the other person's design goal? If a
    > cheap hub that cannot auto-negotiate FDX because one pair is cut falls
    > back to HDX, and if HDX transmissions from the hub to the laptop do not
    > work without sensing carrier, what does that tell us?


    I thought all hubs where HDX by definition. Does something like a FDX hub
    really exist?

    A hub forwards a frame to all it's ports, except the one it is receiving
    the frame on. What to do with a frame that comes in from one of those
    other ports? It cannot send that to all the other ports as they are
    already busy transmitting the original frame.

    This can only work in the case of a store and forward architecture, but
    that is also HDX by definition because of exactly the same problem, so
    why bother?

    Where do I go wrong in this picture? As you usually know what you're
    talking about I assume I'm making a mistake somewhere here.

    M4

  19. Re: Low Cost Hub With Read-Only Ports?

    Martijn Lievaart wrote:


    > A hub forwards a frame to all it's ports, except the one it is receiving
    > the frame on. What to do with a frame that comes in from one of those
    > other ports? It cannot send that to all the other ports as they are
    > already busy transmitting the original frame.



    It can. It will create an interference, the frame gets corrupted, CSMA/CD
    resolves the issue.

  20. Re: Low Cost Hub With Read-Only Ports?

    On Tue, 29 May 2007 14:13:11 +0200, Sebastian G. wrote:

    > Martijn Lievaart wrote:
    >
    >
    >> A hub forwards a frame to all it's ports, except the one it is
    >> receiving the frame on. What to do with a frame that comes in from one
    >> of those other ports? It cannot send that to all the other ports as
    >> they are already busy transmitting the original frame.

    >
    >
    > It can. It will create an interference, the frame gets corrupted,
    > CSMA/CD resolves the issue.


    That is not very useful is it? Besides, in practice that is HDX.

    I'm not completely sure what happens then. On a coax cable someone will
    send a jam signal, but on a hub?

    If the intended receiver sends back a frame to the sender, and that
    sender gets that frame FDX, while all other clients see a collision, and
    that has no further consequences, yes, that might work. But somehow I
    doubt if it really works that way. Someone who knows?

    M4

+ Reply to Thread
Page 1 of 2 1 2 LastLast