Em 21-05-2014 13:43, bodie escreveu: > On 21.05.2014 17:24, André Lucas wrote: >> w.r.t. Apple devices, this happens when the Bonjour Sleep Proxy ( >> https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy) is at work. If you >> have >> one or more Macs and one or more Airport base stations these messages >> will >> appear when the Mac sleeps and when the Airport wakes it in response to >> network traffic. >> >> -André > > Not aware if there are Airport base stations, but some Macs are there > for sure. Right now DragonFlyBSD latest snapshot on laptop, wifi is > working at home, but that was with OpenBSD too. Need to wait till > tomorrow morning so that I can test behavior of Dfly in our corporate > network. It will be even more interesting if it will be working > without the issues. > > I'm more and more inclined to terribly configured APs, but most > probably I will not get chance to get my hands on them. In any case > trying to get some details about them like model and such. > > >> >> >> On 21 May 2014 15:50, bodie <bodz...@openbsd.cz> wrote: >> >>> 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. > Trust me, if you are seeing weird things using OpenBSD, but on Linux you don't, there are weird things happening in the network. I know that it's not the best thing to do, but you could try to add your iwn0 to a bridge(4) interface, and create a rule to tag packets, and you could use pf(4) to block one of the access points. I'm not sure if it will work, but might be worth the try.
Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
