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

g.

the

Nope. Just a single ARP packet type 3 (if RARP misused, not sure which it has to be for inarp - but same thing) to the known MAC destination, which will reply in a single packet to the originating MAC address. No loop, no broadcast involved.

g

If you mean would not everyone on the subnet be aware of everyone elses IP & mAC address data by snooping the dhcp, then no. Only the dhcp request is broadcast, the rest goes peer to peer (and may well be invisible to much of the subnet even in promiscuous mode).

uld

one

Yes, of course it is simple. I just want to use the wintel PC's as TV-sets (i.e. I am not delivering any software for them, my software runs under DPS on the device). In fact this works so far, I am just preparing for the day I have this issue at a customers site.

Dimiter

(the thread got lengthy, here is a third link to the device we are talking about:

formatting link
)

Reply to
Didi
Loading thread data ...

An ARP packet looks absolutely nothing like an IP packet.

ARP, in most senses, is not technically part of the TCP/IP stack at all, except that it's needed by some types of links. No more than Ethernet is really a part of TCP/IP (although it is used by many implementations). While ARP is defined in an RFC, there's plenty of stuff in the RFCs that not really part of TCP/IP proper.

In any event, ARP, as defined in RFC826, supports non-Ethernet format MAC addresses, and non-IP format network addresses. In fact, the format of the hardware and network addresses, and their lengths, are specified in the ARP packet for each query and response.

And to the OP: does the OS on this box have any support for the Windows networking protocols (Samba, if this is *nix)? If you enable that, and ID the node as a workgroup node with some easily recognizable name, then the users should be able to find it in Explorer (somewhere under "My Network Places"). If you published a share on your node you could put a single html page with a link (or perhaps a redirect, or just a display =96 =93I=92m at IP 1.2.3.4=94) to the correct IP address (that redirect page would be recreated each time your device was assigned a new IP address).

Reply to
robertwessel2

No, DPS is not unix. But thanks for the hint, I'll look into that "Samba" thing. If not too complex I certainly could add some (probably partial) support so the name becomes visible in "my network places" or sort of, this would be perfect as a result.

Dimiter

Reply to
Didi

I believe that, strictly speaking, that can't happen. If you have no internet at the moment, you don't have DHCP either. Remember that DHCP itself is a UDP service. UDP in turn works on top of IP, and that, for better or for worse, is "internet".

Well, the problem is nowhere near as easy as it appears at first sight. It's called a "network" because it's _work_ to set up a properly functioning net.

You'll want to look up "zero config networking". That's what the big guys came up with to address this very same issue. You'll see Apple mentioned rather a lot, for their "Rendezvouz"/"Bonjour" project.

And let me point out I'm completely flabbergasted that nobody mentioned this before me --- not over here in c.a.embedded, anyway. I mean, come on guys: not a single owner of an Apple Airport base station speaking up, wondering what all these people keep talking about for days, when a "normal" WLAN box just does the job???

Reply to
Hans-Bernhard Bröker

Oh no. Here we go again. I got quite a few really insightful replies and now this.

There are DHCP servers in the absence of internet. For example, a popular type of cable models do assign IP addresses of the 192.168.... kind when it has no link over the TV cable. Routers do that whether they are linked to the internet or not. On which planet do you live.

rly

Thank for the opinion. But you are posting to groups where some minimal understanding of how things work is implied, these are not general talk forums. Have a look at the thread in its entity and you will see what I mean. No offense meant, just being practical and trying to save time to myself and the rest of the people who really had something to say.

No. I was quite particular explaining what I wanted, the fact that you did not understand it should have indicated to you that you are about to post to a thread you do not understand.

Same answer. The fact that you did not understand what we were talking about should have been sufficient for you to grasp that the topic is outside of your competence and that you have nothing to contribute.

These are technical newsgroups.

Dimiter

Reply to
Didi

=46irst off the TCP/IP stack is 4 levels, and the ISO model is 7 layers. Thus there is intrinsic mismatch. Much of the TCP/IP model tools span=20 two or more layers in the ISO model. The real deal for TCP/IP protocol=20 definitions comes from the IETF RFC library.

formatting link

Please note that this RFC information is freely available for any use.

Wikipedia tries to allocate levels but fails sometimes:

formatting link

formatting link

And another opinion:

formatting link

Personally i place IP and UDP at the ISO link layer and ISO the transport= =20 layer. After all they are sending the message. (R)ARP is about = different=20 network functions and talks to the same layer (going towards Phy) as TCP=20 and IP; however it functions in link, transport, and network ISO layers. = =20 So where do you want to place it?

Reply to
JosephKK

No. UDP does not use IP all. It operates in parallel with IP, and = provides=20 a different service. Al least that is what the RFCs say.

Reply to
JosephKK

P
r

rovides

UDP (and TCP) both use IP as their lower layer. UDP operate in parallel with *TCP* and provides a different service. They *both* run over IP.

It is most emphatically *not* what the RFCs say. In fact, the opening paragraph of RFC786 (which defines UDP) is:

