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

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?

"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

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 ?

"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.

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.

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.

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.

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

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.

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

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.

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

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

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?

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

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

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.

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