Reverse or inverse ARP from windows/linux - no way (!?!?)

no

DHCP

for

and provides

Damn, it seems i got things upside down again.

Op Thu, 01 Apr 2010 06:09:46 +0200 schreef JosephKK :

If you think that the link layer, internet layer and transport layer are all the same layer, then yes. But alas for you, OSI and TCP/IP do not agree with you.

Well, at least he didn't top-post.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

Em 1/4/2010 02:09, JosephKK escreveu:

mistaken.

If you think you have a lesson to teach please:

Can you show the erroneous part of the statement explaining us how an UDP datagram could be *sent* to a network without the IP layer?

Remember *you* wrote they're 'parallel' so they can be used in exchange of each other, right?

Your not very informed reply shows an arrogrant ignorance for the Internet RFC or equivalent ISO models.

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

I totally agree with you that ARP and UDP are in different protocol layers, but your response here is confusing.

ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See:

So, ARP frames are only encapsulated by the Ethernet frame, nothing more. Whereas UDP datagrams are encapsulated inside an IP datagram, which in turn is inside the Ethernet frame.

Bert

In comp.protocols.tcp-ip Albert Manfredi wrote: (snip)

Counting that way, why not any of the higher layers?

Back to ICMP for a moment. As ICMP is also carried in an IP frame, it seems that it should be the same layer as TCP and UDP. In terms of ping, that makes sense. In terms of route redirect or source quench, it doesn't. In the latter case, the ICMP are to help the IP layer and not much about anything higher.

ARP is there to help IP send frames on networks where layer 2 needs such help.

-- glen

ICMP is at the same layer as UDP, TCP, or IGMP, for that matter. But neither ICMP nor IGMP are meant to provide the general purpose "transport layer" services that TCP and UDP provide. I'd classify ICMP and IGMP as special purpose protocols to control or monitor layer 3 devices.

True. ARP is network-agnostic. It happens to have been used in IP nets most often, but that does not mean that it can ONLY be used to resolve IP addresses to physical addresses. It could in principle have been used for DECnet or any of those other forgotten protocols.

Bert

In comp.protocols.tcp-ip Albert Manfredi wrote: (snip)

Make that should have been used for DECnet. As I remember, DECnet changes the MAC address based on the DECnet address, such that no ARP is needed. You can only do that for one protocol per interface, though.

There was not so long ago on another newsgroup someone who had a system that uses DHCP to assign the IP address, then brings up DECnet. Somehow the change of MAC address confused other parts of the system.

Then Appletalk has AARP instead of using ARP.

I don't know IPX very well, so I don't know what it does.

-- glen

no

DHCP

participate=20

mistaken.

Arrghkk, gllujk, orwrrpp. (translation ankle tastes soo good)

norms.

This still stands.

Well, so did the OP (by failing to set any Followup-To at all, and X-posting to at least one totally off-topic newsgroup). And in his utterance that I replied to, _he_ dropped to a level of discussion that was off-topic for all three newsgroup, and unfit for anything but private discussion.

I'm quite sure it's well within USENET norms to redirect discussion of off-topic ad-hominem attacks to more appropriate ways of discussion. _Ignoring_ such redirects, like you did, is not.

able