"This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) [1] is used as the underlying protocol."

And the prior poster is correct - it's IP that basically defines the Internet - the whole Internet exists to move IP packets around, and protocols like ICMP, UDP and TCP are built on top of IP. A number of other less common protocols also are built directly on top of IP (rather than on top of UDP or TCP). For example, the communication between routers running OSPF happens over IP, but uses protocol #89, which is distinct from TCP (6), UDP (17) and ICMP (1).

As for DHCP, it does, in fact, use a UDP packet, although in many implementations that's more a formality and the IP header is largely faked during initial system startup. Having it an actual UDP packet makes it rather easier for the (DHCP) servers and the rest of the network, though.

Reply to
robertwessel2

You are mistaken on this point.

UDP is built on top of IP. TCP is built on top of IP. ICMP is built on top of IP.

These three protocols are peers, at the same level in the network stack.

--
Dave Platt                                    AE6EO
Friends of Jade Warrior home page:  http://www.radagast.org/jade-warrior
  I do _not_ wish to receive unsolicited commercial email, and I will
     boycott any company which has the gall to send me such ads!
Reply to
Dave Platt

P
r

rovides

You are aware that UDP is IP encapsulated, just like tcp? If tcp is one level above IP then UDP also is. But like I said, I am not particularly interested in that sort of "official" side of things. dhcp is indeed running over UDP, but during the gray period of network setup; then at least the request is broadcast etc., some level cheating is applied during the process.

Dimiter

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

formatting link

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

formatting link

Reply to
Didi

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

There is internet, and there is the Internet. You can have a network, even an internet (network of networks) not connected to the Internet (the rest of the world).

Any of them may or may not have a DHCP server on them.

-- glen

Reply to
glen herrmannsfeldt

note quite true anymore ... the copyright notice use to say that author gives unlimited rights including any derivative works as long as the IETF copyright notice was included. A couple years ago, that was changed ... and now it ways that RFC authors may retain rights (so RFCs published since the change are subject to the new copyright rules).

look at RFCs related to IETF Trust ... for instance 5377

5377 I Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents, Halpern J., 2008/11/10 (8pp) (.txt=17843) (See Also 5378) (Refs 3935, 4071, 4371) (Ref'ed By 5744, 5745)

current documents carry the following

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents

formatting link
license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document

... i got hit with it and had to hire a copyright lawyer out of my own pocket (situation where an attempt was made to try and apply the new rules to RFCs published under the old rules) ... and suggested that they needed to make it much more clear to the authors about copyright changes.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970
Reply to
Anne & Lynn Wheeler

The ISO and the IETF are both wrong. There are nine layers :)

formatting link

rick jones

--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Reply to
Rick Jones

In comp.protocols.tcp-ip Rick Jones wrote: (snip)

The story I still remember is that between Europe and US one wanted six and one eight (I don't remember which) so they compromised on seven. Also, for ATM, one wanted 32 byte payload, one 64, so they compromised on 48. (I would have thought it would be geometric mean, though.)

-- glen

Reply to
glen herrmannsfeldt

That's only true for a meaning of the term "internet" that IMHO rather strictly contradicts with your self-proclaimed expertise in internet technologies. What exactly did the 'I' in IP mean again?

One on which your personal opinion is not the normative reference for the meaning of a technical term like "internet".

... says the person who obviously doesn't understand USENET well enough to recognize that his cross-post is obviously off-topic in one of the three groups he wrote to and on the fence of topicality for a second, who didn't bother setting a Followup-To on top of that, and replies to technical suggestions with ad-hominem attacks undiluted by technical arguments. Cute.

Interesting how you believe you know what I looked at and what I didn't.

Who do you believe you're kidding?

Yeah, right. Writing the above really saved your time, as compared to, say, not bothering to write it at all. Sure.

But if you're so sure I don't understand the issue, how about you start arguing against my statements instead of against my person?

Reply to
Hans-Bernhard Bröker

Many networks that have nothing whatsoever to do with the Internet have adopted its protocol. You can't have the Internet without IP, but you can certainly have IP with the Internet.

DS

Reply to
David Schwartz

For this thread to make any sense you should be able to define exactly what an 'Internet' is. Off you go...

Mark.

Reply to
markp

I skipped over that part. When he mentioned his 'customers', I was thinking of people outside of his LAN (on the Internet), which would assume the operation of the entire name service infrastructure.

On LANs, the easiest protocol to implement (for discovery of peers) would be NMBD. That's a part of the Samba s/w suite

formatting link
That's not a solution for WAN access, but it works within small networks.

--
Paul Hovnanian  paul@hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.
Reply to
Paul Hovnanian P.E.

=20

protocol=20

Thanks for the update, i hadn't realized that the publishers sickness had= =20 gotten to IETF. Damn publishers, insisting on hanging on to a=20 technologically obsolete business model from the dark ages.

Reply to
JosephKK

Not at all, both of those are applied liberally to all levels of=20 any stack currently; they actually enclose the whole stack. =20 Worse they are trying to get in between the existing layers/levels.

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.