Greetings,
Looking at Wireshark I seem to be seeing too many ARP requests from my
Rabbit host.
It seems to be sending out an ARP request for every host it sees,
regardless of whether it actually needs that host's address or not. The
net result is that all the unnecessary addresses it caches tend to push
the one or two it needs off the table so that the Rabbit has to send out
an ARP request for them.
I realize, of course, that this might be by-design and that in most
contexts this would be considered desirable but for the case of an
under-powered host with a very small table that does not have to
communicate with the whole LAN, it's not helpful and it is
customer-noticeable.
So my questions are:
Are my observations correct? Is it caching stuff it doesn't need?
Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
Thanx,
Roger
Too Many ARP Requests
Started by ●June 17, 2011
Reply by ●June 17, 20112011-06-17
What hardware and version of Dynamic C? What's your definition of "see" --
hosts that attempt to connect to the Rabbit in some way? Hosts that are sending
some sort of broadcast message?
-Tom
On Jun 17, 2011, at 2:35 PM, phroger_rabbit wrote:
> Greetings,
>
> Looking at Wireshark I seem to be seeing too many ARP requests from my Rabbit host.
>
> It seems to be sending out an ARP request for every host it sees, regardless of whether it actually needs that host's address or not. The net result is that all the unnecessary addresses it caches tend to push the one or two it needs off the table so that the Rabbit has to send out an ARP request for them.
>
> I realize, of course, that this might be by-design and that in most contexts this would be considered desirable but for the case of an under-powered host with a very small table that does not have to communicate with the whole LAN, it's not helpful and it is customer-noticeable.
>
> So my questions are:
>
> Are my observations correct? Is it caching stuff it doesn't need?
> Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
>
> Thanx,
>
> Roger
>
>
>
-Tom
On Jun 17, 2011, at 2:35 PM, phroger_rabbit wrote:
> Greetings,
>
> Looking at Wireshark I seem to be seeing too many ARP requests from my Rabbit host.
>
> It seems to be sending out an ARP request for every host it sees, regardless of whether it actually needs that host's address or not. The net result is that all the unnecessary addresses it caches tend to push the one or two it needs off the table so that the Rabbit has to send out an ARP request for them.
>
> I realize, of course, that this might be by-design and that in most contexts this would be considered desirable but for the case of an under-powered host with a very small table that does not have to communicate with the whole LAN, it's not helpful and it is customer-noticeable.
>
> So my questions are:
>
> Are my observations correct? Is it caching stuff it doesn't need?
> Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
>
> Thanx,
>
> Roger
>
>
>
Reply by ●June 17, 20112011-06-17
I'm using v10.62 on a 5k.
I'm guessing the Rabbit host is seeing broadcasts. In addition to ARP broadcasts, there are quite a few Bonjour mDNS multicasts. The Ethernet switch to which it connects filters out everything else.
Peace,
Roger
--- In r..., Tom Collins wrote:
>
> What hardware and version of Dynamic C? What's your definition of "see" -- hosts that attempt to connect to the Rabbit in some way? Hosts that are sending some sort of broadcast message?
>
> -Tom
> On Jun 17, 2011, at 2:35 PM, phroger_rabbit wrote:
> > Greetings,
> >
> > Looking at Wireshark I seem to be seeing too many ARP requests from my Rabbit host.
> >
> > It seems to be sending out an ARP request for every host it sees, regardless of whether it actually needs that host's address or not. The net result is that all the unnecessary addresses it caches tend to push the one or two it needs off the table so that the Rabbit has to send out an ARP request for them.
> >
> > I realize, of course, that this might be by-design and that in most contexts this would be considered desirable but for the case of an under-powered host with a very small table that does not have to communicate with the whole LAN, it's not helpful and it is customer-noticeable.
> >
> > So my questions are:
> >
> > Are my observations correct? Is it caching stuff it doesn't need?
> > Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
> >
> >
> >
> > Thanx,
> >
> > Roger
> >
> >
>
I'm guessing the Rabbit host is seeing broadcasts. In addition to ARP broadcasts, there are quite a few Bonjour mDNS multicasts. The Ethernet switch to which it connects filters out everything else.
Peace,
Roger
--- In r..., Tom Collins wrote:
>
> What hardware and version of Dynamic C? What's your definition of "see" -- hosts that attempt to connect to the Rabbit in some way? Hosts that are sending some sort of broadcast message?
>
> -Tom
> On Jun 17, 2011, at 2:35 PM, phroger_rabbit wrote:
> > Greetings,
> >
> > Looking at Wireshark I seem to be seeing too many ARP requests from my Rabbit host.
> >
> > It seems to be sending out an ARP request for every host it sees, regardless of whether it actually needs that host's address or not. The net result is that all the unnecessary addresses it caches tend to push the one or two it needs off the table so that the Rabbit has to send out an ARP request for them.
> >
> > I realize, of course, that this might be by-design and that in most contexts this would be considered desirable but for the case of an under-powered host with a very small table that does not have to communicate with the whole LAN, it's not helpful and it is customer-noticeable.
> >
> > So my questions are:
> >
> > Are my observations correct? Is it caching stuff it doesn't need?
> > Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
> >
> >
> >
> > Thanx,
> >
> > Roger
> >
> >
>
Reply by ●June 18, 20112011-06-18
Roger,
I don't see any obvious mechanisms for limiting the arp requests but there is a means of loading an arp cache entry and making it permenant which might be helpful for your problem. Have a look at the arpcache_load function for details.
Regards,
Peter
--- In r..., "phroger_rabbit" wrote:
>
> I'm using v10.62 on a 5k.
>
> I'm guessing the Rabbit host is seeing broadcasts. In addition to ARP broadcasts, there are quite a few Bonjour mDNS multicasts. The Ethernet switch to which it connects filters out everything else.
>
> Peace,
>
> Roger
>
> --- In r..., Tom Collins wrote:
> >
> > What hardware and version of Dynamic C? What's your definition of "see" -- hosts that attempt to connect to the Rabbit in some way? Hosts that are sending some sort of broadcast message?
> >
> > -Tom
> >
> >
> > On Jun 17, 2011, at 2:35 PM, phroger_rabbit wrote:
> > > Greetings,
> > >
> > > Looking at Wireshark I seem to be seeing too many ARP requests from my Rabbit host.
> > >
> > > It seems to be sending out an ARP request for every host it sees, regardless of whether it actually needs that host's address or not. The net result is that all the unnecessary addresses it caches tend to push the one or two it needs off the table so that the Rabbit has to send out an ARP request for them.
> > >
> > > I realize, of course, that this might be by-design and that in most contexts this would be considered desirable but for the case of an under-powered host with a very small table that does not have to communicate with the whole LAN, it's not helpful and it is customer-noticeable.
> > >
> > > So my questions are:
> > >
> > > Are my observations correct? Is it caching stuff it doesn't need?
> > > Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
> > >
> > >
> > >
> > > Thanx,
> > >
> > > Roger
> > >
> > >
> > >
>
I don't see any obvious mechanisms for limiting the arp requests but there is a means of loading an arp cache entry and making it permenant which might be helpful for your problem. Have a look at the arpcache_load function for details.
Regards,
Peter
--- In r..., "phroger_rabbit" wrote:
>
> I'm using v10.62 on a 5k.
>
> I'm guessing the Rabbit host is seeing broadcasts. In addition to ARP broadcasts, there are quite a few Bonjour mDNS multicasts. The Ethernet switch to which it connects filters out everything else.
>
> Peace,
>
> Roger
>
> --- In r..., Tom Collins wrote:
> >
> > What hardware and version of Dynamic C? What's your definition of "see" -- hosts that attempt to connect to the Rabbit in some way? Hosts that are sending some sort of broadcast message?
> >
> > -Tom
> >
> >
> > On Jun 17, 2011, at 2:35 PM, phroger_rabbit wrote:
> > > Greetings,
> > >
> > > Looking at Wireshark I seem to be seeing too many ARP requests from my Rabbit host.
> > >
> > > It seems to be sending out an ARP request for every host it sees, regardless of whether it actually needs that host's address or not. The net result is that all the unnecessary addresses it caches tend to push the one or two it needs off the table so that the Rabbit has to send out an ARP request for them.
> > >
> > > I realize, of course, that this might be by-design and that in most contexts this would be considered desirable but for the case of an under-powered host with a very small table that does not have to communicate with the whole LAN, it's not helpful and it is customer-noticeable.
> > >
> > > So my questions are:
> > >
> > > Are my observations correct? Is it caching stuff it doesn't need?
> > > Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
> > >
> > >
> > >
> > > Thanx,
> > >
> > > Roger
> > >
> > >
> > >
>
Reply by ●March 9, 20122012-03-09
Problem SOLVED!
I had to back-burner this problem for quite awhile until it bothered a customer.
After wasting my time with an Undisclosed Company's "tech-support" (a robo-mailer telling me to RTFM, how helpful is that?) I started tracking the problem down.
The more precise description is that my app listens for and sends mDNS multicasts on 240.0.0.251, port 5353. Whenever it receives any mDNS multicast, DC's code sends the "useless" ARP. If you have a few printers, some Apple iDevices, some iTunes sessions, LXI devices and some units-under-test on the same LAN then the ARPs begin to affect the Rabbit's TCP sessions.
Particularly annoying is that the IP for which it was sending the ARP it was getting from offset 0x1a of the multicast UDP packet when at offset 0x06 of that same packet was the very MAC address for which it was sending the ARP.
I started by greping arpresolve_start_iface and there it was in the middle of udp_handler(). Back with DC v8.61, it used to call arpcache_new() with the MAC address from the UDP packet. Not the most desirable behavior in my case but not too harmful. By v9.62, that line was commented out re: ticket 23956 in their Vantive knowledge base and was replaced by the arpresolve_start_iface(). By simply skipping over the call when the source IP is 240.0.0.251 this problem is solved.
One of these days it might be nice to know what the subject of ticket 23956 was and what was going through the mind of whoever coded that.
Hope this helps somebody.
Peace.
--- In r..., "phroger_rabbit" wrote:
>
> Greetings,
>
> Looking at Wireshark I seem to be seeing too many ARP requests from my
> Rabbit host.
>
> It seems to be sending out an ARP request for every host it sees,
> regardless of whether it actually needs that host's address or not. The
> net result is that all the unnecessary addresses it caches tend to push
> the one or two it needs off the table so that the Rabbit has to send out
> an ARP request for them.
>
> I realize, of course, that this might be by-design and that in most
> contexts this would be considered desirable but for the case of an
> under-powered host with a very small table that does not have to
> communicate with the whole LAN, it's not helpful and it is
> customer-noticeable.
>
> So my questions are:
> Are my observations correct? Is it caching stuff it doesn't need?
> Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
> Thanx,
>
> Roger
>
I had to back-burner this problem for quite awhile until it bothered a customer.
After wasting my time with an Undisclosed Company's "tech-support" (a robo-mailer telling me to RTFM, how helpful is that?) I started tracking the problem down.
The more precise description is that my app listens for and sends mDNS multicasts on 240.0.0.251, port 5353. Whenever it receives any mDNS multicast, DC's code sends the "useless" ARP. If you have a few printers, some Apple iDevices, some iTunes sessions, LXI devices and some units-under-test on the same LAN then the ARPs begin to affect the Rabbit's TCP sessions.
Particularly annoying is that the IP for which it was sending the ARP it was getting from offset 0x1a of the multicast UDP packet when at offset 0x06 of that same packet was the very MAC address for which it was sending the ARP.
I started by greping arpresolve_start_iface and there it was in the middle of udp_handler(). Back with DC v8.61, it used to call arpcache_new() with the MAC address from the UDP packet. Not the most desirable behavior in my case but not too harmful. By v9.62, that line was commented out re: ticket 23956 in their Vantive knowledge base and was replaced by the arpresolve_start_iface(). By simply skipping over the call when the source IP is 240.0.0.251 this problem is solved.
One of these days it might be nice to know what the subject of ticket 23956 was and what was going through the mind of whoever coded that.
Hope this helps somebody.
Peace.
--- In r..., "phroger_rabbit" wrote:
>
> Greetings,
>
> Looking at Wireshark I seem to be seeing too many ARP requests from my
> Rabbit host.
>
> It seems to be sending out an ARP request for every host it sees,
> regardless of whether it actually needs that host's address or not. The
> net result is that all the unnecessary addresses it caches tend to push
> the one or two it needs off the table so that the Rabbit has to send out
> an ARP request for them.
>
> I realize, of course, that this might be by-design and that in most
> contexts this would be considered desirable but for the case of an
> under-powered host with a very small table that does not have to
> communicate with the whole LAN, it's not helpful and it is
> customer-noticeable.
>
> So my questions are:
> Are my observations correct? Is it caching stuff it doesn't need?
> Is there some way to modify it's behavior? (short of modifying ARP.LIB?)
> Thanx,
>
> Roger
>
Reply by ●March 9, 20122012-03-09
On 3/9/2012 6:04 PM, phroger_rabbit wrote:
> One of these days it might be nice to know what the subject of ticket 23956 was and what was going through the mind of whoever coded that.
>
> Hope this helps somebody.
>
Would be nice if they published all these changes and issues like they
did back in the DC 7.x days. ;)
Thanks for following up.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------
> One of these days it might be nice to know what the subject of ticket 23956 was and what was going through the mind of whoever coded that.
>
> Hope this helps somebody.
>
Would be nice if they published all these changes and issues like they
did back in the DC 7.x days. ;)
Thanks for following up.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------
Reply by ●March 12, 20122012-03-12
On Mar 9, 2012, at 3:04 PM, phroger_rabbit wrote:
> I started by greping arpresolve_start_iface and there it was in the middle of udp_handler(). Back with DC v8.61, it used to call arpcache_new() with the MAC address from the UDP packet. Not the most desirable behavior in my case but not too harmful. By v9.62, that line was commented out re: ticket 23956 in their Vantive knowledge base and was replaced by the arpresolve_start_iface(). By simply skipping over the call when the source IP is 240.0.0.251 this problem is solved.
IIRC, the destination MAC address for multicast packets is calculated from the IP address, so there shouldn't be any ARP messaging going on when the source IP is a multicast one. I would think the Rabbit ARP library would just short-circuit the ARP resolve call made on a multicast address to provide the associated MAC.
Also, it may be a bad idea to automatically update the ARP cache with the MAC address from the packet. Wouldn't that make it way too easy to poison the ARP cache of the Rabbit? I could just send a packet using someone else's IP as my source address, and then the Rabbit would just start sending me that traffic.
-Tom
> I started by greping arpresolve_start_iface and there it was in the middle of udp_handler(). Back with DC v8.61, it used to call arpcache_new() with the MAC address from the UDP packet. Not the most desirable behavior in my case but not too harmful. By v9.62, that line was commented out re: ticket 23956 in their Vantive knowledge base and was replaced by the arpresolve_start_iface(). By simply skipping over the call when the source IP is 240.0.0.251 this problem is solved.
IIRC, the destination MAC address for multicast packets is calculated from the IP address, so there shouldn't be any ARP messaging going on when the source IP is a multicast one. I would think the Rabbit ARP library would just short-circuit the ARP resolve call made on a multicast address to provide the associated MAC.
Also, it may be a bad idea to automatically update the ARP cache with the MAC address from the packet. Wouldn't that make it way too easy to poison the ARP cache of the Rabbit? I could just send a packet using someone else's IP as my source address, and then the Rabbit would just start sending me that traffic.
-Tom
