Mailing List Archive

what do do with bug reports
Hello

What am I supposed to do with glaring bugs? Are Juniper interested in
knowing those or don't they care?

In this case I found out that 19.1 behaves badly if you set [system
services subscriber-management overrides interfaces family inet
receive-gratuitous-arp]. The setting is supposed to enable updating the
ARP table when receiving gratuitous ARP from clients. Instead it makes
the router reply to those ARP packets, which causes the clients to
reject the address.

Packet monitor (somewhat shortened):

07:41:05.677882 bpf_flags 0x03,  In
    Juniper PCAP Flags [no-L2, In]
    -----original packet-----
    PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
[none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
    -----original packet-----
    PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
[none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid
0x1b632c2a, Flags [Broadcast] (0x8000)
    -----original packet-----
    PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
[none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
    -----original packet-----
    PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
[none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid
0x1b632c2a, Flags [Broadcast] (0x8000)
      Your-IP 212.237.x.237
        DHCP-Message Option 53, length 1: ACK
    -----original packet-----
    34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length
4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype
ARP, arp who-has 212.237.x.237 tell 212.237.x.237
07:41:05.686691 bpf_flags 0x00, Out
    -----original packet-----
    e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length
4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17
07:41:05.689680 bpf_flags 0x03,  In
    -----original packet-----
    PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
[none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
        DHCP-Message Option 53, length 1: Decline
^C
8 packets received by filter

The part that is plain wrong is "arp reply 212.237.x.237 is-at
e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and
by responding to this, the router causes the client to believe something
else is using the address. Therefore the client sends Decline back to
the DHCP server.

Proxy-arp settings makes no difference at all. Doesn't matter if you
have it entirely disabled or set to proxy-arp restricted. However
disabling receive-gratuitous-arp makes the router stop doing this.

If I made a case for this I am sure they will just tell me to disable
receive-gratuitous-arp which is exactly what I did. I am just curious if
there is any way to report bugs that I will live with as is. It is still
clearly something that should get fixed.

Regards,

Baldur



_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: what do do with bug reports [ In reply to ]
Hi Baldur,

You should not give up and just report the bug.
JTAC may ask you to disable feature that is causing an impact, but in the
meantime they will work on resolving it.

Mind that it might take some time to replicate the problem, prepare the fix
and implement it in the next official software release.

Regards,


pon., 15 cze 2020, 08:23 u?ytkownik Baldur Norddahl <baldur@gigabit.dk>
napisa?:

> Hello
>
> What am I supposed to do with glaring bugs? Are Juniper interested in
> knowing those or don't they care?
>
> In this case I found out that 19.1 behaves badly if you set [system
> services subscriber-management overrides interfaces family inet
> receive-gratuitous-arp]. The setting is supposed to enable updating the
> ARP table when receiving gratuitous ARP from clients. Instead it makes
> the router reply to those ARP packets, which causes the clients to
> reject the address.
>
> Packet monitor (somewhat shortened):
>
> 07:41:05.677882 bpf_flags 0x03, In
> Juniper PCAP Flags [no-L2, In]
> -----original packet-----
> PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
> -----original packet-----
> PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
> [none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
> 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid
> 0x1b632c2a, Flags [Broadcast] (0x8000)
> -----original packet-----
> PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
> -----original packet-----
> PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
> [none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
> 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid
> 0x1b632c2a, Flags [Broadcast] (0x8000)
> Your-IP 212.237.x.237
> DHCP-Message Option 53, length 1: ACK
> -----original packet-----
> 34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length
> 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype
> ARP, arp who-has 212.237.x.237 tell 212.237.x.237
> 07:41:05.686691 bpf_flags 0x00, Out
> -----original packet-----
> e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length
> 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17
> 07:41:05.689680 bpf_flags 0x03, In
> -----original packet-----
> PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
> DHCP-Message Option 53, length 1: Decline
> ^C
> 8 packets received by filter
>
> The part that is plain wrong is "arp reply 212.237.x.237 is-at
> e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and
> by responding to this, the router causes the client to believe something
> else is using the address. Therefore the client sends Decline back to
> the DHCP server.
>
> Proxy-arp settings makes no difference at all. Doesn't matter if you
> have it entirely disabled or set to proxy-arp restricted. However
> disabling receive-gratuitous-arp makes the router stop doing this.
>
> If I made a case for this I am sure they will just tell me to disable
> receive-gratuitous-arp which is exactly what I did. I am just curious if
> there is any way to report bugs that I will live with as is. It is still
> clearly something that should get fixed.
>
> Regards,
>
> Baldur
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: what do do with bug reports [ In reply to ]
Hi,

File a JTAC problem report, either yourself via a Juniper Partner (where
you should have support for your devices).



Rgds.

Ola Thoresen


On 15.06.2020 08:15, Baldur Norddahl wrote:
> Hello
>
> What am I supposed to do with glaring bugs? Are Juniper interested in
> knowing those or don't they care?
>
> In this case I found out that 19.1 behaves badly if you set [system
> services subscriber-management overrides interfaces family inet
> receive-gratuitous-arp]. The setting is supposed to enable updating
> the ARP table when receiving gratuitous ARP from clients. Instead it
> makes the router reply to those ARP packets, which causes the clients
> to reject the address.
>
> Packet monitor (somewhat shortened):
>
> 07:41:05.677882 bpf_flags 0x03,  In
>     Juniper PCAP Flags [no-L2, In]
>     -----original packet-----
>     PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>     -----original packet-----
>     PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
> [none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
> 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291,
> xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>     -----original packet-----
>     PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>     -----original packet-----
>     PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
> [none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
> 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291,
> xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>       Your-IP 212.237.x.237
>         DHCP-Message Option 53, length 1: ACK
>     -----original packet-----
>     34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length
> 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype
> ARP, arp who-has 212.237.x.237 tell 212.237.x.237
> 07:41:05.686691 bpf_flags 0x00, Out
>     -----original packet-----
>     e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806),
> length 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17
> 07:41:05.689680 bpf_flags 0x03,  In
>     -----original packet-----
>     PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>         DHCP-Message Option 53, length 1: Decline
> ^C
> 8 packets received by filter
>
> The part that is plain wrong is "arp reply 212.237.x.237 is-at
> e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1
> and by responding to this, the router causes the client to believe
> something else is using the address. Therefore the client sends
> Decline back to the DHCP server.
>
> Proxy-arp settings makes no difference at all. Doesn't matter if you
> have it entirely disabled or set to proxy-arp restricted. However
> disabling receive-gratuitous-arp makes the router stop doing this.
>
> If I made a case for this I am sure they will just tell me to disable
> receive-gratuitous-arp which is exactly what I did. I am just curious
> if there is any way to report bugs that I will live with as is. It is
> still clearly something that should get fixed.
>
> Regards,
>
> Baldur
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: what do do with bug reports [ In reply to ]
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: what do do with bug reports [ In reply to ]
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp