cyrus@hi.unm.edu (Tait Cyrus) (09/12/88)
I have been playing with `ping' (ECHO,TIME,MASK, & INFO) lately. I am
seeing different machines respond with different IP src fields (assuming
I was `pinging to broadcast').
My question then is:
"Should the src field in the returning IP header be the same
address that was in the dst field in the outgoing (requesting)
IP packet or should the src field be the IP address of the
responding machine?"
Ok, that is a mouth full, so let me give you some more information.
Given the following information:
Class B address: 129.24
Net Mask: 255.255.248.0 (0xfffff800)
a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as
the src IP address on the packet that is being returned to me and
sometimes the ping yields 129.24.#.# as the src IP address where #.# is
the correct IP address of the responding machine.
What is interesting is that some machines respond using 129.24.15.255
for ECHO/TIME/INFO requests, but use 129.24.#.# for MASK requests.
Some machines use different src IP addresses for different requests.
I can't find an RFC which talks about what src IP address to use when
echoing packets, so if one exists, I would greatly appreciate it if
someone could point me towards it.
Any other information about the "correct" way to handle this would also
be greatly appreciated.
Thanks in advance.....
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of EECE - Hypercube Project
@__|_______@ | Albuquerque, New Mexico 87131
| | | |
| | hc | | e-mail:
| @.......|..@ cyrus@hc.dspo.gov
| / | /
@/_________@/romkey@asylum.UUCP (John Romkey) (09/12/88)
In article <23634@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: > "Should the src field in the returning IP header be the same > address that was in the dst field in the outgoing (requesting) > IP packet or should the src field be the IP address of the > responding machine?" I believe that is should definitely the IP address of the network interface that the responding machine sends the datagram through. -- - john romkey UUCP: romkey@asylum.uucp ARPA: romkey@xx.lcs.mit.edu ...!ames!acornrc!asylum!romkey Telephone: (415) 952-9268
tmallory@PARK-STREET.BBN.COM (09/15/88)
> a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as > the src IP address on the packet that is being returned to me and > sometimes the ping yields 129.24.#.# as the src IP address where #.# is > the correct IP address of the responding machine. Flame: An ICMP echo to a broadcast address should get no response! What an incredibly obnoxious thing to do! Opinion: If a reply is sent, then the best response is to insert the IP address of the interface over which the packet was received in the source address field of the reply. Tracy Mallory BBNCC
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/16/88)
tmallory@park-street.bbn.com writes: > a `ping {-t,-n,-i,} 129.24.15.255' sometimes yields 129.24.15.255 as > the src IP address on the packet that is being returned... Flame: An ICMP echo to a broadcast address should get no response! What an incredibly obnoxious thing to do! This looked just too tempting, so I headed off to one of our Sun-3/180 servers (SunOS 3.5.1) to see what would happen if I abused its client subnet (12 Sun3/50 clients) in this way. The result was just mighty entertaining - the `packet loss' statistic is easily the best part, followed closely by the claimed IP address... Script started on Thu Sep 15 12:06:42 1988 [12] [12:06pm] tree:/dino0/karl> ping -s 128.146.28.255 PING 128.146.28.255: 56 data bytes 64 bytes from 128.146.28.255: icmp_seq=0. time=0. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=0. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=0. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=0. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=1. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=0. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=2. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=0. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=20. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms 64 bytes from 128.146.28.255: icmp_seq=3. time=40. ms ^C ----128.146.28.255 PING Statistics---- 4 packets transmitted, 48 packets received, -1100% packet loss round-trip (ms) min/avg/max = 0/25/40 [13] [12:06pm] tree:/dino0/karl> exit script done on Thu Sep 15 12:07:01 1988
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/16/88)
As long as I was at it, I decided to look at what a large collection of diverse machines did with pings to .255. I hit our backbone ethernet (128.146.8, a little over 100 hosts) with a ping like this, and the results are: Responding with 128.146.8.255: Sun-3/180 (SunOS 3.5.1 [UNIX]). Responding with their own addresses: HP-9000 (HP-UX [UNIX]), IBM-RT/PC (Mach), Proteon P4200, BBN Butterfly (Mach), Pyramid (OSx 4.x [UNIX]), Encore Annex telnet server. Not responding: DEC-2060 (TOPS 6.1; responds to direct ping), AT&T 3B2/400 (SysV Rel3.0 + TWG WIN; responds to direct ping), Kinetics Mac gateways (KIP; doesn't respond to direct ping), Encore Multimax (Umax 4.2; responds to direct ping), TI Explorer (Zetalisp; responds to direct ping), Xerox-1108 (Interlisp; responds to direct ping). Also, we have one HP-9000 client subnet. When pinging that subnet's broadcast addr (128.146.43.255), *only the server* responded - the rest were silent. Weird. --Karl
lotto@wjh12.harvard.edu (Jerry Lotto) (09/16/88)
In article <21843@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >As long as I was at it, I decided to look at what a large collection >of diverse machines did with pings to .255. I hit our backbone... >Responding with 128.146.8.255: >Sun-3/180 (SunOS 3.5.1 [UNIX]). And I am sure that someones bridge will then decide that they know where "the broadcast address" lives and stop forwarding it. I have seen this (anti-social) behavior in DEC Lanbridges and it does not bode well for the network until someone resets the beast. Takes a while to find if you aren't looking for it. -- Gerald Lotto - Harvard Chemistry Dept. UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto ARPA: lotto@harvard.harvard.edu
cyrus@hi.unm.edu (Tait Cyrus) (09/16/88)
In article <8809151450.AA23101@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes: >Flame: An ICMP echo to a broadcast address should get no response! What an >incredibly obnoxious thing to do! What do you mean it should get no response? It is a legal broadcast that all machines should reply to. My reason for pinging to the broadcast address is to aid my network debugging. The ping tells me several things. Which machines are on our ever expanding net (known and unknown), who is running trailers (arp table), and the hardware address of many machines. I especially like it because I can quickly tell what new machines are on our net by the fact that there is no name associated with the IP address in the arp table. If you can tell me a better way to do this, I am all ears. >Tracy Mallory >BBNCC Tait Cyrus University of New Mexico Dept. Electrical and Computer Engineering cyrus@hi.unm.edu
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (09/16/88)
In article <23635@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: >In article <8809151450.AA23101@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes: > >>Flame: An ICMP echo to a broadcast address should get no response! What an >>incredibly obnoxious thing to do! > >What do you mean it should get no response? It is a legal broadcast >that all machines should reply to. > No, no, no. ICMP messages are special, because they are error messages. They must be treated carefully and conservatively. You should not respond to a broadcast with an ICMP message, even if the source of the broadcast is an ICMP message. I refer you to the upcoming Host Req'ts RFC and/or Bob Braden, Craig Partridge, et al for further details.
cyrus@hi.unm.edu (Tait Cyrus) (09/16/88)
In article <303@wjh12.harvard.edu> lotto@wjh12.UUCP (Jerry Lotto) writes: >In article <21843@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >>As long as I was at it, I decided to look at what a large collection >>of diverse machines did with pings to .255. I hit our backbone... >>Responding with 128.146.8.255: >>Sun-3/180 (SunOS 3.5.1 [UNIX]). > >And I am sure that someones bridge will then decide that they know >where "the broadcast address" lives and stop forwarding it. If an IP bridge does this, then its' implementation of IP/TCP is hosed. The only time we have seen a problem simular to this is when a new machine was installed and the person installing it mis-typed and the machine thought it's IP address was broadcast. This resulted in all machines sending broadcast packets to this machine. We noticed this problem when all of our gateways lost all their routes (routing packets were going to this screwed machine). Simply pulling this machine off of the net solved the problems. >I have seen this (anti-social) behavior in DEC Lanbridges and it >does not bode well for the network until someone resets the beast. >Takes a while to find if you aren't looking for it. Huhhh???? A DEC Lanbridge is protocol independent. I think what you are refering to is the fact that a DEC Lanbridge (using old proms) will not forward packets sending to the broadcast address (ff:ff:ff:ff:ff:ff) iff it has seen this address in the src field of some other ethernet/802.3 packet. We have seen this happen and the result is NO broadcasts get forwarded through the DEC Lanbridge; i.e. RWHO/ROUTE/etc packets are NOT seen by machines on the other side of the DEC Lanbridge. We have yet to find the machine that thinks its' hardware address is ff:ff:ff:ff:ff:ff, though we are getting new DEC Lanbridge prom that take care of this problem. >-- >Gerald Lotto - Harvard Chemistry Dept. Tait Cyrus University of New Mexico Dept. Electrical and Computer Engineering Parallel Processig Research Group cyrus@hi.unm.edu
hedrick@athos.rutgers.edu (Charles Hedrick) (09/17/88)
We've certainly been bitten by hosts that respond to broadcasts inappropriately, so I'm sympathetic with the idea of being very conservative in responding to ICMP broadcasts. But let's not go too far. Kent England says you are never allowed to respond to a broadcast by sending an ICMP, even if the source of the broadcast is an ICMP. I think what should be said is that you never respond to a broadcast by sending an ICMP *error* message. If the original broadcast is one of the ICMP queries, and the query is well-formed, you can certainly send the corresponding response. Otherwise you couldn't broadcast an ICMP net mask request and expect to get a response. I have mixed feelings about broadcast ICMP echo requests. If you do it very much, it could produce very bad results. However I can also think of situations where I would want to be able to do it. So I'm inclined to say that it should be legal to respond to a broadcast ICMP echo request. If the host requirements RFC says what you said, I think Bob Braden should think again. Either that or come up with some other way to find out your net mask...
vjs@rhyolite.SGI.COM (Vernon Schryver) (09/17/88)
In article <24915@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes: > No, no, no. ICMP messages are special, because they are error > messages. They must be treated carefully and conservatively. That means my favorite diagnostic tool and stress test will go away: `ping -f <broadcast>', where 'ping' takes '-f' as 'flood the target at 100 packets/sec.' (100 p/s * >100 hosts = ?) Believe it or not, this can be quite useful for constructive purposes. Tho it will break my heart, this tool should go to the same retirement home as the old Atoms-for-Piece plan for digging a new Panama canal. The usefulness of the relatively innocuous 'ping <broadcast>' to see what's there can be duplicated with a small program which sends to all possible host addresses (paying attention to netmask). Modern machines can generate at least a couple hundred packets/sec from user code. (At least our's and our competator's are much better than that. :-) Thus in any situation where you don't expect too many responses for the test to social acceptible, it would take the new program only seconds to do the same thing. Vernon Schryver Silicon Graphics vjs@sgi.com
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (09/17/88)
And I am sure that someones bridge will then decide that they know
where "the broadcast address" lives and stop forwarding it.
I have seen this (anti-social) behavior in DEC Lanbridges and it
does not bode well for the network until someone resets the beast.
Takes a while to find if you aren't looking for it.
--
Gerald Lotto - Harvard Chemistry Dept.
UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lotto
ARPA: lotto@harvard.harvard.edu
Actually, the Lanbridge, as all other bridges, looks at the source and
destination addresses in the ethernet frame, NOT in the IP header. So
this particular bug only is triggered by an ethernet frame with a
source address of FFFFFFFFFFFF. The Sun's do have an annoying bug when
turning around broadcast pings, but they do send them with the proper
ethernet frame addresses. I have seen Kinetics Appletalk 'gateways'
fail in such a way as to send ethernet frames with broadcast source addresses,
and this does cause problems on a Rev. E LANBridge. DEC is working a fix
though, and at least with LANBridges you can use RBMS to reset them
remotely....
Thanks,
Milojqj@HOGG.CC.UOREGON.EDU (09/17/88)
>Flame: An ICMP echo to a broadcast address should get no response! >What an incredibly obnoxious thing to do! What do you mean it should get no response? It is a legal broadcast that all machines should reply to. Recall that broadcast was not originally part of the IP design, and indeed that many media that support IP do not support hardware broadcast. As such, it is to be expected that the "proper" behavior of various protocols in response to broadcasts is not well defined in the specs. IP broadcast was added mostly to support the functionality provided by Ethernet broadcast. In any CSMA environment (though not on a TR!) a broadcast ICMP echo request is a VERY BAD idea since it is guaranteed to generate a massive collision as everyone tries to answer at once. Designers of broadcast request-response Ethernet protocols almost always go to great effort to insure that the number of legitimate respondents is bounded, and preferably 1 (cf proxy ARP). If the spec doesn't forbid it, it should.
08071TCP@MSU.BITNET (Doug Nelson) (09/17/88)
>And I am sure that someones bridge will then decide that they know >where "the broadcast address" lives and stop forwarding it. >I have seen this (anti-social) behavior in DEC Lanbridges and it >does not bode well for the network until someone resets the beast. >Takes a while to find if you aren't looking for it. Now wait a minute....It's one thing to reply to the local IP broadcast address - it's another thing to use the Ethernet broadcast address as your source address! DEC Lanbridges don't look at anything higher than that. They should ignore multicast/broadcast addresses as a source address (although I don't really know if they do). I have enough problems with the ARP storms on my network from good (and also from incorrect) broadcast addresses. Doug Nelson Michigan State University
fjd@bridge2.UUCP (Farokh J. Deboo) (09/18/88)
In this discussion, although we have determined that the source address
to be used for the ICMP echo response should be the internet address of
the responding interface (as opposed to the destination address of the
original broadcast ICMP echo request), there have been differing opinions
as to whether an echo response should at all be generated to the original
broadcast ICMP echo request.
Can we reach some consensus on this issue, and perhaps issue the result-
ing statements in an enhanced RFC? Or is it already part of the Host Re-
quirements RFC (where can I get a copy?).
RFC 792 already states the following about when NOT to generate ICMP
responses:
1. To avoid the infinite regression of messages about messages etc., no
ICMP (error) messages are sent about ICMP messages.
2. Also ICMP messages are only sent about errors in handling fragment
zero of fragmented datagrams.
Farokh Deboo (sun!bridge2!fjd)
3Com Enterprise Systems Division
(415) 940-7677
--------------deering@PESCADERO.STANFORD.EDU (Steve Deering) (09/19/88)
According to the draft Host Requirements RFC, a host must silently ignore ICMP Echo and Timestamp Requests sent to an IP broadcast address. A host may (at the implementor's discretion) reply to an Echo or Timestamp Request sent to an IP multicast address, in which case the IP source address of the Reply is the address of the interface on which the Request arrived. By the routing rules in the Host Requirements RFC, that interface is also the one over which the Reply is sent. ICMP *error* messages (destination unreachable, redirect, source quench, time exceeded, parameter problem) must never be sent in response to any datagram received as a link-level broadcast or as an IP broadcast or multicast. Steve Deering
cire@CLASH.CISCO.COM (09/19/88)
>> Subject: Re: ICMP's & IP src addrs >> Date: Thu, 15 Sep 88 09:04:17 -0400 >> From: tmallory@PARK-STREET.BBN.COM >> >> Flame: An ICMP echo to a broadcast address should get no response! What an >> incredibly obnoxious thing to do! >> >> Opinion: If a reply is sent, then the best response is to insert the IP >> address of the interface over which the packet was received in the source >> address field of the reply. >> >> Tracy Mallory >> BBNCC Actually, I've found use for sending out broadcast pings. It can be very usefull when you are at a node in an internet that for one reason or another seems to not hear anymore. Say you are the net administrator and don't have a lot of time. Can anyone hear? Throw out a broadcast ping and see what you get back. The information can be very useful in a gross sort of way. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
tmallory@PARK-STREET.BBN.COM (09/19/88)
Now that the first wave is in, I'd like to amend the following: >Flame: An ICMP echo to a broadcast address should get no response! What an >incredibly obnoxious thing to do! My reply was motivated from my position as a user on a single relatively large ethernet(~500 hosts). There is no protection from this kind of barrage, although a single host could, in theory, use almost as much of the network bandwidth. If a large percentage of the replying hosts have to ARP for the sending host's hardware address, then that's a lot of ARP requests for everyone to process. I agree that a broadcast ping is a very simple and effective tool for network administration. Long before my message reached the rest of the world, I had received an internal reply to this effect. Aside from the usual list of benefits(unlisted hosts, trailer configured hosts, etc.), the reply pointed out that 'obnoxious' applied to the effects observed by users, and that a ping at two in the morning was unlikely to bother most people(at least here at BBN :-). Some problems: once the network gets large enough, there is a reasonable chance that not all of the replies will get back(so try a couple of times?). Also, it is not always possible to guarantee a 'safe' time to use such a tool. A user wishing to measure inter-machine performance will naturally schedule his test to run at two in the morning, when traffic is light... Nor is it simple, with the advent of work-stations, to prevent almost anyone from performing the 'what if' ping test. Many of us remember a much more public 'what if' test of the unix 'rwall' command a few years ago. Note also that the ping request can be sent through ip routers, which makes a great burst traffic generator to stress the routers, but leaves no protection for the poor users of both the network and the router. I am therefore arguing in favor of the spirit of the draft Host Requirements RFC(courtesy Steve Deering): According to the draft Host Requirements RFC, a host must silently ignore ICMP Echo and Timestamp Requests sent to an IP broadcast address. A host may (at the implementor's discretion) reply to an Echo or Timestamp Request sent to an IP multicast address, in which case the IP source address of the Reply is the address of the interface on which the Request arrived. By the routing rules in the Host Requirements RFC, that interface is also the one over which the Reply is sent. Actually, I don't have a great problem with hosts responding to such a request if they choose to, but if they do, then I believe it is important that the source address used be that over which the packet was received, rather than that over which it sends the reply, since that is the only way to establish the address that the host thinks it is using on the broadcast network of the echo request. (I'll need to read up on the routing rules before I go along with always replying back out the same interface.) Tracy Mallory
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (09/19/88)
It's also entertaining to try, say, telnetting to a local broadcast address. Does the Host Requirements RFC give any prescription about hosts replying to ordinary protocol traffic send to a broadcast address or to a link-level broadcast? Clearly, UDP broadcasts should be accepted, but what about TCP? Stuart Levy, Minnesota Supercomputer Center, slevy@uc.msc.umn.edu
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (09/19/88)
Do DEC Lanbridges try to look into the packet at IP addresses? Those x.y.z.255 replies should be coming from all different Ethernet addresses so I wouldn't expect a MAC bridge to consider them special.
rfox@AMELIA.NAS.NASA.GOV (Richard Fox) (09/20/88)
We've certainly been bitten by hosts that respond to broadcasts <inappropriately, so I'm sympathetic with the idea of being very <conservative in responding to ICMP broadcasts. But let's not go too <far. Kent England says you are never allowed to respond to a <broadcast by sending an ICMP, even if the source of the broadcast is <an ICMP. I think what should be said is that you never respond to a <broadcast by sending an ICMP *error* message. If the original <broadcast is one of the ICMP queries, and the query is well-formed, <you can certainly send the corresponding response. <up with some other way to find out your net mask... By allowing hosts to respond to well formed icmp echo request packets to the broadcast address you are opening the door to malicious attempts to swamp a network with data. How so? Ping the broadcast address with an icmp packet size of 1K or greater. If your ethernet contains quite a few hosts (100 maybe???) and they all respond to each packet once every second thats quite al ot of icmp data being generated every second. Start 2 pings going and watch out. Or if your ping option has the ability to generate a ping every 10th of a second your ethernet may find itself heavily congested if not completely unuasable if hosts respond to icmp echo requests to the broadcast address. I can see some usefulness in allowing some hosts respond but I really think this is an area where care must be taken in teh hosts requirements doc. rich
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (09/20/88)
In article <Sep.16.21.23.10.1988.10664@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > >I think what should be said is that you never respond to a >broadcast by sending an ICMP *error* message. >[...] >If the host requirements RFC says what >you said, I think Bob Braden should think again. Either that or come >up with some other way to find out your net mask... No, no [again :-]. I'm wrong, you are right. You state the restriction correctly above. I am guilty of fuzzy thinking on that one. Whatever one might think about broadcast pings, they are not against the rules today. They may just be rather dangerous or impolite. Sorry to everyone for the error and any resulting confusion.
Mills@UDEL.EDU (09/20/88)
Stuart, Your entertainment is actually an interesting experiment, as I discovered when I homed a bunch of rascallion fuzzballs on the broadcast address. I gave the analysis problem to my class on networking as an exercise. Does the game result in (a) any synchronized connection, (b) more than one synchronized connection and (c) if so, does any connection last for a significant time? Think about it. Dave
cyrus@hi.unm.edu (Tait Cyrus) (09/20/88)
In article <22185@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >In article <24915@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes: >> No, no, no. ICMP messages are special, because they are error >> messages. They must be treated carefully and conservatively. > >That means my favorite diagnostic tool and stress test will go away: >`ping -f <broadcast>', where 'ping' takes '-f' as 'flood the target at >100 packets/sec.' (100 p/s * >100 hosts = ?) Believe it or not, this >can be quite useful for constructive purposes. Tho it will break my >heart, this tool should go to the same retirement home as the old >Atoms-for-Piece plan for digging a new Panama canal. > >The usefulness of the relatively innocuous 'ping <broadcast>' to see >what's there can be duplicated with a small program which sends to all >possible host addresses (paying attention to netmask). Modern machines >can generate at least a couple hundred packets/sec from user code. (At >least our's and our competator's are much better than that. :-) Thus >in any situation where you don't expect too many responses for the test >to social acceptible, it would take the new program only seconds to do >the same thing. I agree, though there are some problems. I have a class B address with a netmask giving me 2k possible addresses. Assuming 100 p/s, that is about 20 seconds. Although this is not a very long period of time, you would never see this speed because for each IP address, your machine has to arp the IP address. Since most IP addresses are not used, at least on our net at the current time, a lot of time would be spent waiting for the arp replies. Besides, I would probably blow out my machines arp table with 2k entries. As far as what the correct response to such a "request" should be, we will have to wait for the new hosts requirements RFC (any ideas where I can get a copy of the draft???). >Vernon Schryver -- Silicon Graphics --- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of ECE - Parallel Processing Research Group @__|_______@ | Albuquerque, New Mexico 87131 | | | | | | hc | | e-mail: | @.......|..@ cyrus@pprg.unm.edu | / | / @/_________@/
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/21/88)
Date: Tue, 20 Sep 88 09:46:36 PDT From: nowicki@Sun.COM (Bill Nowicki) Responding with 128.146.8.255: Sun-3/180 (SunOS 3.5.1 [UNIX]). Have you tried a more recent release? The 4.2BSD networking code had thousands of bugs, only some of which were fixed by 3.5.1. SunOS 4.0.1 is the latest release. Yup, looks like it's OK in 4.0. I just tried it on a subnet with 13 3.5.1 3/50s, a 4.0 4/110 and a 4.0 4/something else. Pinging the subnet broadcast got me 13 replies at a time. Although I didn't actually stare at a lanalyzer in order to see exactly which hosts were sending what, it's obvious by implication that the 3.5.1 boxes are guilty and the 4.0 boxes are sane. --Karl
braden@VENERA.ISI.EDU (09/21/88)
Chuck Hedrick writes:
If the host requirements RFC says what
you said, I think Bob Braden should think again. Either that or come
up with some other way to find out your net mask...
It doesn't. The current draft is (always) available for anonymous FTP from host
venera.isi.edu with pathname ietf-hosts.rfc.txt.
Bob Bradenbraden@VENERA.ISI.EDU (09/22/88)
Stuart, The Host Requirements draft says a TCP must not (try to) open a connection to a remote broadcast or multicast address. I found here at ISI that when my Sun opens a TCP connection to a broadcast address, the ISI Symbolics machines crash in an obscure way. The Operations group was most unhappy, said it was my fault. Bob Braden
cpw%sneezy@LANL.GOV (C. Philip Wood) (09/22/88)
I vote for hosts NOT responding to broadcast ping's. If you want to find out who is on your net: set networkpart=192.5.16 @ subnet = 1 @ maskfactor = 32 @ host = 1 @ subnetpart = ( $maskfactor * $subnet ) while ( $host < $maskfactor ) @ hostpart = ( $subnetpart + $host ) set address="$networkpart.$hostpart" icmp echo vanilla $address @ host = ( $host + 1 ) end But, if you do respond to broadcasts you better put in the IP address of the interface the broadcast came in on in your response! Phil Wood.
cpw%sneezy@LANL.GOV (C. Philip Wood) (09/22/88)
Try telnet <class B network>.255.255 I found a connection established as follows (telnet from Sun to ethernet): SUN 4.0 SUNOS tcp 0 0 doc.1101 128.165.255.255.telnet ESTABLISHED VAX 4.3BSD tcp 0 78 128.165.255.255.telnet doc.1101 ESTABLISHED Is this predictable? The connection is stable.
Mills@UDEL.EDU (09/23/88)
Philip, What usually happens is that, after a glorious flabble of packets, one of the broadcast clients synchronizes and the others eventually get reset. This assumes each TCP peer randomizes its initial sequence number. However, if the clients keep bashing away, eventually they will hear a data packet without the expected SYN bit set and will send a reset. Eventually this succeeds and the connection comes bum. I don't understand how your SUn - VAX connection survived. Dave
cpw%sneezy@LANL.GOV (C. Philip Wood) (09/23/88)
Please excuse my previous posting. The program had one tiny bug which caused the last host ping'd to be the broadcast address! The corrected code: set networkpart=192.5.16 @ subnet = 1 @ maskfactor = 32 @ host = 1 @ maxhost = $maskfactor - 1 @ subnetpart = ( $maskfactor * $subnet ) while ( $host < $maxhost ) @ hostpart = ( $subnetpart + $host ) set address="$networkpart.$hostpart" icmp echo vanilla $address @ host = ( $host + 1 ) end Phil Wood.
casey@admin.cognet.ucla.edu (Casey Leedom) (09/23/88)
In article <8809211159.AA06217@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes: > [Re: pinging to a broadcast address] > If a large percentage of the replying hosts have to ARP for the sending > host's hardware address, then that's a lot of ARP requests for everyone > to process. Hhmmm, you mean your hosts receive a packet on their ethernets and don't record the mapping of source ethernet and IP addresses in their ARP caches? Doesn't sound like a very good idea to me. I'd say there's probably a pretty good chance you're going to have to send a packet back to any host you receive one from ... Casey
tmallory@PARK-STREET.BBN.COM (09/24/88)
> Hhmmm, you mean your hosts receive a packet on their ethernets and >don't record the mapping of source ethernet and IP addresses in their ARP >caches? Doesn't sound like a very good idea to me. I'd say there's >probably a pretty good chance you're going to have to send a packet back >to any host you receive one from ... While it this would help a lot with the traffic associated with the broadcast pings, recording, or at least checking, the IP/hardware address mapping for the source of every IP packet received seems wasteful, since it's purpose is to save an infrequent ARP request. If I receive 10000 packets from the same host, I'm not sure I want to check the logical/hardware mapping table every single time. Also, there is the problem that the source address in the IP header may well not match the source hardware address if the packet has been sent through a gateway. OK, so you only insert the mapping if the network number matches the attached network. But some hosts support multiple network numbers for the same network, so the packet might still have come from a gateway... This gets complicated, and the layering isn't very pretty. I don't think many hosts do it, but I'd be happy to hear otherwise. Tracy PS: If a host wants to match IP source addresses with particular hardware addresses for some limited flavor of security, then my main objection is moot.
braden@VENERA.ISI.EDU (09/25/88)
Can we reach some consensus on this issue, and perhaps issue the result- ing statements in an enhanced RFC? Or is it already part of the Host Re- quirements RFC (where can I get a copy?). Anonymous FTP from host venera.isi.edu with pathname: pub/ietf-hosts.rfc.txt It is 150+ pages. Bob Braden
jmg@cernvax.UUCP (jmg) (09/26/88)
>>Now wait a minute....It's one thing to reply to the local IP broadcast >>address - it's another thing to use the Ethernet broadcast address as >>your source address! DEC Lanbridges don't look at anything higher than >>that. They should ignore multicast/broadcast addresses as a source >>address (although I don't really know if they do). >> >Doug Nelson >Michigan State University If you have LANBridges with version 2 of their software then it is true that they can be got into the state where no broadcasts go through (but multicasts are OK). This bug was not in version 1.0. Of course, both versions had bugs if you use RBMS to change costs of lines, bridges etc. The broadcast problem certainly is provoked if the LANBridge sees a packet whose source address is ffffffffffff. To clear it the bridge has to be reinitialised. The symptoms are obvious: new tcp/ip connections fail, but old connections, plus ones where the ethernet address is already in cache, continue to work, as does DECNET. Thus, all the people with Vaxstations do not want the Ethernet touched, for fear that their station will need rebooting, but all the TCP/IPersons want it fixed. How to become unpopular in one easy lesson! -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
casey@admin.cognet.ucla.edu (Casey Leedom) (09/27/88)
In article <8809270020.AA01343@ucbvax.Berkeley.EDU> tmallory@PARK-STREET.BBN.COM writes: > In some article or another I write: > > Hhmmm, you mean your hosts receive a packet on their ethernets and > > don't record the mapping of source ethernet and IP addresses in their ARP > > caches? Doesn't sound like a very good idea to me. I'd say there's > > probably a pretty good chance you're going to have to send a packet back > > to any host you receive one from ... > > Also, there is the problem that the source address in the IP header may > well not match the source hardware address if the packet has been sent > through a gateway. OK, so you only insert the mapping if the network > number matches the attached network. But some hosts support multiple > network numbers for the same network, so the packet might still have come > from a gateway... This gets complicated, and the layering isn't very > pretty. I don't think many hosts do it, but I'd be happy to hear > otherwise. No, you're right. And me a proponent of lazy evaluation to boot ... And I should know better than to get snide on TCP-IP. Actually I wasn't really trying to be snide, but it came out that way. Sorry. But, while I'm here talking about when to put entries into your ARP cache, I'd like to describe an interesting experience I had today and see if anyone can explain it: Lawrence Livermore National Laboratory has recently joined the BARRNET, a regional NSFNET centered in the Bay Area in California. Other members currently include UC Berkeley, NASA Ames Research Center, Stanford, UC Davis, and several others. LLNL is tied into the BARRNET at two points, UCB and NASA ARC: Lawrence Livermore National Laboratory LLNL.Gov NET-LLL-LABNET 128.115 University of California, Berkeley Berkeley.Edu NET-UCB-ETHER 128.32 NASA Ames Research Center ARC.NASA.Gov NET-AMES-NET 128.102 When I look at typical host at LLNL, mozart.llnl.gov [128.115.12.1], a Sun 3/180 running SUN OS 3.4, I see a route to UCB-ETHER via BARRNET-GW.llnl.gov [128.115.1.100], but no ARP cache entry for BARRNET-GW. Now: From UCB (vangogh.berkeley.edu): I can ping mozart. I can talk to the name server on mozart. I can telnet to the SMTP server on mozart. I can't telnet or rsh to mozart. Symptoms: telnet goes into a connected state (at least it said it did) and then hangs. No login prompt, nothing. I had to escape out (^]) and quit the session. rsh just hangs but allows ^C's to abort it, so it hasn't entered a fully connected state with the remote rshd. On mozart.llnl.gov: I can ping UCB (vangogh.berkeley.edu). After all that testing, there's still no entry for barrnet-gw in mozart's ARP cache. If I ping barrnet-gw from mozart or attempt to telnet to UCB from mozart, an entry for barrnet-gw is now in mozart's ARP cache and suddenly telnet's from UCB to mozart work! SUN OS 3.5 doesn't seem to have this problem ... Opps, nope. Read the following paragraph. Unfortunately, I can't get this to happen consistently. For instance, I just deleted the entry for barrnet-gw from mozart's ARP cache and was able to successfully telnet in from UCB. I've done this three times now in the last five minutes and I'm beginning to doubt my memory of the first series of test this afternoon ... Does anyone have any idea what's going on? Casey