Archived from groups: comp.dcom.lans.ethernet (
More info?)
In article <1125738314.989817.164200@o13g2000cwo.googlegroups.com>,
<iwetzel@gmx.net> wrote:
:its unicast IP. The Sender doenst know the gateway IP and also not the
:Gateway mac. Thats the reason why Its an broadcast. But its save that
:the connection between sender and Gateway is an P2P Connection.
You mean something like ICMP Router Discovery, RFC1256?
http://www.faqs.org/rfcs/rfc1256.html
:But may be there is an Ethernet Broadcast frame which on triggers the
:Gateway to say something. Because if I recieve a frame from the gateway
:I know his MAC due to the P2P connection. Due you know some kind of
:ethernet broadcast which triggers a normal Router to send an answer?
In another message in the thread, you mentioned a very specific
kind of router and asked how it might be configured for forwarding.
If you have that level of control, then you could configure the
router to send out RIPv1 or RIPv2 packets announcing the default
route. Hearing such a route would tell you where the router was.
:But may be there is an Ethernet Broadcast frame which on triggers the
:Gateway to say something. Because if I recieve a frame from the gateway
:I know his MAC due to the P2P connection. Due you know some kind of
:ethernet broadcast which triggers a normal Router to send an answer?
Let's have another look at that. You are trying to find out the
IP address of the "gateway" and you propose to do that by
provoking the "router". But if one examines the context of your
request, then the "gateway" is -not- the same as the "router".
If the P2P traffic knows the remote IP address, then all it
has to do is unicast to that IP: all details about the path
it takes to get there will be handled by the IP stack, and you
don't need to worry about router MACs and so on... not unless you
are programming the IP stack itself.
If the P2P traffic does -not- know the remote IP address, then
it is not going to be able to get traffic to the remote endpoint
by sending a unicast traffic to the router's IP + MAC: the
router itself would end up processing the traffic, since the router
would see it's own IP. "normal" routers would drop such traffic
unless it happened to be management traffic (e.g., SNMP or ssh
to the router), or NTP, or unless the router was configured for
"small services" such as chargen.
Thus in the context of your messages, the "gateway" that you
are trying to provoke must be a device that actively participates
in the P2P transaction (even if only in "call setup".) If that
active device is beyond a router, then learning the MAC of
that active device wouldn't help you because you need the router's
MAC to send to, not the active device's MAC.
If you have enough control over the context that you can specify
switch models end to end, then there are three technologies
that I suggest you investigate: multicast, DHCP, and bootp
{DHCP is actually a kind of bootp, but your research will be
easier if you treat them as nearly two different protocols.)
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey
Facebook
Twitter
Instagram