Marcus, I don’t think any action is required at present, it’s been working “fine" for many years. But as you say the firmware as written thinks things are working on a different timescale. Luckily their is nothing real time or timing critical in there -Ian
> On Mar 24, 2020, at 6:56 AM, Marcus Müller <marcus.muel...@ettus.com> wrote: > > 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
