Broadcast

OK, let's start with some basic information.

1) You are sending an ICMP datagram thus a TCP port is not going to respond. Get the port idea out of your head.
2) There is no good reason to ping a broadcast address unless you want to initiate a smurf style attack
3) WTF are you doing this for?

Quote:

---

I would have thought that it would have been more like nmap -sS -vv -n -p80 -P0 192.168.1.0/24 sent out over the network rather than the broadcast to get all hosts to respond to a probe of port 80.

Perhaps someone should get TH13's opinion?

---

This is the sensible way to do local subnet discovery w/o flooding the piss out of the network.

Quote:

---

What are the devices on the network? Generally using ping 192.168.1.255 -t (windows) or ping 192.168.1.255 -b (linux) should work unless ping is surpressed by router/switch/firewall.

---

This will make every host on the local subnet respond until you stop the ICMP request. You will more than likely see a DUP! message appended signifying multiple responses to the request.

I'm going with MsMitts in that something is eating the ICMP broadcast request. I would check into what is actually sitting on your LAN.

Quote:

---

What I find stranage also is doing a nmap -sU -p42508 -P0 -S 192.168.1.18 -vv 255.255.255.255 only return me one host. This, I don't understand at all.

---

See above datagram statement.

Also nmap -vv -sP 192.168.1.0/24 will return all live hosts along with MAC and manufacturer of the NIC. This is the correct way to get info on hosts on your subnet.

Again, what are you trying to do?

I use eTrust Antivirus from CA in my company. With eTrust, you can install an eTrust server that provide the signature update and force the setting for all the pc in my network. To discover is a PC is running eTrust, the eTrust server is using a “IP-directed broadcasts over UDP Port 42508” (Took for the help file). Right now, eTrust server is able to find all the PC running eTrust on my local subnet but I’m unable to have him find the PC running eTrust across my VPN probably because of VPN configuration.

My goal is to test if it’s really the VPN configuration that block the broadcast by using another program to do that “IP-directed broadcasts over UDP Port 42508” or it’s just eTrust Server configuration that is bad.

Three things.

1) If UDP is involved, this is a heartbeat function the manufacturer uses to "phone home" to the parent server.
2) Your VPN may not be capable of passing UDP traffic. You'd be surprised how many do not.
3) You may not have the VPN ACLs set properly.

Anyway, Symantec uses the same framework to checkin to the SAV parent servers. This is not ICMP traffic, rather straight broadcast.

The best thing to do is setup Ethereal on the LAN and watch the traffic. This will answer your question instantly.

1) Nice Thinking!
2) I'll check with my VPN provider.

Thank a lot for the info! I'll make more tests! This project force me to learn NMap, now, it'll force me to learn Ethereal. :)