Rare project developers

[mc36 <>]

On 5/19/22 14:56, Edgard da Cunha Pontes wrote:
> Hi Csaba,
>
> It works!!! \o/
good to hear.... :)

> I just changed the serial console parameter "9600-8-n-1" in minicom.
anyway, you can change the freerouter behavior in the generated 
/rtr/hwdet-lin1.sh...

> image.png
>
> Taking advantage of this contact/subject, this device has only 2GB of RAM, 
> which led me to do an installation with Debian 11 i386.
> Installation of this OS proceeded normally. But unfortunately after 
> installing RARE/freeRtr I noticed a possible error/difference in the final 
> result.
>
> success-install-x64.png success-install-x86.png
for sure you can, but keep in mind that i lost long ago my last i686 machine,
so for now, freertr.org only hosts thebuilt rtr-arch.tar files for amd64 and 
arm64...
in other words, for any other architecture, you have to compile them yourself,
moreover, every time they change, you have to recompile them to have the 
fixes,
speedups, etc in place... anyway, compiling the binaries is not too difficult:
wget freertr.org/rtr.zip
cd misc/native
./c.sh
but there is an other thing to note, dpdk imho only available for 64 bit, i7+ 
grade cpus:
https://github.com/rare-freertr/freeRtr/blob/7f184fd66213b8cc4db124e9872d8c48b34f3ea1/misc/native/c.sh#L49
without that -march=corei7 knob it simply fails to compile the dpdk 
headers....
anyway, the same functionality could be achieved with the libpcap packetio
(p4emu vs p4dpdk) but obviously just a portion of the speed because every 
packet
will bounce between kernel-user-kernel to have them forwarded in the 
dataplane..

br,
cs




> Does it make any sense (is it possible) to use an x86 OS instead of an x64 
> one?
>
>
> Em qui., 19 de mai. de 2022   s 07:14, mc36 < <>> 
> escreveu:
>
>     hi,
>     the later two, enp1s0 entered promisc means to me that your system is up 
> & running...
>     one thing to note regarding how freerouter takes over the serial console 
> is that,
>     it uses 9600-8-n-1 (as most cisco devices) so after you see the above 
> mentioned
>     messages, you should change to that speed in your 
> minicom/picocom/whatever...
>     let me know if this helps to recover at least the serial console...
>     an other thing i spotted is that only 2 of your 4 nics come up indicating
>     to me that they must have changed names in the newer kernel of sid so once
>     you recovered the serial console, we should not stop there.... :)
>     br,
>     cs
>
>
>
>     On 5/19/22 11:23, Edgard da Cunha Pontes wrote:
>      > Hi all,
>      >
>      > After some unsuccessful attempts to install RARE/freeRtr on Luna 
> D-125, I decided to come here for help.
>      > I made an installation tutorial (step by step) that maybe can help to 
> understand the problem.
>      > 
> https://docs.google.com/document/d/1jrXgkYxFyIiKOjQ-tS8bKF-eyoHN4MHVrD9gaX8gPho/edit?usp=sharing
>     
> <https://docs.google.com/document/d/1jrXgkYxFyIiKOjQ-tS8bKF-eyoHN4MHVrD9gaX8gPho/edit?usp=sharing>
>      > 
> <https://docs.google.com/document/d/1jrXgkYxFyIiKOjQ-tS8bKF-eyoHN4MHVrD9gaX8gPho/edit?usp=sharing
>     
> <https://docs.google.com/document/d/1jrXgkYxFyIiKOjQ-tS8bKF-eyoHN4MHVrD9gaX8gPho/edit?usp=sharing>>
>      > The installation ends with a success message, but when restarting the OS, the 
> system "freezes".
>      >
>      > Include the "initcall_debug ignore_loglevel" parameters at system 
> boot, to analyze how far it goes.   These are the latest messages:
>      > [      42.038700] calling     nf_nat_init+0x0/0x1000 [nf_nat] @ 508
>      > [      42.044453] initcall nf_nat_init+0x0/0x1000 [nf_nat] returned 0 
> after 162 usecs
>      > [      42.064865] calling     nf_conncount_modinit+0x0/0x1000 
> [nf_conncount] @ 508
>      > [      42.071886] initcall nf_conncount_modinit+0x0/0x1000 
> [nf_conncount] returned 0 after 102 usecs
>      > [      42.084514] device enp0s20f1 entered promiscuous mode
>      > [      42.101402] calling     nsh_init_module+0x0/0x1000 [nsh] @ 508
>      > [      42.107239] initcall nsh_init_module+0x0/0x1000 [nsh] returned 0 
> after 2 usecs
>      > [      42.199975] calling     dp_init+0x0/0x107 [openvswitch] @ 508
>      > [      42.205665] openvswitch: Open vSwitch switching datapath
>      > [      42.494589] initcall dp_init+0x0/0x107 [openvswitch] returned 0 
> after 282151 usecs
>      > [      42.525521] device enp1s0 entered promiscuous mode
>      > [      42.642649] device enp2s0 entered promiscuous mode
>      >
>      > I hope someone has had a similar problem and can shed some "light".