[SOLVED] An answer to my post on arplookup failing [US$50]
-
The answer is to configure your system by powering off the cable modem, then the message will no longer appear in your log files. Leave the modem off. Can I have the $50? (I prefer to be paid in beer)
Seriously, if the cable modem has a private IP on the lan you are going to get this. Yours is Roadrunner, but I've seen the same thing with Comcast- the modem has a public IP passthough, but operates on a private IP. You might be able to get different CPE if it's really bothering you. -
You can have the bounty if you can explain how to get the system to quit logging the error. My log file fills with that !@#$ message constantly, so I can hardly see anything else.
Would a different brand cable modem help?
-
Afaik:
System –> Advanced --> "Shared Physical Network"
"This will suppress ARP messages when interfaces share the same physical network"Will suppress all ARP messages, regarless of the cause.
-
Using the advanced setting to suppress ARP messages when interfaces share the same physical network is a good thought, but I have had that setting enabled for months and it is making no difference. Any other ideas?
-
That box just toggles net.link.ether.inet.log_arp_wrong_iface and .log_arp_movements to zero.
They don't help in this situation. As long as the cable modem is arping on that private subnet, you are going to have this message. I very rarely use cable, so I'm not sure, but it seems logical that some cable modems could just operate as a bridge instead of the bogus private IP with public passthrough crap. Unfortunately, most cable providers require you to use a modem they supply. I know Comcast has some kind of crazy system where the public block is routed to you via rip running on the CPE, and this is only configurable from their end, or with their double-secret login or whatever, so you have to use what they give you. (with this kind of account setup- home accounts are different and they may have other setups for business) You could try using this http://doc.pfsense.org/multiple-subnets-one-interface-pfsense.pdf to add an alias on the WAN side (192.168.100.10 or something). If that works, donate your $50 to the project.Edit: You wouldn't need to do the NAT stuff in the doc, just add the alias. This may cause your interface to show the private, not the public IP in the GUI. This is cosmetic only. (I think. You might blow your system up, standard warnings apply.)
-
Good job dotdash. I basically followed your recommendation, and it eliminated the entries in the log. I have paid the bounty (Confirmation number: 8Y334490J6562784M).
For the benefit of anyone else with a similar problem, and there are a few according to my research, I only really changed one thing to dotdash's advice. I configured the config.xml file to add the single line referenced in the instructions, namely: <shellcmd>ifconfig AAA inet 192.168.100.10 netmask 255.255.255.0 alias</shellcmd>. Obviously, I changed the "AAA." to the name of my interface. However, when I used the WAN interface, it would eliminate the error messages in my log but the connection to the web was severely impaired–slowing to a stop in most cases. However, when I replaced the AAA with the name of my LAN interface, I both eliminated the error message in the log and the connection to the web remained solid. I can only conclude that dotdash's advice was simply to use the ability to define an alias on an interface in order to provide something for the arplookup to see in order to eliminate the error message. If so, then it did not really matter which interface was used. Perhaps someone more knowledgeable than me can explain it further.
In summary, follow the instructions of defining an alias, as noted in dotdash's post, but use the LAN interface rather than the WAN interface.
For what it is worth, I also found it easier to simply ssh into the firewall and edit the config.xml file directly (after making a backup) rather than following the GUI procedure listed in the instructions.
[Now, if I can only get an answer to my post on the SonicWall VPN client . . . . The bounty is up to $200 on that one.]
-
Hmm, the private IP on the WAN must confuse the passthrough on the cable modem. Defining the alias on the LAN was a good thought. For others, the supress arp checkbox should be checked or this configuration will result in arp errors about the address being on the wrong interface.
-
While the arplookup error is gone, which is a great step, the other error then kicks in: dhclient[17421]: DHCPREQUEST on dc0 to 76.85.238.38 port 67, followed immediately by dhclient[17421]: SENDING DIRECT. The new error is reported every three minutes. Is this related?
-
You may want to check the logs, maybe the provider is setting the DHCP lease time very short.
Is all that message means is that the DHCP client process is sending a request (via the dc0 interface) to the provider's DHCP server directly (instead of sending to broadcast). This is normal when trying to renew your lease. If this happens every three minutes, that is indeed odd. It might be worth testing a 1.2.3 snapshot. Perhaps the changes in the 7.2 dhclient will help. -
Here is what I found on the DHCPREQUEST error.
First, I noticed an endless stream of entries on the Firewall log from 10.236.179.1 (a private address?) to, alternately, (a) the public ip address of my WAN, (b) 255.255.255.255:68, or
to 224.0.0.1. The protocol indicated was either UDP or IGMP. Sometimes no port was indicated, but more often port 67 or 68 would be indicated. The entry would occur about every two minutes, but sometimes more frequently.It occurred to me that this might be related to the DHCPREQUEST problem, although I have only the barest guess why. If the cable modem is, for some reason, generating a DHCPREQUEST continually, it might be because the firewall rules are rejecting the request continually. On further reflection, all of the problems might be related as they seem to stem from the cable modem's configuration.
I have done two things which seem to have addressed the problem. First, I added a WAN firewall rule to pass a UDP or IGMP request from 10.236.179.1. Second, I unchecked the box "Block private networks" on the WAN page. It seemed, given the problems I have had with a private IP address on the cable modem, that it would help.
The DHCPREQUEST error is no longer appearing in my System log, and the Firewall log no longer shows that the traffic from 10.236.179.1 has been dropped. It has been so long since my log files were really useful, given all of the repeated entries, that it is now a real pleasure to review them.
Having said and done this, I do not have a deep understanding of why this works, other than the obvious, or more importantly whether it is a good idea. I am open to feedback on that just for my knowledge.
