Hi Ian, always good to hear from you, but, puh, this is awakening old memories, and I'm not even sure those are the good ones.
Yeah, I remember, the interval for the Gratuitious ARP packets isn't what it's supposed to be according to firmware comments. Uh. Maybe we just clocked the CPU core lower than the author of the firmware thought? No, I think I ruled that out back in the day, but a lot of RFNoCization happened since then, so intervals might be different now than they were then. Hm. I really don't think taking apart that CPU design will do us much good, both practically and psychologically, if we don't know what exactly we're fixing. Do you have an idea on how to narrow that down? I'm not to keen on rebuilding a bunch of FPGA images for testing without a build server... Cheers, Marcus On 24.03.20 07:29, Ian Buckley wrote: > Old thread but for the sake of a knowledge archive: The ICMP IR traffic is > the X310 Link state routing table updates…it’s unique to the X310, not > present in the N210 > And I also, only tonight, observed other X310 firmware driven network > services running at ~3x the interval I expected Marcus…so something is off > globally in the firmware or the timer register that drives it. > -Ian > >> On Jan 6, 2017, at 6:55 AM, Marcus Müller via USRP-users >> <usrp-users@lists.ettus.com> wrote: >> >> Hi Vladica, >> >> err, that's a strange problem; are you sure you want to change the >> behaviour of your SDR devices to suit the security product that you pay >> for, in order to make your network easier to secure? Frankly, if that >> product makes any problems: It looks like some software that runs on a >> plain Linux system, probably. Use ebtables to simply make that system >> deaf to packets coming from your USRP's MAC address. Or, if your local >> switch allows that, simply put the USRP in a separate VLAN. >> >> By the way, the N210 also answers with broadcast packets to discovery >> requests, if I remember correctly. So if that problem really is >> X310-specific, then it's probably due to the periodic gratitious ARP >> packets (garp,[1]). That is, the X300 informs the devices on the network >> about the fact that the IP address it has is answered by its MAC >> address; that way, there's an ARP table entry for the X310. You can >> actually just build the firmware yourself and comment out the garp() >> call, if you're inclined to do so, then >> >> To be honest, I see a strange behaviour related to that; namely, the >> firmware in x300_main.c [2] claims that the garp() function gets called >> every (roughly, integer division...) 1 millisecond, and the garp() >> function then only does something every 60,000 calls – i.e. one packet >> every minute. I just listened for those, and they don't happen at 60s >> periods, but at 192.65s periods. Which is kind of strange. I'll raise >> this with the others. >> >> Best regards, >> >> Marcus >> >> [1] https://wiki.wireshark.org/Gratuitous_ARP >> [2] >> https://github.com/EttusResearch/uhd/blob/master/firmware/usrp3/x300/x300_main.c#L452 >> >> On 06.01.2017 15:03, Vladica Sark via USRP-users wrote: >>> Hi there, >>> >>> I have a few X310s. Some of them are connected to a desktop PC but I >>> want to access some of them via my laptop. the laptop is connected to >>> a local switch and the X310 is also connected to it. In order to have >>> internet access the switch is connected to the wall ethernet plug. >>> This plug is monitored by macmon and disconnects the plug from LAN, if >>> strange mac appears. >>> >>> The problem appears due to the ICMP information request frames >>> broadcasted by the X310. Since this is a broadcast, it is also >>> forwarded to the wall plug and the macmon disconnects it from the LAN. >>> >>> >>> With the N210 I didn't had those problems, probably because they do >>> not transmit broadcasts. >>> >>> The problem is that i have already a few mac addresses in the macmon >>> and entering more would require additional licenses. >>> >>> Is there chance to disable these broadcasts? >>> >>> BR, >>> Vladi >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
