Hi!
Thanks for your explanation Guy. I understand what's your point. I don't
have any multicasting here at all. To make my long story short I fixed this
problem when I installed PCMCIA Card Services 3.1.14 (pcmcia-cs-3.1.14). I
still can't figure why but finally it works properly.
Anyway, I'll explain you my test setup a little bit further. IP addresses
are 192.168.0.1, 192.168.0.2, 192.168.0.3. Netmask is 255.255.255.0
(FFFFFF80). Broadcast address is 192.168.0.127. Ethereal is running on
machine 192.168.0.1. Nmap is installed on IP 192.168.0.2. Another
'Ethereal' is running on SPARC Solaris (SUN Ultra1 hardware) just to
compare capturing results and has IP address 192.168.0.4. They're all
connected to a hub.
I've started following using nmap on host with IP 192.168.0.2:
nmap -sU -p 4000-4001 -P0 -n 192.168.0.3
(UDP scan on ports 4000/4001, destination host 192.168.0.3 with no TCP)
On both SPARC and Linux machine I've captured whole session with exactly
same content.
When I entered:
nmap -sU -p 4000-4001 -PT -n 192.168.0.3
(same as before including nmap's option to TCP 'Ping' destination port 80)
On SPARC I've captured all traffic including TCP packet to destination's
port 80. On Linux no TCP at all.
?..Why?...no clue.....
Anyway, thanks for your help. I don't know what's changed in new PCMCIA-CS
source but definitely it made this thing works.
Regards,
Dundo
At 11:44 AM 5/22/00 -0700, Guy Harris wrote:
On Mon, May 22, 2000 at 01:58:28PM -0400, Dundo wrote:
> Yes, UDP address was different than laptop's IP address.
But was the destination IP address a *unicast* address, as per the
question Gilbert asked:
> >Was the UDP to a unicast (non-broadcast, non-multicast) address that was
> >different than the laptop's NIC's IP address?
I.e., was it to an address other than 255.255.255.255 (or an address the
host part of which was all 1's), or to an address the first byte of
which was 224.
> All traffic that
> I've created was running between two other machines, not Ethereal machine
> itself.
I wouldn't describe broadcast traffic and multicast traffic as being
"between two other machines"; I'd describe it as running between one
other machine and *all* machines on the network (broadcast), or between
one other machine and *all* machines in the multicast group (multicast).
This is a key distinction; read on....
> As you, I'm also suspicious about that PCMCIA NIC but I cannot figure out
> why it's not possible to 'see' only TCP.
If the UDP traffic you saw was all broadcast traffic (which would be
traffic to a MAC address of ff:ff:ff:ff:ff:ff) or multicast traffic
(which I think will have the low-order bit of the high-order byte of the
MAC address set), then, if the card can't go into promiscuous mode, the
reason why it won't see TCP traffic between two other machines on the
network is probably that it can't see traffic between two other machines
on the network (because it can't go into promiscuous mode) - it can only
see traffic received by or sent by the machine to which it's attached,
and that traffic will either be traffic from that machine, traffic to
that machine, or broadcast and multicast traffic that happens to be
received by that machine, and broadcast and multicast traffic won't be
TCP.
(The destination IP address of broadcast IP traffic will probably be
255.255.255.255, and the destination IP address of multicast IP traffic
will probably have 224 as the first byte.)
> If this NIC is not able to run in
> promiscous mode I presume there would be no traffic visible at all.
Nope. You'll see traffic that the NIC receives, which includes not only
traffic explicitly sent to the machine to which the NIC is attached, but
*also* includes broadcast traffic and multicast traffic sent to a
multicast group of which that machine happens to be a member.
- Dundo -
--> This message has been sent on 100% recycled electrons <--
