Re: BPF to filter/mod ARP
> Hi group, > > Maybe someone can help me with this question - as I am usually only > looking at L4 and the top side of L3 ;) > > In order to validate a peculiar switches behavior, I want to adjust some > fields in gracious arps sent out by an interface, after a new IP is > assigned or changed. Gracious or Gratuitous? > > I believe BPF can effectively filter on arbitrary bit patterns and > modify packets on the fly. It can. > > However, as ARP doesn't seem to be accessible in the ipfw > infrastructure, I was wondering how to go about setting up an BPF to > tweak (temporarily) some of these ARPs to validate how the switch will > behave. ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, so very hard to do much with it in ipfw, but perhaps the layer2 keyword, and some use of mac-type can get it to match an arp packet. Arp is ethernet type 0x806. ipfw add 111 count log all from any to any layer2 mac-type arp That does seem to work ipfw -a list 111 001114 0 count log ip from any to any layer2 mac-type 0x0806 Also normally ipfw does NOT pick packets up early enough to see them, to get the layer2 option to work you need: sysctl net.link.ether.ipfw=1 so that the filters at ether_demux get turned on. So perhaps use a divert rule and send them to a socket where a program can mangle them, and then return them to ipfw and hopefully the kernel does what you want after that... > (I need to validate, if there is some difference when the target > hardware address doesn't conform to RFC5227 - which states it SHOULD be > zero and is ignored on the receiving side; i have reasons to believe > that the switch needs either a target hardware address of > ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's > entries.) > > Thanks a lot! > > Richard > -- Rod Grimes rgri...@freebsd.org
Re: BPF to filter/mod ARP
> On 1. Mar 2023, at 22:10, Scheffenegger, Richard > wrote: > >>> On 1. Mar 2023, at 21:33, Scheffenegger, Richard >>> wrote: >>> >>> Hi group, >>> >>> Maybe someone can help me with this question - as I am usually only looking >>> at L4 and the top side of L3 ;) >> >>> In order to validate a peculiar switches behavior, I want to adjust some >>> fields in gracious arps sent out by an interface, after a new IP is >>> assigned or changed. > >> Wouldn't scapy allow you to do this kind of testing? > > Unfortunately not - I don't want to forge another packet, I want to make sure > only the specific one is being sent, with the standard GARP retransmissions > and so on. Can't you test what you want to test by generating all the required packets from scapy? ARP is a pretty simple protocol... Best regards Michael > > Richard >
RE: BPF to filter/mod ARP
>> On 1. Mar 2023, at 21:33, Scheffenegger, Richard wrote: >> >> Hi group, >> >> Maybe someone can help me with this question - as I am usually only looking >> at L4 and the top side of L3 ;) > >> In order to validate a peculiar switches behavior, I want to adjust some >> fields in gracious arps sent out by an interface, after a new IP is assigned >> or changed. > Wouldn't scapy allow you to do this kind of testing? Unfortunately not - I don't want to forge another packet, I want to make sure only the specific one is being sent, with the standard GARP retransmissions and so on. Richard
mlx5en & tcpdump -Q
Related to the other issue just mentioned, I found that when trying to perform unidirectional packet captures using the tcpdump -Q option, when trying this against a CX5 NIC, i get this error message: tcpdump: e4a: pcap_setdirection() failed: Setting direction is not implemented on this platform (this is a 13.0 kernel, can not really check main). Does anyone know if this functionality is available already, or any plans to implement this for mlx5en ? Thanks, Richard OpenPGP_0x17BE5899E0B1439B.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: BPF to filter/mod ARP
> On 1. Mar 2023, at 21:33, Scheffenegger, Richard wrote: > > Hi group, > > Maybe someone can help me with this question - as I am usually only looking > at L4 and the top side of L3 ;) > > In order to validate a peculiar switches behavior, I want to adjust some > fields in gracious arps sent out by an interface, after a new IP is assigned > or changed. Wouldn't scapy allow you to do this kind of testing? Best regards Michael > > I believe BPF can effectively filter on arbitrary bit patterns and modify > packets on the fly. > > However, as ARP doesn't seem to be accessible in the ipfw infrastructure, I > was wondering how to go about setting up an BPF to tweak (temporarily) some > of these ARPs to validate how the switch will behave. > > (I need to validate, if there is some difference when the target hardware > address doesn't conform to RFC5227 - which states it SHOULD be zero and is > ignored on the receiving side; i have reasons to believe that the switch > needs either a target hardware address of ff:ff:ff:ff:ff:ff or the local > interface MAC, to properly update it's entries.) > > Thanks a lot! > > Richard >
BPF to filter/mod ARP
Hi group, Maybe someone can help me with this question - as I am usually only looking at L4 and the top side of L3 ;) In order to validate a peculiar switches behavior, I want to adjust some fields in gracious arps sent out by an interface, after a new IP is assigned or changed. I believe BPF can effectively filter on arbitrary bit patterns and modify packets on the fly. However, as ARP doesn't seem to be accessible in the ipfw infrastructure, I was wondering how to go about setting up an BPF to tweak (temporarily) some of these ARPs to validate how the switch will behave. (I need to validate, if there is some difference when the target hardware address doesn't conform to RFC5227 - which states it SHOULD be zero and is ignored on the receiving side; i have reasons to believe that the switch needs either a target hardware address of ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's entries.) Thanks a lot! Richard OpenPGP_0x17BE5899E0B1439B.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully
On 1 Mar 2023, at 5:36, Michael Gmelin wrote: >> On 1. Mar 2023, at 11:35, Yuri wrote: >> >> Windows system connects to FreeBSD through ssh and then this connection >> dies because of WiFi or VPN issues. >> >> FreeBSD still has the sshd process alive for this connection for 30+ minutes. >> >> TCP keepalive is enabled on the FreeBSD host: >> >> $ sysctl net.inet.tcp.always_keepalive >> net.inet.tcp.always_keepalive: 1 >> >> Shouldn't TCP keepalive kill this sshd process after 3-4 minutes because >> this connection isn't alive? >> > > Keepalives start after net.inet.tcp.keepidle milliseconds (2h by default). When this happens to me, I generally log into the server again and use write(1) to send a message to that tty (a newline will do). That probes the connection and causes a reset, and the session gets cleaned up. I use a longer keepidle value for other reasons. Mike
Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully
> On 1. Mar 2023, at 11:35, Yuri wrote: > > Windows system connects to FreeBSD through ssh and then this connection dies > because of WiFi or VPN issues. > > FreeBSD still has the sshd process alive for this connection for 30+ minutes. > > TCP keepalive is enabled on the FreeBSD host: > > $ sysctl net.inet.tcp.always_keepalive > net.inet.tcp.always_keepalive: 1 > > Shouldn't TCP keepalive kill this sshd process after 3-4 minutes because this > connection isn't alive? > Keepalives start after net.inet.tcp.keepidle milliseconds (2h by default). Cheers
sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully
Windows system connects to FreeBSD through ssh and then this connection dies because of WiFi or VPN issues. FreeBSD still has the sshd process alive for this connection for 30+ minutes. TCP keepalive is enabled on the FreeBSD host: $ sysctl net.inet.tcp.always_keepalive net.inet.tcp.always_keepalive: 1 Shouldn't TCP keepalive kill this sshd process after 3-4 minutes because this connection isn't alive? Yuri