Just make the device send a packet to the broadcast address, or to FF:FF:FF:FF:FF:FF every 20 seconds, containing its ID (well, it'll contain the MAC as the source address already, but you could also add more info e.g. the time since turned on or other information that may be helpful to distinguish between multiple devices). Every host on their local subnet will receive such packets, so it'll be a simple matter of programming to get the info you need.

norms.

No. You asking for email reply is abnormal. Rechecking the thread a bit= =20 i did not see any serious ad hominem either. Perhaps you are reading=20 different posts than i am, perhaps not.

Okay, perhaps we can steer this back to the original question?...

Is there a (easy) way to generate an Inverse ARP from a WIndows and/or Linux workstation? (or any other device, like a cisco switch or router)

My notes to add to the mess:

- We have identified an "interesting mac" address on the network (most likely noticed on a switches mac table) but we don't know it's IP address.

- we're assuming it has an IP address. (not netware or appletalk or...)

- We are not asking about Reverse ARP, that's different than Inverse ARP. Reveres ARP issued by me is me asking for my own IP address. RARP was a predecessor to bootp/dhcp.

- Inverse arp is sent to a mac address and asks that mac what his/her IP address is.

- Not everyone responds to a Broadcast ping to 255.255.255.255, so those results are not guaranteed to get the "interesting" mac to respond and add an entry to your arp table

- Not everyone responds to a subnet Broadcast ping to 172.16.3.255 (assuming the subnet is 172.16.3.0/24), so those results are not guaranteed to get the "interesting" mac to respond.

- Not everyone responds to a ping to 172.16.3.0 (assuming the subnet is 172.16.3.0/24), so those results are not guaranteed to get the "interesting" mac to respond.

- the interesting mac may not be using DHCP, it may be statically assigned an IP address and mask.

- the interesting mac may be programmed for a different subnet than what we think the switch port should be on (say our subnet is

172.16.3.0/24 and the "interesting mac" is quietly sitting there programmed for 10.20.30.153/24)

- because of the above, even a ip address scan of the subnet you think it's on (172.16.3.0/24) isn't going to get a response from the interesting mac.

So, it would be really cool if you could generate an Inverse-arp to the "interesting mac" to say "hey! what's your IP address?".

Of course if someone has such a command, the next question will be what percentage of devices will actually respond to it?

port mirroring to a sniffer (Wireshark) is another way to see it's IP address, if it's sending anything.

anyway, that's where this posting started (I think). Can anyone answer that initial question about generating an Inverse-arp?

Cheers - Glen#2

keep in mind, if your "interesting mac" address host is using dhcp to get it's IP address, and your DHCP server which it uses is on the other side of your broken Internet circuit, using inverse-arp would be a very temporary solution. DHCP based IP addresses are given out with a lease time that expires. The host should clear it's IP address if the lease time expires. Lease times can be from minutes to days. I've often seen 24hrs, but I've seen as low as 1 hour. The DHCP client host will try to renew at the leases half-life (and probably again after that until the lease expires, I'll have to look that up one day. I'd guess it would try half way between the failed renewal and the expirey, and keep doing that til the expirey, but it's just a guess)

Glen#2

I have made it to issue a new DHCP request some time before it expires, just had a look at it - 3 minutes before expiration. Works so far, but I don't have many systems deployed yet. Anyway, I have put this(and other similar high-level behaviour) in a DPS script for a reason, so it can easily be changed it if needed :-) .

BTW I think I posted the reason why there is no rarp/inarp utility under windows (their API won't allow it, a guy responded elsewhere). The same guy said he had written one himself for linux, so it seems to be possible there - but I did not locate anything readily available in a half an hours search.

Dimiter

at

I certainly can define exactly what the "Internet" is, but I don't see how it's relevant.

DS

There is only one Internet, so "an Internet" is grammatically incorrect. It should be "the Internet". There is no argument about the definition of "Internet", as there is only one (note that the capitalized "Internet" denotes a proper noun).

If you're not talking about *the* Internet, rather a network of computers outside *the* Internet, you should say "an internet". There you might have an legitimate argument over the precise definition of "internet".

You mention a fallback IP constructed from a standard prefix

192.168.100., with being the last octet of the NIC's MAC.

How about putting a slip of paper into the box stating this fallback IP? Works with and without non-site internet.

clemens

Well this is sort of the same thing. The lowest byte just has to be made up somehow, as others use 192.168.100.xx as well. Some luck will be needed anyway to not have that IP reserved. BTW the users get this not on a piece of paper but in a file on the accompanying CD :-) .

But this IP will not work at all in may cases when there is internet on the site. The subnet is likely to be quite different to the assumed one for fallback, so hosts trying to reach this IP will route to the gateway rather than locally (using ARP). It is just an ultimate fallback scenario so one can somehow get in touch with the device if it won't get automagiacally accepted on the local net via dhcp. Say, when people want to set a static address to it and need to access the thing to do it.

Dimiter

P.S. This is a revived old usenet thread, here is yet again the URL of the discussed device:

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

can

IP?

Out of curiosity, did you try NBNS and if so what was the factor that prevented use of it? I noticed you continued trying other solutions..

--------------------------------------- Posted through