Baby jumbo frames on VDSL by XS4ALL

Dirk-Jan Leave a comment

Last week I acquired a new modem because the old one supplied by the provider was acting strange and I wanted it. The new modem is a Cisco 887VA router equipped with a VDSL2/ADSL2+ interface so that it could replace the previous Fritz!box. A day after I had finished the setup I noticed some unusual things which eventually led to the conclusion that packet fragmentation was occurring. In my search for an answer I learned that the Point-to-Point protocol (PPP) needs 8 bits which need to be subtracted from the default MTU of 1500. So configuring an MTU size of 1492 for the Dialer0 interface and altering the max segment size ‘ip tcp adjust-mss 1452’ on the internal VLAN interface did the trick.

But, then I stumbled upon a service page of my provider stating (in Dutch):

RFC4638 wordt ondersteund op ons netwerk. Dit betekent dat u als klant een MTU van 1500 kunt gebruiken als uw router RFC4638 ondersteunt.

So it’s possible to use a MTU size of 1500 if the router is able to do so. In the past I have played with MTU sized 9000 (called Jumbo frames), so 1512 is a baby.

It took some time to figure out how, but eventually came up with the following:

!
interface Ethernet0
 mtu 1512
 no ip address
!
interface Ethernet0.6
 encapsulation dot1Q 6
 pppoe enable group global
 pppoe-client dial-pool-number 1
 pppoe-client ppp-max-payload 1500
!
interface Dialer0
 no mtu 1492
!
interface Vlan2
 no ip tcp adjust-mss 1452
!

Want to follow the PPP negotiation proces, then execute to following (in enable mode):

debug ppp negotiation
clear ppp all
show logging

Time to test!

$ ping -c 3 -s 1472 www.xs4all.nl
PING www.xs4all.nl (194.109.6.92) 1472(1500) bytes of data.
1480 bytes from www.xs4all.nl (194.109.6.92): icmp_seq=1 ttl=61 time=6.18 ms
1480 bytes from www.xs4all.nl (194.109.6.92): icmp_seq=2 ttl=61 time=6.23 ms
1480 bytes from www.xs4all.nl (194.109.6.92): icmp_seq=3 ttl=61 time=5.96 ms

--- www.xs4all.nl ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.966/6.128/6.234/0.116 ms
$

ADRCI incompatible schema version

Dirk-Jan 1 Comment

This issue arises when migrating from Oracle 12.1 to 12.2.

I could not easily find the info how to fix this issue, so I’ll share it in case someone else stumbles upon it.

adrci> show log
DIA-48494: ADR home is not set, the corresponding operation cannot be done
adrci>
adrci> show homes
ADR Homes: 
diag/netcman/hostname/cman_hostname.domainname
adrci>
adrci> set homepath diag/netcman/hostname/cman_hostname.domainname
adrci> purge -age 129600 -type ALERT
DIA-49803: Purge not possible due to incompatible schema version.
adrci> set homepath diag/netcman/hostname/cman_hostname.domainname
adrci> migrate schema
Schema migrated.
adrci> purge -age 129600 -type ALERT
adrci>

Done!

Securing MySensors network

Dirk-Jan Leave a comment

Some months ago I decided it was time to secure my steadily growing MySensors network. As described on the MySensors website this can be implemented by using a software or hardware solution to sign messages. I chose the hardware solution using the ATSHA204A component. Because the more convenient break-out board was out of stock, I ordered a little strip of 3-legged ATSHA204A surface mounted devices (SMD). But when they arrived I was struck by the size of those things.

Feeling steady handed today I took the nerve to solder one of them to put on my gateway device. This gateway device consists of a Arduino Uno, Ethernet shield (W5100) and nRF24L01+ PA/LNA. There are some nodes (Sensebender Micro) in the house which are already equipped with an ATSHA204A.

Somewhat proud of my accomplishment I like to share some picture of what it looks like.

Curious and want to know more about securing MySensors, check out the following page.