Re: crash with ipfw nat on mips32
Erk. I'll go see if I can figure out what's going on. Thanks! This is really quite grr-y. -a On 21 March 2018 at 23:35, Andrey V. Elsukov wrote: > On 22.03.2018 09:23, Adrian Chadd wrote: >> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) >> [ thread pid 11 tid 100010 ] >> Stopped at 0 >> db> bt >> Tracing pid 11 tid 100010 td 0x80673b40 >> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144 >> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120 >> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88 >> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0 >> db> > > Hi, > > this is not NAT related, it is ipfw's dynamic states. > I'm not sure, but this is seems related to ConcurrencyKit. > > -- > WBR, Andrey V. Elsukov > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: crash with ipfw nat on mips32
On 22.03.2018 10:31, Adrian Chadd wrote: > Erk. I'll go see if I can figure out what's going on. > > Thanks! This is really quite grr-y. >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) >>> [ thread pid 11 tid 100010 ] >>> Stopped at 0 >>> db> bt >>> Tracing pid 11 tid 100010 td 0x80673b40 >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144 >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120 >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88 >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0 >>> db> >> >> this is not NAT related, it is ipfw's dynamic states. >> I'm not sure, but this is seems related to ConcurrencyKit. It looks like CK doesn't declare support for mips. Probably we need to make compat shim, that uses old implementation for platforms, that are not supported by CK. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: crash with ipfw nat on mips32
On Thu, Mar 22, 2018 at 03:52:39PM +0300, Andrey V. Elsukov wrote: > On 22.03.2018 10:31, Adrian Chadd wrote: > > Erk. I'll go see if I can figure out what's going on. > > > > Thanks! This is really quite grr-y. > >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) > >>> [ thread pid 11 tid 100010 ] > >>> Stopped at 0 > >>> db> bt > >>> Tracing pid 11 tid 100010 td 0x80673b40 > >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144 > >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120 > >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88 > >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0 > >>> db> > >> > >> this is not NAT related, it is ipfw's dynamic states. > >> I'm not sure, but this is seems related to ConcurrencyKit. > > It looks like CK doesn't declare support for mips. > Probably we need to make compat shim, that uses old implementation for > platforms, that are not supported by CK. > Hi, mips should be supported by using the compiler builtins, as is riscv. If there is a crash, it is definitively a bug. Can you guys tell me which CK function dies that badly ? Regards, Olivier ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ether <-> wlan failover still is broken (was: is lagg (re+wlan) working on 11.0-RELEASE?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, while having no any problem with separate (lagg less) mode, when I use ether or wlan without aggregating, I am still experiencing severe problem with ether <-> wlan failover after upgrade to 11.1 I decided to give another try to the handbook Example 30.3. https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless it still does *not* work for me after wlan MAC address change (to the one of the ethernet as it's described in the handbook), wpa_supplicant becomes unable to associate with AP > uname -a FreeBSD 11.1-RELEASE-p8 #0 > pciconf -lv ath0@pci0:3:0:0:class=0x028000 card=0x1785103c chip=0x0032168c rev=0x01 hdr=0x00 vendor = 'Qualcomm Atheros' device = 'AR9485 Wireless Network Adapter' class = network re0@pci0:7:0:0: class=0x02 card=0x3387103c chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet does anybody else face same trouble, please? - -- Zeus V. Panchenko jid:z...@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -BEGIN PGP SIGNATURE- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWrO2QQAKCRCveOk+D/ej KrUjAJoCx6H9QgcJH97lMklyQZfOy0PrnQCggDki8cJvqdQl+mgWCLkNGePC1Fc= =vSkJ -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
On Wed, Mar 21, 2018 at 02:19:43PM -0700, Ronald F. Guilmette wrote: [...] > P.S. It is my assumption that the kind of thing I'm looking for, if > it exists at all, will be found somewhere below the application layer. > I do not rule out however that there may be some way of differentiating > the two cases described above by looking at application layer responses > for some certain common applications. As far as I know however, it is > not possible to make the desired differentiation on the basis of > application layer responses for most typical network applications, > e.g. various makes and model numbers of servers for HTTP, HTTPS, > SMTP, SSH, DNS, etc. Of course, if I have simply missed something, > and if there is in fact a way to differentiate the two cases on the > basis of responses sent for any of these application protocols, then > I sure would like to know about that too. DNS: if both A and A' running open recursive DNS servers (bad idea in modern internet, but..) it's possible to use TTL field to differentiate. Scenario: create some DNS record with good enough TTL of one hour. Ask A about this record, get answer with TTL = 3600. Wait for ten seconds, then ask A' about the same record. If received TTL is about 3590 - it's really likely that A and A' is the same host. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ether <-> wlan failover still is broken
On 22.03.2018 16:57, Zeus Panchenko wrote: > hi, > > while having no any problem with separate (lagg less) mode, when I use > ether or wlan without aggregating, I am still experiencing severe problem > with ether <-> wlan failover > > after upgrade to 11.1 I decided to give another try to the handbook Example > 30.3. > https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless > > it still does *not* work for me > > after wlan MAC address change (to the one of the ethernet as it's described in > the handbook), wpa_supplicant becomes unable to associate with AP It will work, if you will change ethernet's MAC address to one, what wlan interface have. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ether <-> wlan failover still is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey V. Elsukov wrote: > > It will work, if you will change ethernet's MAC address to one, what > wlan interface have. > in my previous attempts it was working this way *only* when interface was in promiscious mode but I'll try it again, thanks - -- Zeus V. Panchenko jid:z...@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -BEGIN PGP SIGNATURE- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWrPDfQAKCRCveOk+D/ej KmpfAJ4p2DAn9hAVJjc2KqS1UdS+eN8hNgCfXrzZzefzSrBa6XquJhDru+hBBjU= =1maj -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ether <-> wlan failover still is broken
22.03.2018 20:57, Zeus Panchenko wrote:
> while having no any problem with separate (lagg less) mode, when I use
> ether or wlan without aggregating, I am still experiencing severe problem
> with ether <-> wlan failover
>
> after upgrade to 11.1 I decided to give another try to the handbook Example
> 30.3.
> https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless
>
> it still does *not* work for me
>
> after wlan MAC address change (to the one of the ethernet as it's described in
> the handbook), wpa_supplicant becomes unable to associate with AP
>
>> uname -a
> FreeBSD 11.1-RELEASE-p8 #0
>
>> pciconf -lv
> ath0@pci0:3:0:0:class=0x028000 card=0x1785103c chip=0x0032168c
> rev=0x01 hdr=0x00
> vendor = 'Qualcomm Atheros'
> device = 'AR9485 Wireless Network Adapter'
> class = network
> re0@pci0:7:0:0: class=0x02 card=0x3387103c chip=0x816810ec rev=0x06
> hdr=0x00
> vendor = 'Realtek Semiconductor Co., Ltd.'
> device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
> class = network
> subclass = ethernet
>
>
> does anybody else face same trouble, please?
lagg uses fabricated MAC by default and your WiFi connection does not seem like
that.
You should try forcing lagg to use MAC of wireless card instead of fabricated
one:
ifconfig lagg0 ether $(ifconfig wlan0 | awk '/hwaddr/ {print $2}')
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ether wlan lagg works only with hint.ath.0.macaddr set (was: ether <-> wlan failover still is broken)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey V. Elsukov wrote: > > It will work, if you will change ethernet's MAC address to one, what > wlan interface have. > yes, for me it works *only* if the interface is in promiscious mode, just have checked BUT! what finally helped me is this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213207#c13 /boot/loader.conf hint.ath.0.macaddr="MAC:ADDRESS:OF:THE:ETHERNET:INTERFACE" - -- Zeus V. Panchenko jid:z...@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -BEGIN PGP SIGNATURE- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWrPN0AAKCRCveOk+D/ej KqWqAKCd7GWqyXLMZtLWtOuWfR+eOVD6OQCg11ZcsR5SIsb5phXu3resUgTRnO0= =y2sk -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ether <-> wlan failover still is broken
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene Grosbein wrote:
>
> You should try forcing lagg to use MAC of wireless card instead of fabricated
> one:
> ifconfig lagg0 ether $(ifconfig wlan0 | awk '/hwaddr/ {print $2}')
>
as I wrote in previous message, it works *only* when interface is in
promiscious mode ... alas
- --
Zeus V. Panchenko jid:z...@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
-BEGIN PGP SIGNATURE-
iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWrPONQAKCRCveOk+D/ej
KlaJAJ98/YNjbI1XZwsn3RGHKP0Of/mfhACg7CgYCHpSR6e7NjG4CGLxMl2pV5Y=
=+aRw
-END PGP SIGNATURE-
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
On 03/22/18 09:02, Alexandre Snarskii wrote: On Wed, Mar 21, 2018 at 02:19:43PM -0700, Ronald F. Guilmette wrote: [...] P.S. It is my assumption that the kind of thing I'm looking for, if it exists at all, will be found somewhere below the application layer. I do not rule out however that there may be some way of differentiating the two cases described above by looking at application layer responses for some certain common applications. As far as I know however, it is not possible to make the desired differentiation on the basis of application layer responses for most typical network applications, e.g. various makes and model numbers of servers for HTTP, HTTPS, SMTP, SSH, DNS, etc. Of course, if I have simply missed something, and if there is in fact a way to differentiate the two cases on the basis of responses sent for any of these application protocols, then I sure would like to know about that too. DNS: if both A and A' running open recursive DNS servers (bad idea in modern internet, but..) it's possible to use TTL field to differentiate. Scenario: create some DNS record with good enough TTL of one hour. Ask A about this record, get answer with TTL = 3600. Wait for ten seconds, then ask A' about the same record. If received TTL is about 3590 - it's really likely that A and A' is the same host. If A and A' do resolve beyond their SOA for clients outside of their domain. That was vulnerable for abuse, and hardly anybody does that these days. Am I missing something? Valeri ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: crash with ipfw nat on mips32
oh and xcompiled with gcc-6.x . -a On 22 March 2018 at 09:09, Adrian Chadd wrote: > I dunno yet; this is a very embedded mips74k box. :) > > > -a > > On 22 March 2018 at 06:00, Olivier Houchard wrote: >> On Thu, Mar 22, 2018 at 03:52:39PM +0300, Andrey V. Elsukov wrote: >>> On 22.03.2018 10:31, Adrian Chadd wrote: >>> > Erk. I'll go see if I can figure out what's going on. >>> > >>> > Thanks! This is really quite grr-y. >>> >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) >>> >>> [ thread pid 11 tid 100010 ] >>> >>> Stopped at 0 >>> >>> db> bt >>> >>> Tracing pid 11 tid 100010 td 0x80673b40 >>> >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144 >>> >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120 >>> >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88 >>> >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0 >>> >>> db> >>> >> >>> >> this is not NAT related, it is ipfw's dynamic states. >>> >> I'm not sure, but this is seems related to ConcurrencyKit. >>> >>> It looks like CK doesn't declare support for mips. >>> Probably we need to make compat shim, that uses old implementation for >>> platforms, that are not supported by CK. >>> >> >> Hi, >> >> mips should be supported by using the compiler builtins, as is riscv. If >> there >> is a crash, it is definitively a bug. Can you guys tell me which CK >> function dies that badly ? >> >> Regards, >> >> Olivier ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: crash with ipfw nat on mips32
I dunno yet; this is a very embedded mips74k box. :) -a On 22 March 2018 at 06:00, Olivier Houchard wrote: > On Thu, Mar 22, 2018 at 03:52:39PM +0300, Andrey V. Elsukov wrote: >> On 22.03.2018 10:31, Adrian Chadd wrote: >> > Erk. I'll go see if I can figure out what's going on. >> > >> > Thanks! This is really quite grr-y. >> >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) >> >>> [ thread pid 11 tid 100010 ] >> >>> Stopped at 0 >> >>> db> bt >> >>> Tracing pid 11 tid 100010 td 0x80673b40 >> >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144 >> >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120 >> >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88 >> >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0 >> >>> db> >> >> >> >> this is not NAT related, it is ipfw's dynamic states. >> >> I'm not sure, but this is seems related to ConcurrencyKit. >> >> It looks like CK doesn't declare support for mips. >> Probably we need to make compat shim, that uses old implementation for >> platforms, that are not supported by CK. >> > > Hi, > > mips should be supported by using the compiler builtins, as is riscv. If there > is a crash, it is definitively a bug. Can you guys tell me which CK > function dies that badly ? > > Regards, > > Olivier ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ether wlan lagg works only with hint.ath.0.macaddr set (was: ether <-> wlan failover still is broken)
Hi, I keep telling people that right now it's not something I at least have time to fix up. :) -a On 22 March 2018 at 08:37, Zeus Panchenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Andrey V. Elsukov wrote: >> >> It will work, if you will change ethernet's MAC address to one, what >> wlan interface have. >> > > yes, for me it works *only* if the interface is in promiscious mode, > just have checked > > BUT! what finally helped me is this: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213207#c13 > > /boot/loader.conf > > hint.ath.0.macaddr="MAC:ADDRESS:OF:THE:ETHERNET:INTERFACE" > > - -- > Zeus V. Panchenko jid:z...@im.ibs.dn.ua > IT Dpt., I.B.S. LLC GMT+2 (EET) > -BEGIN PGP SIGNATURE- > > iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWrPN0AAKCRCveOk+D/ej > KqWqAKCd7GWqyXLMZtLWtOuWfR+eOVD6OQCg11ZcsR5SIsb5phXu3resUgTRnO0= > =y2sk > -END PGP SIGNATURE- > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: crash with ipfw nat on mips32
On Thu, Mar 22, 2018 at 09:09:37AM -0700, Adrian Chadd wrote: > oh and xcompiled with gcc-6.x . > > I'm not very knowledgable with mips. Is it possible gcc wrongly generated an instruction that is not supported by mips74k ? I suppose not, or it wouldn't lead to a TLB miss. Olivier > > On 22 March 2018 at 09:09, Adrian Chadd wrote: > > I dunno yet; this is a very embedded mips74k box. :) > > > > > > -a > > > > On 22 March 2018 at 06:00, Olivier Houchard wrote: > >> On Thu, Mar 22, 2018 at 03:52:39PM +0300, Andrey V. Elsukov wrote: > >>> On 22.03.2018 10:31, Adrian Chadd wrote: > >>> > Erk. I'll go see if I can figure out what's going on. > >>> > > >>> > Thanks! This is really quite grr-y. > >>> >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) > >>> >>> [ thread pid 11 tid 100010 ] > >>> >>> Stopped at 0 > >>> >>> db> bt > >>> >>> Tracing pid 11 tid 100010 td 0x80673b40 > >>> >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144 > >>> >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120 > >>> >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88 > >>> >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0 > >>> >>> db> > >>> >> > >>> >> this is not NAT related, it is ipfw's dynamic states. > >>> >> I'm not sure, but this is seems related to ConcurrencyKit. > >>> > >>> It looks like CK doesn't declare support for mips. > >>> Probably we need to make compat shim, that uses old implementation for > >>> platforms, that are not supported by CK. > >>> > >> > >> Hi, > >> > >> mips should be supported by using the compiler builtins, as is riscv. If > >> there > >> is a crash, it is definitively a bug. Can you guys tell me which CK > >> function dies that badly ? > >> > >> Regards, > >> > >> Olivier ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
In message <4db72389-d167-4152-a15f-4710c54b2...@your.org>, Kevin Day wrote: >Does the ssh-keyscan tool do what you want? I never knew about that tool until now. But yes, indeed, that may be the exact kind of magic I was looking for. Thank you. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
In message <201803220250.w2m2owmf024...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Grimes" wrote: >You are not going to prove the "control of the exact same Bad Actor" >without a warrant to search and seize. Well, as someone else noted, if two IP addresses yield the exact same SSH key, that is fairly definitive. If I planned to be going into a court of law, then yes, a warrant would be both appropriate and required. But going into court is not among my goals. >> >What you ask I believe could be done, but it non trivial and >> >would require a very good understanding of both forensics >> >and the differing ways that TCP/IP is implemented. >> >> I like to think that I am a quick learner. Please proceed with the >> lesson. > >The rates for lessons in Forensics start at reasonable enough >amounts, you can contact me off list if you wish to persue that. Thanks for your support. As i am doing what I am doing on a volunteer (unpaid) basis, I'm afraid that I will not be able to take you up on your generous offer. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
In message <20180322140233.ga79...@staff.retn.net>, Alexandre Snarskii wrote: >DNS: if both A and A' running open recursive DNS servers (bad idea in >modern internet, but..) it's possible to use TTL field to differentiate. >Scenario: create some DNS record with good enough TTL of one hour. Ask A >about this record, get answer with TTL = 3600. Wait for ten seconds, then >ask A' about the same record. If received TTL is about 3590 - it's really >likely that A and A' is the same host. Thank you! Yes. This, and checking the SSH key, seem to both be very promising solutions to the problem. I will be investigating and trying both, to try to establish how well they might work in practice. It will be great if both work, because some bad actors will be running SSH (on a known or findable port) and others won't be. And likewise, some bad actors will be running their own name servrs and others won't be. So it will be Good to have several tools in the toolbox. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
In message <4ce048ad-873e-795e-aae0-8d795d9bb...@kicp.uchicago.edu>, Valeri Galtsev wrote: >If A and A' do resolve beyond their SOA for clients outside of their >domain. That was vulnerable for abuse, and hardly anybody does that >these days. Am I missing something? As I understand it, sadly, there are still a couple of zillion open recursive resolvers out there. I would anticipate that Bad Actors are neither more likely nor less likely than the general poulation to put such an abomination online. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Raw Sockets: Two Questions
On 2018-Mar-21 13:50:26 -0700, "Ronald F. Guilmette" wrote: > >In message <5ab2c0b1.3020...@grosbein.net>, >Eugene Grosbein wrote: > >>It does not mean you need to stick with raw sockets API. >>libpcap can be used too, as I've shown in previous letter. > >Thank you. If zmap ends up not suiting my needs, I will >definitely look into libpcap. Since no-one else has mentioned it, another option would be divert(4), which is part of IPFW. -- Peter Jeremy signature.asc Description: PGP signature
Re: Same host or different? How can you tell "over the wire"?
> > In message <201803220250.w2m2owmf024...@pdx.rh.cn85.dnsmgr.net>, > "Rodney W. Grimes" wrote: > > >You are not going to prove the "control of the exact same Bad Actor" > >without a warrant to search and seize. > > Well, as someone else noted, if two IP addresses yield the exact same > SSH key, that is fairly definitive. Wrong, as someone else pointed out that is simply a mater of copying the /etc/ssh/*host* key files over to the other host. This also happens when people clone machines... so is actual more common than one might think. You can be pretty sure they are different machines, but you can not assertain they are the same machine with this information. You can assert nothing about control with this information. You can be pretty sure they are under the same control, but not provable. Anyone with elivated privledge access to A can copy the /etc/ssh/* files to A'. > If I planned to be going into a court of law, then yes, a warrant > would be both appropriate and required. But going into court is > not among my goals. > > >> >What you ask I believe could be done, but it non trivial and > >> >would require a very good understanding of both forensics > >> >and the differing ways that TCP/IP is implemented. > >> > >> I like to think that I am a quick learner. Please proceed with the > >> lesson. > > > >The rates for lessons in Forensics start at reasonable enough > >amounts, you can contact me off list if you wish to persue that. > > Thanks for your support. As i am doing what I am doing on a volunteer > (unpaid) basis, I'm afraid that I will not be able to take you up on > your generous offer. -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Same host or different? How can you tell "over the wire"?
In message <201803221856.w2miurjh027...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Grimes" wrote: >> Well, as someone else noted, if two IP addresses yield the exact same >> SSH key, that is fairly definitive. > >Wrong, as someone else pointed out that is simply a mater of >copying the /etc/ssh/*host* key files over to the other host. >This also happens when people clone machines... so is actual >more common than one might think. > >You can be pretty sure they are different machines, but you >can not assertain they are the same machine with this information. >You can assert nothing about control with this information. > >You can be pretty sure they are under the same control, but >not provable. Anyone with elivated privledge access to A >can copy the /etc/ssh/* files to A'. Your points are, of course, valid. However in the absence of the scenario where Bad Actor `B' has broken in to some machine which is under the control of Bad Actor `A', and where B has then absconded with a copy of A's SSH key (and then used that himself as an SSH key) for my limited purposes, at least, the sighting of two identical SSH keys on two different IP addresses strongly suggests a high likelihood that the two IP addreses are indeed under the control of a single party. (I should perhaps explain and emphasize that I personally am not by any means a member of law enforcement. I do not have the power to deprive any party of either life or freedom or property. I am thus, quite reasonably able to accept a level of "proof" which may be quite persuasive, even if it does not rise to the level of "beyond a reasonable doubt". I am just doing security research... not prosecuting anybody.) ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multicast/SSDP not working (on VLAN interface)
@sunp...@freebsd.org: as you are the (brand new?) maintainer of the
miniDLNA port for FreeBSD, my hopes are with you :D
tl;dr
"setsockopt" should be replaced by "sourcefilter" (at least in
minissdp.c's "AddMulticastMembership)
On 22.03.18 01:15, Rodney W. Grimes wrote:
...
Try as a very first rules:
ipfw add 1 log allow ip from any to 224.0.0.0/4
ipfw add 2 log allow ip from 224.0.0.0/4 to any
DO NOT put any restricting clauses on these.. if this makes things
work simply move them down a few rules until you find the point
at which things stop working.
I tried this; to no avail.
But it got me on the right track! MiniDLNA was actually (trying to) send
IGMPv3 packets (224.0.0.22) back to the client but they were following
the default route!
The problem is here (please excuse if I do not get all the terminology
right, I am not a network programmer):
The function "AddMulticastMembership" in minissdp.c uses the "ip_mreqn"
struct to call "setsockopt" for "IP_ADD_MEMBERSHIP".
It is trying to use an interface index "imr.imr_ifindex =
iface->ifindex" in "ip_mreqn".
The code I am talking about can be found here:
https://sourceforge.net/p/minidlna/git/ci/master/tree/minissdp.c#l69
Using an interface index for "IP_ADD_MEMBERSHIP" is not supported (since
FreeBSD 7.0):
-
A host must become a member of a multicast group before it can receive
datagrams sent to the group. To join a multicast group, use the
IP_ADD_MEMBERSHIP option:
struct ip_mreq mreq;
setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
where mreq is the following structure:
struct ip_mreq {
struct in_addr imr_multiaddr; /* IP multicast address of group */
struct in_addr imr_interface; /* local IP address of interface */
}
imr_interface should be set to the IP address of a particular multicast-
capable interface if the host is multihomed. It may be set to
INADDR_ANY to choose the default interface, although this is not
recommended; this is considered to be the first interface corresponding
to the default route. Otherwise, the first multicast-capable interface
configured in the system will be used.
Prior to FreeBSD 7.0, if the imr_interface member is within the network
range 0.0.0.0/8, it is treated as an interface index in the system
interface MIB, as per the RIP Version 2 MIB Extension (RFC-1724). In
versions of FreeBSD since 7.0, this behavior is no longer supported.
Developers should instead use the RFC 3678 multicast source filter APIs;
in particular, MCAST_JOIN_GROUP.
-
As documented here:
https://www.freebsd.org/cgi/man.cgi?query=ip&apropos=0&sektion=4&manpath=FreeBSD+11.1-RELEASE&arch=default&format=html
I have verified that things start to work when I forced the "other
execution path" in "AddMulticastMembership" (using "ip_mreq" instead of
"ip_mreqn"; I have achieved this by changing the "#ifdef
HAVE_STRUCT_IP_MREQN" statement into it's negated form "#ifndef
HAVE_STRUCT_IP_MREQN").
Unfortunately I am not qualified to (properly) fix this :(
I read the statement that MCAST_JOIN_GROUP should be used (meaning
replace "setsockopt" with "sourcefilter", if I get that correctly). But
I do not really understand what that means/how to do that.
https://www.freebsd.org/cgi/man.cgi?query=sourcefilter&apropos=0&sektion=3&manpath=FreeBSD+11.1-RELEASE&arch=default&format=html
If someone could point me in the right direction (a tutorial how
"sourcefilter" must be used for example), I might be able to come up
with something that can be developed into a proper patch. Of course, if
someone can fix this right away, that would be even better.
Best regards
andreas
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Need Netgraph Help [fixed]
Hi John, did you ever try out my version?
Julian
On 7/1/18 4:06 am, Julian Elischer wrote:
On 7/1/18 4:02 am, John Lyon wrote:
Thanks for the clarification and all the help.
After Marko clarified that that edges/hooks are bidirectional, I
was able to get it working WAN to LAN and LAN to WAN by using a
pair of one2many and ETF nodes.
The commands were (from memory):
#Create Unfiltered WAN Path
ngctl mkpeer igb0: one2many lower one
ngctl name igb0:lower wanmux
ngctl mkpeer wanmux: etf many0 downstream
ngctl name wanmux:many0 wanfilter
ngctl connect wanfilter: igb0: nomatch upper
#Create Unfilter LAN Path
ngctl mkpeer igb1: one2many lower one
ngctl name igb1:lower lanmux
ngctl mkpeer lanmux: etf many0 downstream
ngctl name lanmux:many0 lanfilter
ngctl connect lanfilter: igb1 nomatch upper
#Cross Connect Two Paths
ngctl connect wanfilter wanmux waneapout many1
ngctl connect lanfilter lanmux laneapout many1
#Filter Cross Connections
ngctl msg wanfilter: 'setfilter { matchhook="waneapout"
ethertype=0x888e }'
ngctl msg lanfilter: 'setfilter { matchhook="laneapout"
ethertype=0x888e }'
The graph looks like this:
igb0] <> [mux0] <---> [etf0] <> [igb0
\ /
X
/ \
igb1] <> [mux1] <---> [etf1] <> [igb1
It was conceptually easier for me to wrap my head around and it
appears to work (somewhat). But if I can get it to work, I like
Julian's approach better as it is simpler and uses fewer nodes.
etf includes a mux/demux.. the link is bidirectional.
Thanks again for all the help!
John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc
On Sat, Jan 6, 2018 at 2:39 PM, Julian Elischer > wrote:
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
