On 21.05.2014 16:36, Giancarlo Razzolini wrote:
Em 21-05-2014 11:09, Kenneth Westerback escreveu:
On 21 May 2014 07:20, bodie <bodz...@openbsd.cz> wrote:
On 21.05.2014 12:50, bodie wrote:
On 21.05.2014 11:18, bodie wrote:
Hi,
testing http://marc.info/?t=140024539000003&r=1&w=2 further and
now I
hit issue with corporate WIFI. I can connect perfectly fine to 2
of
them provided with WPA2-PSK, either with regular ifconfig or with
wpa_supplicant from packages, but the thing is that my
/var/log/messages is flooded by these messages repeating like
every
3s:
/bsd: arp info overwritten for GW_IP by MAC_1 on iwn0
/bsd: arp info overwritten for GW_IP by MAC_2 on iwn0
arp -a shows only one MAC all the time and that's MAC_2 no matter
if
I reboot or just reconnect to network. Info from inside about
setup of
those APs is:
There actually are 2 gateways having the same IP address GW_IP
and
the mac addresses belong to them. They work as failover and also
load
balacer.
Not sure if it's because of that or because of ARP flooding in
/var/log/messages, but performance of those WiFi is quite strange
like
ping replies over 20ms, a lot of web services doesn't work, takes
years to connect, some are running perfectly fine immediately and
such.
So.....
1) Is there anything I can do with ARP messages in
/var/log/messages?
Nothing in man arp and some sysctl switch I found only in FreeBSD
2) Is there anything what can be tweaked from OpenBSD side to
improve
general performance of WiFi connection or is it just either AP
fix or
nothing?
Thanks a lot
Still trying to get much more info, but that setup must be
horrible.
Trying arping results in:
30 packets sent, 60 received. Always doubled response with MAC_1
and MAC_2
When trying to ping some of the internal servers they all have
123.123.123.123 IP which is of course totally wrong. Same if tried
with dig @GW_IP server_IP (as GW_IP is set as DNS by dhclient)
So now not so sure if it's terrible AP setup or if it's something
in
ARP, dhclient, ieee80211 code in OpenBSD
Even more suspicious details:
option dhcp-client-identifier 1:0:c2:c6:1c:af:ac in lease from
dhclient, but
my MAC is 00:c2:c6:1c:af:ac. It got mangled or is it on purpose?
This one I can solve. :-) It's on purpose and according to spec. the
prepended '1' indicates the type of identifier. In this case an
ethernet MAC.
(investigating in the meantime of course :-))
dhcp-server-identifier is IP of totally different subnet (10..)
instead of
You can always add a 'reject' statement in your dhclient.conf to
ignore suspicious dhcp servers. As the man page says "although it
should be a last resort - better to track down the bad DHCP server
and
fix it.". Assuming it turns out to be a rogue or misconfigured dhcp
server. It seems unlikely from the other symptoms you mention.
192... of that AP/GW
Well, there is no reason the dhcp server should be on the AP/GW. Of
course, no reason it shouldn't.
A tcpdump (tcpdump -i <blah> -s 2000 -vv -X) might show you who is
sending what.
.... Ken
Well,
Without you providing the mac address of your gateways/aps, I can
only guess. But I know some access points do very funny things. The
most
notorious example are apple airports. It will simply change your mac
with their own and anything on the wired side of the lan will get
theses
arp messages. But it seems to me more likely to be something
misconfigured in your network.
Cheers,
Well trying to test on other BSD, but PC-BSD doesn't work on this
laptop, Dfly is working, but on latest there's bug preventing use of
WiFi which will be solved in tomorrow snapshot, release doesn't boot at
all so far, NetBSD doesn't detect even WiFi and vga so OpenBSD is so far
only OS where I was able to test it.
Ubuntu either live or installed on this laptop is working perfectly
fine on that network with isc-dhcp-client. And even arping is returning
only one of two MACs available on those APs.
None of that is helping much so far, still on start where either
something wrong in OpenBSD or in AP, but well they will say obviously
that Windows and Linux clients doesn't have those problems, which is
true as of now.